Future Social Communication Framework: Nostr’s Starting Point and the Next Stop in Social Communication.

“Opening the ‘gateway to endless possibilities’ in social communication protocols.”

This is the second article in the ‘Web3 Social Infrastructure Trinity’ series. The series starts from the era of Ethereum as the world computer and marks the release of Binance’s Greenfield white paper as the turning point into the ‘New Trinity’ era, discussing the foundational roles of decentralized computing, decentralized storage, and decentralized communication within the Web3 ecosystem. Decentralized computing has long been the focal point with the ongoing L1 and L2 debates, while the potential of decentralized storage has been widely recognized, particularly with Binance’s backing. Now, the third piece of the puzzle, ‘decentralized communication,’ is poised to become the next prominent area of growth. This series follows this narrative.

In the previous article, we reviewed the early ‘trinity’ concept in Ethereum’s formative days and examined decentralized storage solutions and directions through the example of Binance’s Greenfield. In this article, we take ‘Nostr,’ the first protocol to make waves in the decentralized communication space, as our starting point for analysis. Using Nostr as a lens — characterized by a disciplined adherence to Bitcoin’s fundamental principles — we will explore what preparations are necessary for a mature decentralized communication model to emerge.

Nostr Frontier Blueprint: Opening the ‘Gateway to Infinite Possibilities’ in Social Communication Protocols

A month after the initial excitement, the dust kicked up by Damus — the most popular app on the Nostr protocol — has settled back to its starting point. Damus’s simplicity was both its strength and its weakness; the protocol’s anarchistic nature initially drew cheers from idealists, followed by a flood of users, ultimately leading to an ad overrun. After reviewing studies on Nostr and delving into developer documentation, we conclude that Nostr is merely the starting point for social communication. As an experimental network, it functions more as a “herald” than a practical application, bringing decentralized communication into public view without fully delivering due to a lack of essential technical and design elements. Overall, Nostr is a prototype of a communications protocol that lacks antifragility. In response to Nostr’s momentum, we believe skilled developers can build the next generation of communication protocols around this prototype. At the end of this article, we will explore better solutions, such as relay networks.

Overview of Nostr Data

Data source: https://nostr.directory/stats

Relay Deployment Status：

Nostr currently has 132 public relays, 49 restricted relays, and 74 offline relays.

The relays are mainly deployed in North America, with 92 in the United States, 37 in Canada, and the third highest in Germany (35).

The core of Nostr: Dumb server, Smart client.

Technical Basics

• Client: The client handles various social tasks. It is complex and customizable.
• Relay: The relay server communicates with the client, storing and indexing data. It achieves interoperability through its simplicity.
• Event: An event is the basic object/data type used by the relay, facilitating the sending and retrieving of messages between the relay and the client. Events and their tags are highly extensible, allowing developers significant freedom.
• sig: A signature that ensures the authenticity of events. This is done on the client side.
• tags: Open, arbitrary tags. For example, a reply to an event might be tagged with “the e tag.”
• Technical Implementation Process: The client sends events to the relay server, including a pointer to a specific relay within the event. The relay then stores and indexes these events, and other clients can communicate with the relay servers they are aware of to request the events they have received and stored.

All complexity is left on the client side, while the relay only needs to meet a minimal consensus standard, providing developers with ample flexibility and a very low barrier to entry.

Currently, the client is a web-based interface that does not communicate directly with the relays, which still poses a risk of interception.

Relay: An Infinite Portal for Free Jumping.

“Relays” like all previous servers, can be filled with spam, receive harmful information, or maliciously block content and users that pose no harm. Nostr’s solution isn’t to infinitely increase the number of relays and give users the power to choose relays that meet their standards (as Mastodon is doing), but rather to achieve minimal cost dynamic freedom by reducing the deployment costs of relays and the switching costs between them.

The “Any Door” can always lead to the next relay. On one hand, the low-threshold deployment of relays ensures they cannot be exhausted; on the other hand, the convenience of switching relays guarantees that users have the freedom to leave a relay and continue building their social connections at any time. The mechanism for leaving a relay is as follows:

1) A recommendation for another relay is sent from the current relay. The client of the original relay (the old relay) will automatically recognize and add the new relay to its list of known relays. This way, others will still be able to receive updates from someone even if that person switches relays.

2) If someone is blocked by many relays at the same time, preventing the relay recommendations from being broadcast, they can still let their friends know about their new relay through other means.

It is important to note that automatic data migration between relays is not possible, which means users cannot seamlessly transfer their existing social connections and data when switching between relays.

The topology of Nostr and social spaces.

“Concise yet robust” is the best vision we can have for a social communication protocol, embodying the elegant design philosophy of Bitcoin fundamentalism as it is applied to social protocols like Nostr. “Concise” demands the sacrifice of all unnecessary technical details to achieve just the right level of functionality. However, in this process of sacrificing, Nostr fails to find a balance, instead compromising the functionality itself:

“Concise…”

Why is Nostr concise? Because the social space, as a kind of space, is inherently simple and completely passive. The operators of the relay act merely as guardians, rather than “managers” (as seen in Mastodon). The entrance and exit constitute all the functions of this space and define the boundaries of the intersecting space.

Beyond the boundaries themselves, all other functionalities within the space are realized by the “clients.” This allows the Nostr protocol to more closely resemble the social landscape of the real world: just as infinite storage doesn’t exist, neither do infinite retrievals or infinite reach. What exists is only a “shared space.” The concept of “coexistence” represents a relationship diagram that aligns with all natural social processes: forming intersections → tracking interactions; if individuals remain within the same intersecting space, those interactions deepen; if they leave, the relationship ceases to exist.

Nostr’s approach is a physical realization of an abstract interest space. On platforms like WeChat, Telegram, WhatsApp, or others, the concept of groups is fundamentally abstract and not tied to any specific technical entity. However, Nostr binds groups to physically deployed “relays,” directly linking them to specific node servers.

“But not robust.”

This approach raises an important issue: the storage problem. Since relays do not communicate with each other, there is no data exchange. Leaving a relay or being expelled from one is akin to a user voluntarily departing from or being removed from a specific Web2 platform, without being able to take their social data with them. Users can’t carry their social relationships when they leave WeChat, Facebook, or Xiaohongshu, as WeChat does not communicate with Facebook or Xiaohongshu. Nostr is closer to a Web2 than a Web3 protocol: the multiple relays essentially back up users’ social data (while also supporting users in backing it up themselves), but they do not guarantee the safety of those backups.

The “client” relies on these non-communicating backups to implement different functions. This is akin to constructing new buildings on a very unstable data sandcastle; each new construction represents a fresh invocation of the old sand layers. Yet, as the user base expands and time passes, “permanent loss” shifts from being a probability issue to a certainty. At this point, there is no centralized institution that can vouch for such permanent loss. Relays are anonymous, and we shouldn’t assume that every user will personally deploy a relay to ensure the safety of their data.

The arbitrary transitions caused by the lack of data interoperability are more reminiscent of the late-stage federalism of Web2 platforms, rather than the true embryonic form of a Web3 network.

Dumb Relay: Is it really the best solution for relay networks?

With decentralization as a premise, “relays” can take on many unlimited forms in technical design. “Dumb Relay” is one option, but there’s another choice: allowing the “Dumb Relay” to have a voice. Having a voice is a prerequisite for consensus; only through data exchange between relay nodes can protocol-level data synchronization occur. This synchronization is not a matter of redundancy but rather a necessary technical background for data security and preventing single points of failure. Behind “consensus” lies the security of the entire network.

Nostr is more like a “protocol layer demo” for a communication protocol, not designed for large-scale applications. Communication protocols must always prepare for the next hundred million users. At that scale, the issues of data security and recovery — once secondary concerns — will become core challenges that every protocol layer developer must face.

From the starting point of Nostr to the next destination of the next-generation communication protocol.

In summary, we can identify several features that the ideal relay network of the next generation should possess, even though Nostr currently lacks them (or lacks them in full):

1. Consensus among nodes to prevent permanent data loss due to single points of failure.
2. Scalability: Given the “Dumb server, Smart client” design philosophy, which aims to lower the deployment threshold for relays, the Nostr protocol cannot effectively scale for specific relays.
3. Abstract accounts (instead of irrecoverable public-private key pairs).
4. An economic incentive layer to support a growing number of relay nodes with a large user base.

These standards are not mutually exclusive. Considering the crucial ecological role of decentralized communication protocols, along with the user value and economic potential they offer, existing relay networks and decentralized protocols will inevitably evolve in these directions. PUSH, XMTP, Dialect, Notifi, Hal, Tenderly, and some projects inheriting the legacy of Ethereum’s Whisper, such as Status, are all worthy of observation. In the next article, we will present a case study of one communication protocol that has achieved relatively high completion and speed, serving as a reference sample for decentralized communication.