This is a series of articles introducing the Nostr protocol. In previous articles, we introduced its origin and basic usage. In this article, we will discuss its working principle and some thoughts on the Nostr network.
💡 Interestingly, "nostre" in Catalan and "noster" in Latin mean "ours".
The Nostr protocol does not specify programming languages, platforms, databases, etc., allowing developers complete freedom in designing and implementing relays. This has attracted developers and enthusiasts from various industries. Currently, there are implementations in C#, Rust, Go, Java, Python, Kotlin, JavaScript, TypeScript, and Clojure. These relay implementations use SQLite or PostgreSQL as their databases.
Basic Elements of the Nostr Protocol#
In the network composed of the Nostr protocol, we can simplify the model of a minimum element. The basic elements include: users, clients, and relays. The relationship between these three elements can be represented as follows:
-
Users use clients to publish and view content (transmitted in the form of events) and complete signatures on the client when necessary.
-
Clients send content to relays for transmission and receive content transmitted by relays. Relays only forward messages.
We can see that clients do not communicate directly with each other, and relays do not communicate with each other.
As shown in the above figure, User 1 uses Client 1 and Client 2 to send messages. User 1 subscribes to Relay 1 and Relay 2 using Client 1, so the messages sent by Client 1 will be broadcasted by Relay 1 and Relay 2. If User 2 is the recipient of the message, they can receive the message through Client 1 and Client 2. Since User 2 subscribes to Relay 1 and Relay 2 using Client 1, they can view the messages broadcasted by Relay 1 and Relay 2 through Client 1. User 2 only subscribes to Relay 2 using Client 2, so they can only receive messages broadcasted by Relay 2 through Client 2.
From here, we can observe a phenomenon, which is that the relay is only responsible for transmitting the messages sent by the client and does not make any changes to the messages. Message editing, processing, and display, as well as user operations such as following, blocking, unfollowing, and zapping, are all completed on the client. This is also an important development principle of the Nostr protocol: "Dumb Relay, Smart Client".
The speed of your client operation depends on the relay you are connected to. Therefore, you can connect to more relays to ensure a smooth experience when using the Nostr network. When more relays forward the content sent by our clients, the client's user experience is better. When all the relays you are connected to are disconnected, you will not be able to find all the content published by your account unless you reconnect to these relays. If you want to ensure that your data is always saved, you can also operate your own relay. Here is a guide: Set up a Nostr Relay Server in Under
Advantages and Applications of the Nostr Protocol#
Advantages of the Nostr Protocol:#
Under this development principle, the following advantages will be brought:
-
Freedom of speech
Relays can prevent users from publishing any content there, but this does not affect them because they can still publish to other relays. Since users are identified by public keys, when they are banned, they do not lose their identity and their follower base. There is no need for users to manually enter new relay addresses (although this should also be supported). Whenever someone you follow publishes a server recommendation, the client should automatically add it to the list of relays it will query. If someone is using one relay to publish their data but wants to migrate to another relay, they can publish a server recommendation to the previous relay.
If someone is banned by multiple relays to the point where they cannot broadcast their server recommendations, they can still let some close friends know where they are currently publishing through other means. Then, these close friends can connect to the new server to view the content posted by their friends. Gradually, the old fan base of the banned user will start to find their posts again from the new relay. When the relay stops operating, all the above content is still valid.
In such a system, as long as we keep our private and public keys safe, we don't have to worry about being blocked by content platforms, and our right to speak will return to our own hands.
-
Resistance to censorship
Each user can publish their updates to any number of relays. Relays can charge users (the negotiation of this fee is currently not within the scope of the protocol) to publish there, which ensures resistance to censorship.
-
Prevention of spam
If spam is a problem for relays, it may require payment of publishing fees or some other form of identity verification, such as email addresses or phone numbers, and associate them internally with public keys, and then publish them to the relay—or other anti-spam techniques such as hashcash or captchas. If a relay is used as a spam carrier, it can be easily delisted by the client, and the client can continue to receive content updates from other relays.
-
More elegant data storage
In order to keep the network healthy, hundreds of active relays are not required. In fact, considering the fact that new relays can be easily created and spread through the network when existing relays start to have problems, only a few are needed to work properly. Therefore, the required amount of data storage is usually less than that of Mastodon or similar software. Alternatively, consider a different outcome: there are hundreds of niche relays run by amateur enthusiasts, each relay has a small group of users updating content. This architecture can also be scaled: data is sent from users to a single server, and then directly sent from that server to users who will use the data. It does not need to be stored by anyone else. In this case, it is not a big burden for any server to process updates from other servers, and having amateur servers is not a problem.
-
Transmission of video and other content
Relays can easily reject large content or charge for accepting and hosting large content. When information and incentives are clear, specialized video service providers will emerge in the market to realize the transmission of video and other files, which will promote the formation of new commercial services.
-
Users control their own information flow
Each client can decide how to best display posts to users, so users can always choose to view content in the way they want—whether it is using AI to determine the order of updates seen or sorting content in chronological order.
Applications of the Nostr Protocol:#
The design concept of Nostr is that one day it can replace Twitter as a platform, but in addition to that, it can also be used in the following applications:
- Direct and instant messaging
- Public chat rooms
- News channels
- Forums
- Websites
- Code repositories
- Virtual communities
- Games (Checkers, Chess)
- Real-time collaboration
- Uber clone
- RSS readers
- Tipping
- Automation and home automation
- Voting
- Bridges from other social networks to Nostr (email, Twitter, Mastodon, etc.)
- More features, waiting for everyone to explore together
Classification of Relays#
Anyone can develop and operate their own relay, and some people are already operating relays for profit. There is no official explanation for the classification of relays, and the relays on the market can be roughly divided into three categories:
- Regular relays: Anyone can publish content on them, similar to a public square, without any filtering of the published content, so the overall information quality is low and the content is uneven.
- Paid relays: There is a certain entry barrier, requiring payment or a certain registration process, and some content filtering is implemented, but it does not mean that there is no spam content.
- Closed relays: Only designated users can join, and they are dedicated to internal small circles. For example, organizations, companies, and clubs use their own relays.
Of course, for most people, the first and second types of relays are sufficient to meet our needs. You can find existing relays here: Find Relays
Some Thoughts on Nostr#
Economic System#
The Nostr protocol network introduced the lightning network from the beginning, giving the entire Nostr network a native economic "gene". The next step is to explore business scenarios that can achieve economic exchanges and develop corresponding functions for these scenarios.
In terms of the functions that clients generally have at present, one function that can develop an economic system is "zap". When anyone expresses their liking, instead of using "like", they use "ZAP" and send a certain amount of sat to support the content they like. This will enable the creator's economy to have the possibility of growth. When more people naturally reward the content they appreciate, the culture of rewarding will spread in the Nostr network, and creators will be motivated to produce higher-quality content, and the business flywheel will start to turn.
Ecological Construction#
Nostr is not an application, it is a communication protocol, like an underground river, on which we can plant various plants (build our own applications to achieve various functions) to develop a forest. We can imagine that a rich application ecology will be developed based on the Nostr protocol. Based on my observations in the Nostr developer group and research on Nostr-related projects on GitHub, developers are still very enthusiastic, and they are rapidly developing and iterating new applications and features. If this development continues, the Nostr ecology will inevitably experience a wave of explosion in the near future.
Of course, there are also some issues that we need to pay attention to, such as the high similarity of many project functions, which wastes more possibilities for ecological development.
Overall, developers are the foundation of the Nostr network's development. Only with good applications can more diverse functions be supported. Currently, developer incentives are missing, and developers are developing out of love. Before starting development, every developer may try to think about how to achieve commercialization. This is not only beneficial to the long-term development of their applications, but also when more developers think about business models, the commercial possibilities of the entire ecosystem can be developed, which will promote the prosperity of the entire ecosystem market and further promote the development and popularization of the Nostr network.
*You can also find me in these places*:
Jike: hoodrh
Mirror: Hoodrh
Twitter: Hoodrh
Nostr: npub1e9euzeaeyten7926t2ecmuxkv3l55vefz48jdlsqgcjzwnvykfusmj820c
If you like it here, you can tip me via the Lightning Network :)