NIP-65: Relay List Metadata
Clients need to know where to look for a person
Nostr is not one database. If Alice writes to one set of relays and Bob listens on another, clients need a way to discover where Alice's events usually appear and where Alice expects mentions to arrive. NIP-65 gives each user a small relay map.
The replaceable kind 10002 event lists relay URLs with optional read or write markers. Write relays are where the user generally publishes. Read relays are where the user expects to receive events about them, such as mentions.
This is why NIP-65 is central to the outbox model. Instead of blasting every event to every relay, clients can route more intelligently: fetch from an author's write relays, publish mentions to tagged users' read relays and spread the relay-list event so others can discover it.
Kind 10002 with read and write relay hints
The event contains r tags. The first value is the relay URL. The optional marker is read or write. If omitted, the relay is both read and write. The content field is empty.
When downloading events from a user, clients need to use the user's write relays. When downloading events about a user, clients need to use that user's read relays. When publishing, clients need to send the event to the author's write relays and to the read relays of tagged users.
The standard also tells clients to keep lists small, usually two to four relays per category, and to spread the author's kind 10002 event to the relays where the event was published.
From feed advertisements to the outbox model
Mike Dilger added the visible feed-advertisement work in February 2023 and quickly refined read and write relay meaning. Vitor Pamplona simplified NIP-65 in August 2023. Later changes normalized relay URLs, defined read/write punctuation more clearly and linked outbox model articles.
In April 2025, fiatjaf shrank the NIP so it was clearer, and Awiteb added a note about republishing kind 10002. That simplification matters because NIP-65 is infrastructure many clients have to get right.
The outbox model is one of the big answers to Nostr's relay discovery problem. NIP-65 is the user's own piece of that answer.
Relay routing is a product feature, not a hidden setting
A client implementing NIP-65 needs to keep a user's relay list fresh, publish it broadly enough to be found, avoid enormous relay lists and route events according to read/write intent. If a user tags ten people, the client has to think about each recipient's read relays.
The classic implementation failure is treating all relays as global defaults. That wastes bandwidth and misses people. The other failure is treating kind 10002 as private preference when it is really public routing metadata.
Good UI needs to explain which relays are used for publishing, which are used for mentions and when a client is republishing the relay-list event for discoverability.
Relay lists reveal habits and can go stale
NIP-65 relay lists are public routing hints. They can reveal communities, paid relay use, private relay preferences or geography-like behavior. That is often acceptable, but it must not be invisible to users.
Stale relay lists are another problem. If a user changes relays and clients keep using old data, mentions and replies go missing. Relay-list refresh is not polish; it is message delivery.
Read NIP-65 in the wild
NIP-65 tells clients where a user tends to read and write. That relay-list metadata is one reason a profile can remain reachable when you switch apps.
Stale relay lists make Nostr feel broken. Show update time, read/write purpose and repair paths, because the difference between an empty profile and a bad relay route is invisible to most people.
What changes when you actually use it
For you, NIP-65: Relay List Metadata is felt when a relay accepts, rejects, indexes, hides, charges for or returns events. Relays are not passive pipes. They make policy and infrastructure choices that shape what a client can show. The source terms kind 10002, draft, kind:10002, read, write matter because they are the narrow places where a product can distinguish a relay decision from a network failure.
What changes for builders and operators
For builders and operators, NIP-65: Relay List Metadata is observability. Log what the relay accepted, rejected, counted, authenticated or refused. Then show enough of that to users so they can repair configuration instead of assuming Nostr is empty or broken.
What the official file makes concrete
The official file is organized around Size, Discoverability. Inspect kind 10002, draft, kind:10002, read, write because these are the pieces most likely to surface as product behavior.
NIP-65: Relay List Metadata belongs to infrastructure, not scenery. Acceptance, indexing, authentication, retention, payment and filtering all shape what you actually see.
Where it breaks
The failure mode in NIP-65: Relay List Metadata is blaming the network for one server's policy. A relay may reject an event for payment, spam, size, auth, retention or software reasons. If the client collapses those cases into one empty state, the user loses the ability to act.
Where this appears outside the markdown
In the ecosystem, NIP-65: Relay List Metadata lives where users rarely look and operators spend real money: websocket services, relay policies, indexes, rate limits, authentication, monitoring and retention. A good hub page has to make that infrastructure readable because relay behavior decides whether Nostr feels alive, empty, expensive or hostile.
The nearby-standard trap
The nearby-standard trap in NIP-65: Relay List Metadata is treating all relay standards as one reliability story. Discovery, authentication, information documents, search, counts, monitoring and management each expose a different slice of relay behavior. Read NIP-01 and the adjacent source links before calling a relay 'good' or 'broken'.
Language that keeps the feature honest
Good product copy for NIP-65: Relay List Metadata names the relay decision. It says whether access, payment, indexing, search, storage, rate limit, auth or policy shaped the result. That language gives you something to fix instead of making the network feel mystical.
What this page does not promise
NIP-65: Relay List Metadata does not make every relay equal. A relay can be public, paid, local, archival, search-oriented, authenticated, heavily moderated or almost disposable. The standard gives clients and operators a way to communicate one part of that behavior. It does not replace uptime checks, policy reading, payment terms, retention expectations or the practical question of whether your own events can be found later.
Read it as a field test
Start NIP-65: Relay List Metadata with the server behavior you can observe: accept, reject, count, search, authenticate, limit, store, delete or report. Then connect it to kind 10002, draft, kind:10002, read, write. A relay NIP becomes readable when it explains what a relay can honestly promise and what still depends on policy, money and operations.
Where the standard earns trust
The source links give you places to test the interpretation in public: Mike Dilger: gossip model, Mike Dilger: Nostr relays, NIP-65 design issue, NIP-11 Relay Information. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-65 source is the anchor for exact wording, and NIP-65 commit history shows how that wording moved over time. The strongest secondary clues here are Mike Dilger: gossip model, Mike Dilger: Nostr relays, NIP-65 design issue. Treat this evidence chain as part of the article, not as footnotes. A NIP page becomes useful when you can move from claim to source to working behavior without guessing.
Keep the chain visible for NIP-65: Relay List Metadata: first the human promise, then kind 10002, draft, kind:10002, read, write, then the implementation record, then the real-world failure case. That order keeps NIP-65 useful without turning it into marketing copy or protocol trivia.
Three questions to carry forward
- What exact relay behavior is being described: discovery, auth, search, count, information, payment, moderation or management?
- Can you see whether a failure came from policy, payment, indexing, rate limit, auth or downtime?
- Does the relay expose enough public information for you to decide whether it belongs in your own relay set?
What to verify before you rely on it
- Find
kind 10002,draft,kind:10002,read,writein the official file and check where the UI exposes the same concept. - Read NIP-01 and the adjacent source links as context before treating NIP-65 as a complete product story.
- Open at least one implementation, mirror, pull request or library source from the source links before trusting that the idea is mature.
- Test the unhappy path: missing relays, stale metadata, invalid signatures, blocked events, expired state, revoked permissions or unavailable media.
- Write the user-facing copy in plain language. If a standard changes authority, privacy, money, moderation or recovery, say that before the click.
Direct sources
Use these sources for NIP-65: Relay List Metadata in that order: Official NIP-65 source for the current wording; NIP-65 commit history for the change record; Mike Dilger: gossip model, Mike Dilger: Nostr relays, NIP-65 design issue for public context. The article gives you the consequence in plain language, but the source trail is where exact fields, status notes, unresolved debates and implementation proof stay checkable.
