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 minimal 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 sign when necessary.
-
Clients send content to relays for transmission and receive content from 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 messages through Client 1 and Client 2. Since User 2 subscribes to Relay 1 and Relay 2 using Client 1, they can view messages broadcasted by Relay 1 and Relay 2 through Client 1. User 2 only subscribes to Relay 2 using Client 2, so Client 2 can only receive messages broadcasted by Relay 2.
From this, we can observe a phenomenon: relays are only responsible for transmitting messages sent by clients and do not make any changes to the messages. Message editing, processing, display, and user operations such as following, blocking, unfollowing, and zapping are all done on the client. This is an important development principle of the Nostr protocol: "Dumb relays, smart clients".
The speed of your client's operation depends on the relays 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 you have published 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
Advantages and Applications of the Nostr Protocol#
Advantages of the Nostr Protocol:#
Under this development principle, the following advantages are brought about:
-
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 recommendation, 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 their friends' posts. Gradually, the banned user's old fan base will start finding their posts again from the new relay. When the relays stop operating, all the above content is still valid.
In such a system, as long as we keep our private keys and public keys safe, we don't have to worry about our accounts being blocked by content platforms. 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 (currently, the negotiation of this fee is not within the scope of the protocol) to publish there, which ensures resistance to censorship.
-
Preventing 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
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 issues, only a few are needed for it 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 scale: data is sent from users to a single server, and then directly sent from that server to users who will use the data. It doesn't have 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—from 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 besides 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, resulting in low overall information quality and inconsistent content.
- Paid relays: There is a certain barrier to entry, 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, relays for organizations, companies, and clubs.
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 Existing 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 those scenarios.
In terms of the functions that clients generally have at present, a 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 potential for 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 spinning.
Ecological Construction#
Nostr is not an application, it is a communication protocol, like an underground river. We can plant various plants on it (build our own applications to achieve various functions) to develop a forest. We can imagine that a rich application ecosystem will be developed based on the Nostr protocol. Based on my observations in the Nostr developer community and research on Nostr-related projects on GitHub, developers are enthusiastic and are rapidly developing and iterating new applications and features. If this development continues, the Nostr ecosystem will inevitably experience a burst of growth 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 the potential for further development of the ecosystem.
Overall, developers are the foundation of the Nostr network's development. Good applications can support the implementation of more diverse functions. Currently, developer incentives are lacking, 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 for 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's commercial 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. 🙂