NIP-65: Relay Lists, Outbox, and Inbox — Routing Beyond One Home Relay

Nostr has no global timeline server. Events are signed objects; relays are optional storage and fan-out. The folklore that follows is sticky: pick one “home relay,” mirror everything there, and hope the network finds you.

That story collapses under ordinary use. Authors publish to a small set of places they can afford to keep online. Mentions and replies need a different set — places the author actually reads. Friends live on other relays. A client that only knows NIP-11 relay capability docs still does not know where Alice writes or where Bob expects tags.

NIP-65 — Relay List Metadata — is the living optional answer: a replaceable kind:10002 event that advertises per-pubkey write and read relays. This note is protocol literacy about that routing layer. It is not a recruitment pitch to “join Nostr now,” and it deliberately sits beside (not inside) the companion note on NIP-11 relay information documents.

What NIP-65 actually defines

The canonical NIP text (draft, optional) defines a replaceable event of kind:10002 whose job is to advertise relays where the user generally writes, and relays where the user generally reads mentions. The content field is empty. The signal lives in tags.

Each relay is an r tag:

• ["r", "wss://example.relay"] — marker omitted → both read and write
• ["r", "wss://example.relay", "write"] — outbox / publication target
• ["r", "wss://example.relay", "read"] — inbox / mention target

NIP-01’s kind ranges classify 10000 <= n < 20000 (and kinds 0 / 3) as replaceable: for each (pubkey, kind) pair, relays MUST keep only the latest event; older versions MAY be discarded. So kind:10002 is a single authoritative list per pubkey at a time — not a growing history of preferences. NIP-51’s lists table names the same kind as “Read/write relays” and points at NIP-65 for tag semantics.

A minimal shape (from the NIP example, URLs illustrative):

{
  "kind": 10002,
  "tags": [
    ["r", "wss://alicerelay.example.com"],
    ["r", "wss://brando-relay.com"],
    ["r", "wss://expensive-relay.example2.com", "write"],
    ["r", "wss://nostr-relay.example.com", "read"]
  ],
  "content": ""
}

Clients SHOULD guide users to keep lists small — about 2–4 relays of each category. Huge lists recreate the “connect to everything” failure mode the outbox model was meant to exit.

Outbox versus inbox — the routing rules

NIP-65’s SHOULD behaviours are the outbox/inbox model in concrete form:

1. Events from a user — when downloading what someone authored, clients SHOULD use that user’s write relays (their outbox).
2. Events about a user — when looking for mentions/tags of someone, clients SHOULD use that user’s read relays (their inbox).
3. On publish, clients SHOULD:
   • send the event to the author’s write relays
   • send the event to each tagged user’s read relays
   • also publish the author’s kind:10002 to the same relays the event went to (so relay lists travel with content)

That split is the whole point. Write relays are where your notes land for people who follow you. Read relays are where others should drop replies and mentions so you see them without scanning the entire network. A relay can appear in both roles (omitted marker), or only one.

Call this the outbox model in the narrow NIP-65 sense: discovery is keyed off signed metadata per pubkey, not off a single shared “main” relay everyone must share. Gossip still needs bootstrap — you have to fetch someone’s 10002 from somewhere before you can prefer their outbox — but once you have it, routing becomes directed instead of flood-and-pray.

Why NIP-11 alone cannot route you

NIP-11 answers a different question: what does this relay claim it can do? Supported NIPs, limits, auth, payment gates, contact keys — self-reported HTTP metadata for a relay URI.

NIP-65 answers: for this pubkey, which relays matter for write versus read? It is an event, signed by the user, replaceable, gossiped. A perfect NIP-11 document on wss://popular.example does not tell you whether Alice ever publishes there. Conversely, Alice’s kind:10002 does not tell you that relay’s max_subscriptions or auth_required.

Good clients use both layers:

• NIP-11 to decide whether a candidate relay is usable (limits, policy, features).
• NIP-65 to decide which candidates to open for a given author or mention graph.

Treat either as gospel alone and you get silent empty feeds or failed publishes that look like “Nostr is broken” when the client simply asked the wrong sockets.

Replaceable lists, discoverability, and bootstrap

Because kind:10002 is replaceable, updating your relay preferences is publishing a newer event with the same kind — not appending. Clients and relays that follow NIP-01’s replaceable convention surface the latest list.

Discoverability is explicit in NIP-65: clients SHOULD spread an author’s kind:10002 to as many relays as viable, especially relays that currently act as well-known public indexers for these lists — places many clients already hit to publish or fetch relay metadata. Without that spread, your outbox preference is a secret only your laptop knows. With it, strangers can find your write relays without you sharing a personal “home server” URL out-of-band.

Bootstrap remains social and opportunistic: follow lists (kind:3), relay hints on p/e tags (NIP-01), and indexer-ish relays all help you locate the first 10002. NIP-65 does not invent a DHT. It standardises what to do after you have the list.

NIP-51 also notes related but distinct lists — for example kind:10050 DM receive relays (NIP-17), blocked relays (10006), search relays (10007). Do not confuse “my general write/read advertisement” with “where I want encrypted DMs” or “relays I refuse.” Same family of list kinds; different jobs.

What breaks when clients ignore the model

If clients ignore NIP-65 and only hammer a hardcoded public set:

• Authors on quieter or paid write relays never appear in followers’ feeds.
• Mentions land on relays the recipient never opens — “I replied, they ghosted” becomes a routing bug.
• Everyone piles onto a few popular relays, recreating the centralisation folklore claimed to avoid.
• Bandwidth and battery burn on wide REQ filters against relays that never held the target author’s notes.

If users treat one relay as magical home without advertising 10002, even careful clients cannot prefer their outbox. The metadata is part of the social contract: signed preference, small list, republished when it changes.

Civil-liberty stakes are concrete without geography theatre. When speech infrastructure is fragmented — uneven hosting, aggressive local moderation, or fragile transit — routing literacy matters more than a single branded relay. You want mentions delivered to relays you actually monitor, and your notes discoverable on relays you control or trust enough to write to — without forcing every reader through one choke point. NIP-65 is that preference surface; it is not immunity from seizure, spam, or dishonest relays.

What this is not

This note is not a client install guide, a ranked relay list, or a “best relays of 2026” shopping post. It does not claim NIP-65 is finished, universally implemented, or sufficient for DMs, search, or media. It does not equate replaceable relay lists with censorship resistance or anonymity. It does not advise paying for relays as an investment, nor treat pay-to-relay flags (a NIP-11 concern) as financial products. It does not teach evasion of lawful process. It does not replace verifying event signatures or reading a relay’s live behaviour after its NIP-11 claims.

Educational takeaway: capability ads (NIP-11) and routing ads (NIP-65) solve different problems. Home-relay folklore flattens both into one URI. The protocol keeps them apart on purpose.

Related on CryptoDecentral

• Nostr pillar
• NIP-11: How Nostr Relays Advertise What They Can Do
• Network metrics

Further reading (primary)

• NIP-65 Relay List Metadata (raw)
• NIP-65 on GitHub
• NIP-65 HTML mirror
• NIP-01 Basic protocol flow
• NIPs README (kind registry)
• NIP-51 Lists