The Future of Social Communication Architecture: The Beginning of Nostr and the Next Stop for Social Messaging
TechFlow Selected TechFlow Selected
The Future of Social Communication Architecture: The Beginning of Nostr and the Next Stop for Social Messaging
Open the "gateway to myriad wonders" of social communication protocols.
Navigating Web3 tides with focused insightsThis is the second article in the "Trinity" series on Web3 social infrastructure. The series begins with the era of Ethereum's world computer, using the release of Binance Greenfield’s whitepaper as a turning point into a "new trinity" era, exploring the foundational roles of decentralized compute, decentralized storage, and decentralized communication within the Web3 ecosystem. Decentralized computing has long been at the center of attention through debates over Layer 1 and Layer 2 solutions; the potential of decentralized storage has now been widely recognized thanks to strong support from Binance. The third piece of this puzzle—“decentralized communication”—is poised to become the next major frontier with comparable scale and promise. This series follows that thread.
In the previous article, we revisited Ethereum’s original “trinity” vision during its early days and examined current approaches and future directions for decentralized storage using Binance Greenfield as a case study. In this article, we take Nostr—the first breakout protocol in the decentralized communication space—as our starting point and analytical subject, exploring what preparations are needed for a mature decentralized communication system beyond the minimalist, staunchly Bitcoin-maximalist design principles embodied by Nostr.
Frontier Schema of Nostr: Opening the "Gate of All Wonders" for Social Communication Protocols
After about a month of hype and consolidation, the dust kicked up by Damus—the most popular application built on the Nostr protocol—has largely settled back to ground zero. Damus rose due to its simplicity, yet also fell because of it. The anarchic nature of the protocol brought idealistic enthusiasm, mass adoption driven by peer influence, and ultimately, an overwhelming flood of spam. After reorganizing various studies on Nostr and diving into developer documentation from the builders' perspective, we conclude: Nostr is merely a starting station for social communication. As an experimental network, its role is more that of a "trumpeter"—raising awareness—than a fully functional application. It has successfully brought decentralized communication into public view but fails to deliver due to missing essential technical and design components. Overall, Nostr represents a prototype of a communication protocol lacking anti-fragility. Following Nostr’s wake-up call, we believe skilled developers can now forge the next generation of communication protocols based on this prototype. Toward the end of this article, we will explore better alternatives to the current relay network model.
Nostr Data Overview
Nostr Ecosystem Data
Data source: https://nostr.directory/stats
Relay Deployment Status
There are currently 132 public relays, 49 restricted relays, and 74 offline relays on Nostr.
Relays are primarily deployed in North America: 92 in the United States, 37 in Canada, followed by Germany in third place with 35.
Nostr's Core Principle: Dumb Server, Smart Client
Technical Basics
Client: The client handles various social tasks. It is complex and customizable.
Relay: A relay server communicates with clients, storing and indexing data. Its simplicity ensures interoperability.
Event: The fundamental object or data type used by relays, enabling message transmission and retrieval between relays and clients. Events and their tags are highly extensible, giving developers great flexibility.
sig: Signature, ensuring event authenticity, generated on the client side.
tags: Open and arbitrary tags. For example, replying to an event adds an “e tag”.
Technical workflow: Clients send events to relay servers, including pointers to specific relays. Relays store and index these events. Other clients communicate with relays they “know” to request stored events.
All complexity remains on the client side, while relays only need to meet minimal consensus standards—offering vast flexibility and extremely low development barriers.
*Current clients are not directly communicating with relays via native apps but through web interfaces, which remain vulnerable to blocking.
Freely Switchable Relays: Infinite Portals
Like any server, relays may be flooded with spam, receive harmful content, or maliciously block benign users or messages. Nostr’s solution isn’t simply increasing the number of relays infinitely and letting users choose ones matching their preferences (as Mastodon does), but rather minimizing deployment costs and switching friction between relays—enabling dynamic freedom at minimal cost.
An infinite portal always leads to another relay. On one hand, the low barrier to deploying relays ensures they can never be exhausted; on the other, easy switching guarantees users the freedom to leave a relay at any time and continue building social connections elsewhere. The mechanism for leaving a relay works as follows:
1) Broadcasting a recommendation pointing to another relay. The client on the old relay automatically detects and adds the new relay to its known list, so others won’t lose track of someone just because they switched relays.
2) If someone is banned across many relays and cannot broadcast their new relay info, they can inform friends through alternative channels.
It must be noted that automatic data migration between relays is impossible, meaning users cannot seamlessly carry existing social relationships and historical data when switching relays.
Nostr and the Topology of Social Spaces
“Simple yet robust” is the best possible vision for a social communication protocol—an elegant design philosophy rooted in Bitcoin maximalism as reflected in Nostr. “Simplicity” demands sacrificing all nonessential technical details, achieving functionality with minimal means. However, Nostr fails to strike a balance in its trade-offs, compromising core functionality itself in the process:
“Simple…”
Why is Nostr simple? Because social space, like physical space, should be simple and entirely passive. Relay operators are custodians, not “managers” (unlike Mastodon). Access and exit define all functionalities and set boundaries for shared spaces.
Beyond spatial boundaries, all other functions are implemented by the “client.” This makes Nostr resemble real-world social dynamics: just as infinite storage doesn’t exist, neither do infinite search or reach. Only “shared spaces” exist. Co-presence becomes a relational concept aligned with natural social processes: forming intersections → following up; staying in the same shared space deepens ties; leaving ends the relationship.
Nostr materializes abstract interest-based communities into physical reality. On platforms like WeChat, Telegram, WhatsApp, or other messaging apps, groups are fundamentally abstract—not tied to any technical entity. But Nostr binds groups directly to physically deployed “relays,” anchoring them to actual node servers.
“But not robust.”
This approach creates a critical flaw: the storage problem. Since relays do not communicate or exchange data with each other, leaving or being expelled from a relay results in losing access to accumulated social data—just like leaving a Web2 platform. When users leave WeChat, Facebook, or Xiaohongshu, they cannot take their social graph with them because these platforms don’t interoperate. Nostr behaves more like a Web2 than a Web3 protocol: Nostr’s multiple relays create redundant copies of user data (and allow self-backup), but offer no guarantee of backup integrity.
Clients build features atop these isolated backups. This is akin to constructing new buildings on an unstable sandcastle—each new layer depends on fragile foundations. As user numbers grow and time passes, “permanent data loss” shifts from a possibility to inevitability. And unlike centralized systems, there is no central authority to vouch for recovery. Relays are anonymous, and we cannot expect every user to personally deploy their own relay for data security.
The free-jumping “portals” enabled by lack of data interoperability resemble late-stage federated models of Web2 platforms, not true precursors to Web3 networks.
Is 'Dumb Relay' Really the Best Solution for Relay Networks?
Assuming decentralization as a premise, “relays” can technically take many unrestricted forms. “Dumb Relay” is one option, but another exists: allowing relays to “speak.” “Speech” enables consensus. Only when relay nodes exchange data can protocol-level synchronization emerge. Such synchronization isn’t redundancy—it’s a necessary technical foundation for data security and protection against single points of failure. Underlying “consensus” lies the entire network’s security.
Nostr resembles a “protocol-layer demo” rather than a system ready for mass adoption. Communication protocols must always prepare for the next billion users. At that scale, issues previously considered secondary—data security and recoverability—become central challenges every protocol developer must confront.
From Nostr's Starting Point to the Next Generation of Communication Protocols
In summary, we can abstract several characteristics that Nostr currently lacks (or possesses incompletely), but which an ideal next-generation relay network should have:
- Inter-node consensus to prevent permanent data loss caused by single-point failures;
- Scalability: Due to the “Dumb server, Smart client” design principle and efforts to minimize relay deployment barriers, Nostr cannot scale individual relays effectively;
- Abstracted accounts (instead of irrecoverable public-private key pairs);
- An economic incentive layer to sustain relay node growth under large user bases.
These goals are not mutually exclusive. Given the strategic importance of decentralized communication protocols and their associated user value and economic potential, existing relay networks and decentralized protocols will inevitably evolve toward these objectives. PUSH, XMTP, Dialect, Notifi, Hal, Tenderly, and parts of Status that inherit Ethereum’s Whisper legacy are all promising candidates worth watching. In the next article, we’ll examine one of these protocols—one showing the highest completion rate and fastest progress—as a reference model for decentralized communication.
Acknowledgements
Special thanks to ArNostr, George Zhang Tengji from Unipass, and Sponge Aaron from Plancker DAO for their contributions to this article.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
