Nostr Outbox Model (Gossip)

The Nostr Outbox Model, historically called the "gossip" model, is a relay-routing strategy defined by NIP-65 that keeps Nostr decentralized as it scales. Rather than everyone piling onto a handful of large relays — recreating the centralized platforms Nostr exists to escape — each user advertises which relays they write to and which they read from, and clients use that information to route traffic intelligently. It is the difference between a protocol that happens to allow many relays and one whose usage pattern actually keeps many relays relevant.

How NIP-65 expresses it

A user publishes a replaceable kind 10002 event — their relay list — containing r tags, each holding a relay URL with an optional read or write marker (a tag with no marker means both). Clients then follow a simple routing rule: to publish your notes, send them to your own write relays; to find someone else's notes, read from their write relays; and to reach a specific person with a mention or reply, write to their read relays. Because the relay list is itself an ordinary Nostr event, it propagates across the network like any other note, so no central directory of relays is required — the routing table is self-describing and travels with the identity it describes. The specification recommends keeping each list small, around two to four relays per category, which keeps the network's fan-out efficient: a client following a hundred people queries the union of their write relays, not every relay in existence.

Why it matters for sovereignty

The Outbox Model means a user's content lives wherever that user chooses, not on a relay a platform controls. If a popular relay goes down, starts charging, or de-platforms someone, followers' clients simply fetch that person's notes from their other write relays — the identity, anchored in the keypair (npub/nsec), never depended on any single host. Censorship stops being a platform decision and becomes a coordination problem an individual can route around by editing one event. The logical endpoint is running your own relay and listing it as a write relay: your words then live first on hardware you own, with public relays serving as distribution rather than custody. That is the same instinct as running your own Bitcoin node — hold the primary copy, let the network mirror it.

Practical notes

Outbox support varies across clients; those that honour NIP-65 find people reliably across relay boundaries, while naive clients only see what happens to sit on their configured defaults — worth checking before you blame the protocol for missing notes. Keep your relay list realistic (relays you actually use, that actually accept your events), and remember that reads leak metadata: the relays you query learn what you ask for, one reason small personal relays and paid relays with policies you trust both have a place. This routing logic is also what makes metadata-private messaging deliverable in practice; see how relay lists drive delivery in NIP-17 (Private Direct Messages).

The model also changes what "identity" needs from infrastructure. Because followers locate you by your key plus your published relay list — optionally humanized through a NIP-05 identifier — there is no username database to seize and no platform whose goodwill your reachability depends on. Moving providers is editing an event, not migrating an account. That is the property to evaluate any "decentralized" social protocol against: not whether many servers exist, but whether leaving one of them costs you anything. By that measure, outbox routing is what turns Nostr's federation of relays from a hosting detail into an actual guarantee.