quoting naddr1qv…8upl
The Most Misunderstood Protocol
There is a confusion that afflicts almost everyone who encounters Nostr for the first time. It is a confusion born of familiarity. We have spent so long in the world of platforms—Twitter, Facebook, Reddit, Mastodon—that we cannot help but map every new system onto the old coordinates.
Is Nostr like Twitter? Sort of. Is it like Mastodon? Sort of. Is it decentralized? Federated? Peer-to-peer? What is the trust model? Who is in charge? Where is the data? Who can see it? Who can delete it?
These are the right questions. But the answers require us to think in a way that platforms have trained us not to think. They require us to distinguish between layers that platforms deliberately conflate.
This essay is an attempt to draw that distinction clearly. It argues that Nostr's genius lies in its separation of concerns: the protocol is decentralized, relays are federated (or not, as they choose), and users are sovereign. No single entity controls Nostr. Users manage their own relationships with relays. And the protocol itself does not care—literally does not care—how relays organize among themselves.
This is not a bug. It is the entire point.
The Layers We Must Untangle
Before we can understand Nostr's trust model, we must first understand that there is not one model but several, operating at different layers of the stack.
The Protocol Layer: This is the set of rules that define how clients and relays communicate. It specifies event formats, signature schemes, message types, and basic interaction patterns. The protocol is decentralized in the strongest possible sense: no one owns it, no one controls it, no one can change it without convincing a massive installed base to follow along. The protocol is to Nostr what TCP/IP is to the internet—a common language that enables everything else.
The Relay Layer: This is the network of servers that store and forward events. Relays are operated by individuals, communities, companies, and idealists. They can have any rules they want. They can charge fees, require authentication, delete content, block users, or federate with other relays. The protocol does not care. The protocol does not know. The protocol only defines how clients talk to relays, not how relays talk to each other.
The Client Layer: This is the software that users interact with. Clients fetch events from relays, display them in feeds, and publish new events on behalf of users. Clients can be smart. They can aggregate, filter, search, and recommend. They can connect to dozens or hundreds of relays simultaneously. They can implement any discovery algorithm their developers can imagine.
The User Layer: This is you. You control your keys. You choose your clients. You select your relays. You decide what to publish and what to read. You are not a user of a platform. You are a participant in a protocol.
Each of these layers has its own trust dynamics, its own governance model, its own failure modes. Understanding Nostr means understanding that these layers are independent—and that this independence is the source of the system's resilience.
The Protocol is Decentralized
The protocol layer of Nostr is as decentralized as anything in the history of computing. It is a set of specifications—NIPs, or Nostr Implementation Possibilities—that anyone can implement. There is no central server that runs the protocol. There is no company that owns it. There is no foundation that controls it.
This is not accidental. It is the direct consequence of a design choice: Nostr does not require relays to coordinate. They do not need to agree on a global state. They do not need to reach consensus. They do not need to sync with each other. They just need to understand the same event format and the same basic message types.
The result is a system that has no central point of control. No one can shut down the protocol because the protocol is not a thing that runs anywhere. It is just an idea. It is just a set of rules that many independent pieces of software happen to follow.
This is the same model that gave us email, the web, and TCP/IP. No one controls SMTP. No one controls HTTP. No one controls IP. They are protocols. They are languages. They are not platforms.
And like those protocols, Nostr benefits from what economists call "compositional evolution." Anyone can build on it. Anyone can extend it. Anyone can use it for purposes its creators never imagined. The protocol does not care. The protocol does not judge. The protocol just defines how to format and sign an event.
Relays are Federated (Or Not, As They Choose)
Here is where the confusion usually begins. If the protocol is decentralized, what are relays? And how do they relate to each other?
The answer is: relays relate to each other however they want. The protocol does not specify. The protocol does not care.
Some relays operate in isolation. They accept events from a small community, store them locally, and never exchange data with anyone else. These are private spaces, digital clubhouses, sovereign territories.
Some relays federate. They exchange events with other relays, creating a shared pool of content. They might do this through simple replication, or through more sophisticated protocols like the one ActivityPub uses. The point is: this is their choice. The protocol does not mandate it, but it does not prevent it either.
Some relays act as indexers. They crawl the network, collect metadata, and provide search and discovery services. Clients can query them to find events, users, or topics of interest. These indexers are themselves relays—they just happen to store a lot of data and provide useful APIs.
The key insight is that federation is an implementation detail, not a protocol requirement. It is something relay operators can do if it serves their users. It is not something the protocol forces on anyone.
This flexibility is what gives Nostr its unusual combination of properties. It can support intimate communities where every member knows every other. It can support massive public squares where millions of users interact. It can support private groups, encrypted chats, and public broadcasts—all on the same protocol, all with the same basic event format.
The Bootstrap Problem and the Role of Indexers
One of the oldest problems in decentralized systems is bootstrapping. How do you find anything when there is no central directory? How do you discover new people when there is no global list?
Nostr's answer is: indexers.
An indexer is a relay that specializes in discovery. It crawls other relays, collects metadata about users and events, and makes that metadata available to clients. It might index public keys, relay lists, NIP-05 identifiers, or any other data that helps users find what they're looking for.
When you first join Nostr, your client likely connects to one or more well-known indexers. purplepag.es, relay.nostr.band, and others serve this role. They help you find your friends, discover interesting topics, and bootstrap your relay list.
But here is the crucial point: indexers are just relays. They have no special status in the protocol. They have no power to censor or control. If an indexer becomes unreliable or hostile, clients can simply stop using it. New indexers can appear at any time. The network does not depend on any single indexer.
This is the same pattern we saw with relays in general: specialization without centralization. Indexers provide a useful service, but they do not become choke points. They are replaceable. They are optional. They are just another flavor of relay.
The bootstrap problem is never fully solved—new users will always need some way to get started—but it is continuously resolvable. As long as there is at least one indexer somewhere that a client trusts, the network remains accessible.
ActivityPub's Lessons and Nostr's Divergence
The comparison with ActivityPub is instructive. ActivityPub is the protocol that powers the Fediverse—Mastodon, PeerTube, Pixelfed, and dozens of other platforms. It is a beautiful piece of engineering, and it has proven that federated social media can work at scale.
But ActivityPub makes a choice that Nostr does not: it assumes federation. In ActivityPub, servers are expected to talk to each other, to exchange messages, to maintain shared timelines. This is baked into the protocol. It is not optional.
This choice has consequences. To participate in the Fediverse, you must either run your own server (which is hard) or find someone else's server to join (which requires trust). Your identity is tied to that server. If the server goes down, your identity goes with it. If the admin becomes abusive, you must migrate—a process that is technically possible but socially painful.
Nostr takes a different path. It does not assume federation. It does not require it. It does not even particularly encourage it. Relays can federate if they want, but they don't have to. Users can publish to multiple relays simultaneously, ensuring that their content survives even if any single relay fails. Identity is tied to keys, not servers. You can switch relays without losing your followers or your history.
The result, I would argue, is a better user experience. Not because the technology is more advanced—ActivityPub is plenty advanced—but because the trust model is simpler. You do not need to learn how to self-host a server. You do not need to depend on an unaccountable admin who might shut down the server at any time. You just create an account—really, you just generate a key pair—and go.
This is the difference between a protocol designed for users and a protocol designed for servers. Nostr was designed for users. ActivityPub was designed for servers that serve users. Both approaches work. But they work differently, and they create different kinds of experiences.
The Client's Role in Discovery
If relays are independent and federation is optional, how do clients actually find anything? The answer lies in client-side intelligence.
Nostr clients are not dumb. They do not simply display whatever a single relay gives them. They aggregate. They filter. They search. They implement sophisticated discovery algorithms that work across multiple relays.
Consider a client trying to build a feed of posts from people you follow. It collects the public keys of your follow list. It looks up each user's relay list (their kind 10002 event). It groups users by which relays they use. It sends batch queries to each relay, asking for recent posts from all the users who publish there. It merges the results, sorts them by timestamp, and displays them in a unified feed.
This is the outbox model, and it works. It works even if no two users share a single relay. It works even if every user publishes to their own private server. It works because the client is smart enough to go where the data is, rather than expecting the data to come to a central location.
Discovery beyond your follow list is similarly client-driven. Clients can query indexers to find new users. They can search for topics across multiple relays. They can follow recommendations from trusted sources. They can implement any algorithm their developers can imagine.
The point is that the intelligence is in the client, not the network. This is the opposite of centralized platforms, where the network is smart and the client is dumb. In Nostr, the network is dumb—it just stores and forwards events—and the client is smart. This inversion is what makes the system so flexible and so resilient.
The Trust Model Summarized
Let us now state the trust model explicitly.
At the protocol layer, you trust no one. The rules are public, the signatures are verifiable, and the code is open source. You can verify everything yourself.
At the relay layer, you trust the operators you choose. You trust them to store your events, to serve them to others, and to respect your privacy (if that matters to you). You can verify this trust by running your own relay, or you can spread your trust across multiple relays so that no single operator has complete power over you.
At the client layer, you trust your client software. You trust it to handle your keys securely, to connect to the relays you specify, and to display events honestly. You can verify this trust by using open source clients, by auditing the code yourself, or by writing your own client.
At the user layer, you trust yourself. You trust yourself to protect your keys, to choose your relays wisely, and to navigate the network in a way that serves your goals.
This is not a trustless system. Bitcoin taught us that trustless systems are possible for money, but communication is different. Communication requires relationships. Relationships require trust. The goal is not to eliminate trust, but to distribute it so widely that no single betrayal can destroy you.
Why This Matters for Censorship Resistance
The distinction between decentralized protocol and federated relays is not merely academic. It has real consequences for censorship resistance.
In a federated system like ActivityPub, censorship is server-level. If your server decides to block someone, they are blocked for everyone on that server. If a government decides to pressure a server operator, that operator becomes a point of failure. The federation can route around it, but only if other servers choose to pick up the slack.
In Nostr, censorship is relay-level but user-controlled. If a relay blocks you, you publish to other relays. If a relay deletes your content, your content survives elsewhere. If a government pressures a relay operator, that operator can comply without silencing anyone—because users will simply stop using that relay and move to others.
This is the advantage of making federation optional. When relays are independent, users can adapt. When the protocol does not care how relays organize, the network can evolve in response to pressure. The attacker must succeed everywhere. The defender need only succeed somewhere.
This is not theoretical. It has been tested. Relays have been pressured. Content has been deleted. Users have migrated. The network has survived. It survives because its trust model does not depend on any single actor's good behavior.
The UX Argument
Let me end with a claim that may be controversial: Nostr has better user experience than ActivityPub for the basic reason that you do not need to learn how to self-host a server or depend on an unaccountable admin that might shut down the server at any time. In Nostr, you just create an account and go.
This is not to say that Nostr's UX is perfect. It is not. The client ecosystem is still maturing. Discovery is still harder than it should be. Key management is still intimidating for non-technical users. These are real problems, and they are being worked on.
But the fundamental architecture—keys, not accounts; relays, not servers—creates a different kind of relationship between users and the network. Users are not tenants. They are not subjects. They are sovereign individuals who choose their own associations.
This is the user experience that matters most: the experience of control. The experience of knowing that your identity is yours, not leased from some platform. The experience of knowing that you can always find another relay if this one turns against you. The experience of knowing that no admin can wake up one day and decide you're gone.
Everything else is polish. Everything else is UI. The core experience—the experience of sovereignty—is already there.
The Protocol Does Not Care
There is a phrase that appears in discussions about Nostr, often used by its creator and early adopters: "the protocol does not care."
It does not care how relays organize. It does not care what content you publish. It does not care what clients you use. It does not care about your politics, your morality, or your vision for the future.
This indifference is not coldness. It is design. It is the recognition that protocols should enable, not enforce. They should create possibilities, not dictate outcomes.
The protocol is decentralized. Relays are federated (or not). Users are sovereign. The protocol does not care.
This is Nostr's trust model. This is its genius. And this is why it might actually work.
This essay was written for sovereign podcasters, independent journalists, and anyone trying to understand why Nostr's architecture matters. Share it freely. Post it to your relays. Let the network decide.
No single entity can ever control YOUR #Nostr