• You Don’t Know What You’re Missing
• Authors Know Where They Post
• How Do You Find the List?
• The Implementation: What Clients Actually Do
• Privacy, Scale, and Control
• Embrace the Chaos

Now imagine trying to find a specific book by a specific author in this library. You don’t know which building has it. You don’t know if the building will let you in. You don’t know if the copy they have is complete or if someone tore out the pages you need. You don’t even know if the author is still writing books, or if they’ve given up and started a podcast instead.

This is Nostr. This is the problem. This is what the Outbox Model solves.

§You Don’t Know What You’re Missing

When Nostr first appeared, people did what people always do: they found the path of least resistance. A handful of relays became the default. relay.damus.io, nos.lol, relay.nostr.info. Everyone posted to them. Everyone read from them. It worked well enough, for a while.

But “well enough” is a trap. It creates the illusion of functionality while concealing systemic failure. You see the notes that made it to the relays you’re connected to. You don’t see the notes that didn’t. And because you don’t see them, you don’t know they exist. You don’t know what you’re missing. This is the dog that isn’t barking. This is the silence that confirms nothing is wrong, precisely because everything is wrong.

The problem becomes visible only when it becomes acute. When someone you follow stops appearing in your feed. When replies to your posts go missing. When quoted notes show up as empty boxes. When you realize that your experience of Nostr is not Nostr itself, but a highly filtered, arbitrarily truncated subset determined entirely by which relays you happened to pick when you first installed your client.

The natural response is to add more relays. If ten relays give you 90% coverage, surely a hundred relays will give you 99%. This is wrong, but it feels right. It feels like trying harder. It feels like solving the problem through sheer effort.

What actually happens is you open a hundred WebSocket connections. Your bandwidth usage spikes. Your client slows to a crawl. Your battery drains. And you still miss content, because the relays you added are just more of the same—more duplicates, more overlap, more noise, but not necessarily more signal from the specific people you actually want to hear from.

The other natural response is to post to more relays. If you want people to find your content, spray it everywhere. This is what services like Blastr did: accept your event and forward it to hundreds of relays. Now every relay has a copy of your note. Storage requirements explode by orders of magnitude. And the read side of the problem gets worse, because now every relay has even more duplicate content, making it even harder to find anything unique.

This approach is guessing. On the read side, you’re guessing which relays might have the content you want. On the write side, you’re guessing which relays people might use to find your content. Both sides are guessing, and both sides are wrong.

§Authors Know Where They Post

The Outbox Model, originally proposed by Mike Dilger and now codified as NIP-65, starts from a simple observation: the person who knows where to find an author’s content is the author themselves.

This is obvious, once you think about it. If you write things, you know where you put them. You know which services you use. You know which servers you trust. You know which jurisdictions you’re willing to subject your words to. Why should everyone else have to guess?

The model works like this: every user publishes a special kind of event—kind 10002—that lists the relays they use. Not the relays they read from, not the relays they think are cool, not the relays they heard about from a friend. The relays they actually, personally, intentionally post their content to.

This list has two categories: “write” relays (where the author posts their own content) and “read” relays (where the author expects to receive replies and mentions). The distinction matters. Your outbox is where you put things. Your inbox is where you accept things from others.

When someone wants to find your content, they look up your kind 10002 event, take the list of your write relays, and query those directly. Not random relays. Not popular relays. Not the relays they happen to be connected to. Your relays. The ones you chose. The ones you use.

When someone wants to reply to you or mention you, they look up your kind 10002 event, take the list of your read relays, and post a copy there. Not to their own relays. Not to random relays. To your inbox. Where you’ll actually see it.

This is not complicated. This is not novel. This is how the web has worked since the beginning. You have a website. People visit your website to see your content. If they want to reply, they have their own website. This is the original model. This is the model that worked before platforms centralized everything into walled gardens.

§How Do You Find the List?

Of course, there’s a catch. To find someone’s relay list, you need to know which relays have that list. This is the bootstrapping problem. You need the thing to find the thing.

The solution is not elegant, but it works: you guess. But you guess intelligently, and you guess only once.

When you first encounter a pubkey—through a mention, a quote, a manual entry, a QR code—your client needs to find that user’s kind 10002 event. To do this, it queries a small set of well-known “indexer” relays. purplepag.es, relay.nostr.band, a handful of others. These relays specialize in storing metadata and relay lists. They’re the card catalog for the library.

This is a compromise. It’s a form of centralization. But it’s a shallow, weak, easily escapable form. If these indexer relays disappear or become hostile, users can share relay lists through other means. Through NIP-05 DNS records. Through manual entry. Through out-of-band communication. Through embedding relay hints in other events. Through any mechanism client developers can imagine.

The important thing is that once you have someone’s relay list, you no longer need the indexers for that person. You go directly to their chosen relays from then on. The indexers are a bootstrap, not a dependency.

§The Implementation: What Clients Actually Do

A client following the Outbox Model does something like this:

When you want to see notes from people you follow, the client collects all their pubkeys, looks up their most recent kind 10002 events (falling back to indexers if necessary), groups the pubkeys by which relays they use, and sends batch queries to each relay asking for notes from all the users who listed that relay as a write relay.

This is efficient. Instead of opening a connection to a hundred relays and hoping for the best, the client opens connections to exactly the relays that actually have the content you want, and requests exactly the content you want from each one.

When you post a note that mentions someone, the client looks up that person’s read relays and sends a copy to each one. Not to your relays. Not to random relays. To their inbox. Where they’ll see it.

When you post a note that doesn’t mention anyone, the client sends it to your write relays. That’s it. No spraying. No duplication. No waste.

The NDK library, which implements this model, describes it as giving Nostr “decentralizing tendencies by default.” The model is transparent to developers once enabled. It just works, in the background, making better decisions about where to look for content and where to put it.

§Privacy, Scale, and Control

Every model has trade-offs. The Outbox Model is no exception.

The privacy concern is real. When your client connects to someone else’s chosen relays to fetch their content, those relays see your IP address. They see what you’re requesting. They can build a profile of what you read and who you follow. This is exactly the same privacy exposure as visiting someone’s website—and the solution is exactly the same: use Tor, use a VPN, use any of the tools already designed to solve this problem. It is not Nostr’s job to reimplement privacy at the protocol level when perfectly good solutions already exist at the network level.

The scale concern is also real. If you follow ten thousand people and they all use different relays, your client might need to connect to thousands of relays simultaneously. This is impractical on mobile devices and impossible in browsers. But this is a theoretical problem, not a practical one. In reality, people cluster. They use similar relays. They follow people with similar interests who use similar infrastructure. The number of distinct relays needed to cover a follow list is much smaller than the number of followers. And as the network grows, it will naturally tend toward a smaller number of larger relays—not because of centralization pressure, but because of economics and convenience. This is fine. This is healthy. As long as it remains possible to run a new relay, the escape hatch remains open.

The control concern is perhaps the most interesting. In the Outbox Model, authors control where their content lives. They choose the relays. They can change them. They can add redundancy. They can move if a relay becomes hostile. This is power that users of centralized platforms do not have. This is sovereignty.

§Embrace the Chaos

Nostr is not a platform. It is not a product. It is a protocol. And protocols do not guarantee outcomes—they enable possibilities. The Outbox Model does not guarantee that you will see every note from every person you follow. It guarantees that if you want to see them, there is a way. It guarantees that the failure modes are visible, not hidden. It guarantees that when things break, you can understand why and you can fix them.

This is uncomfortable for people accustomed to platforms that hide complexity behind polished interfaces. But it is also liberating. In a platform, you are a user. In a protocol, you are a participant. You have agency. You have choice. You have responsibility.

The Outbox Model is not a finished solution. It is a direction. It is a set of incentives and affordances that push the network toward decentralization without mandating it. It is a way of thinking about content discovery that respects the fundamental nature of Nostr: that it is a mess, that it will always be a mess, and that the mess is the point.

Because in the mess, there is freedom. In the chaos, there is resilience. In the thousand relays, each with its own rules and its own community and its own quirks, there is the possibility of something that actually belongs to the people who use it.

The Outbox Model is how we find each other in that chaos. It is how we build tribes across a thousand servers. It is how Nostr becomes not just a replacement for Twitter, but something new entirely.

And that is worth a little complexity.