NIP-65: Your Relay List Is Part of Your Identity
Relay list metadata is how your public key tells the rest of the network where to look. It is not glamorous, but it is one of the standards that makes portable identity feel real instead of theoretical.
Your key is not a GPS signal
A Nostr public key identifies you, but it does not automatically broadcast where every event can be found. That is one of the first surprises in serious Nostr use. Your key can sign a note, a profile update, a relay list, a long-form post, a zap request, a group event or an app-specific event. The signature says the event belongs to you. It does not tell every client which relay should be asked first.
Old platform habits hide this problem. On a centralized network, one company owns the database and the feed. If the post exists, the platform knows where it is because the platform is the place. Nostr separates identity from storage. That gives you exit, but it also means discovery needs routing. A valid event can exist on one relay and feel invisible to a client that never queries that relay.
NIP-65 is the standard that makes your relay route public. It lets your key publish relay list metadata: a replaceable event that names the relays you want others to know about. A client can read that event and learn where you write, where you read or where you expect your events to be found. The result is not perfect routing, but it is a huge improvement over guessing.
This is why relay lists should be treated as part of your operational identity. Your profile name tells people how to recognize you. Your public key proves which events are yours. Your relay list tells clients where to look. If that list is stale, bloated or missing, your identity may still be valid while your presence feels broken. That distinction matters for creators, communities, businesses, venues and anyone using Nostr for more than casual testing.
The standard is small, but the consequence is large: you are not only publishing content; you are publishing part of your map. Keep the map clean and other clients have a better chance of finding you. Let the map rot and people may assume you are quiet, censored, gone or hidden behind an app problem.
What NIP-65 actually publishes
NIP-65 uses relay list metadata as a signed replaceable event. In practice, the event names relay URLs with r tags and can mark relays for read, write or both. That tiny distinction does a lot of work. A write relay is a place where you publish your own events. A read relay is a place where you want others to look for events or where you read from. If no marker is used, clients can treat the relay as usable for both roles, depending on implementation.
The event is signed by your key, so it can travel across clients. That is the entire point. Relay preferences should not be trapped inside one app's local settings. If you move from a mobile client to a web client, or from a casual client to a publishing tool, the new app should be able to read your relay list and understand your route through the network. You should not have to rebuild your identity's infrastructure map every time you change interfaces.
NIP-65 also improves on older habits. Early clients often stuffed relay hints into contact lists or local configuration. That worked when the network was smaller and most people used similar public relays. It does not scale well when people use paid relays, personal relays, local venue relays, search relays, wallet relays and community-specific rooms. The relay list needs its own object because the infrastructure graph deserves its own attention.
Replaceability matters too. You do not want a permanent pile of historical relay hints with no clear latest version. You want a current list that can be updated as your setup changes. If you leave a dead relay, join a paid relay, add a local community relay or change your publishing home, your relay list should change with you. The network should learn the new route.
The standard still depends on client behavior. A relay list is useful only if clients publish it correctly, read it consistently, respect read/write markers, handle failures and avoid overwriting it carelessly. NIP-65 gives the map format. Good software has to make the map reliable.
Read and write are different jobs
Read and write markers are not protocol decoration. They describe different directions of trust. A write relay is where you put events. A read relay is where other people might retrieve events or where your client wants to read. Those roles can overlap, but they should not be confused. A relay that is excellent for publishing may not be ideal for broad reading. A relay used for search or discovery may not be the place where you should write every event.
Imagine you publish through a paid relay for durability and through a public relay for reach. Your write list can name both, because both receive your events. You might also read from public relays where your friends publish. Those read relays are part of your experience, but they are not necessarily places where your own events should be expected. A client that ignores the distinction can create noise and missed expectations.
The distinction also matters for local relays. A venue might ask you to write local event comments to a venue relay while your public notes still go to broad relays. You may want clients to read local context there when you are inside that place, but you do not want the local relay to become the only global route to your public identity. Markers help software preserve that nuance.
Wallet and service relays make the difference even sharper. A Nostr Wallet Connect relay may carry encrypted wallet messages, not normal public social events. If a client treats that relay as a general write target because it appears in a list somewhere, the experience gets weird fast. Relay roles need to stay legible. NIP-65 gives clients a way to make that legibility machine-readable.
When you review your own list, ask the direct question: why is each relay here? If the answer is “I publish there,” it is a write role. If the answer is “I read friends there,” it is a read role. If the answer is “I do not know; an app added it,” it probably needs inspection. A relay list should be a map, not sediment.
Outbox discovery starts here
Outbox discovery is the idea that a client should look where the author says they publish. Instead of asking a random global set of relays for every profile, the client can read the author's relay list and query those relays first. That is more efficient, more respectful of niche relay choices and more compatible with a network where people do not all live on the same default servers.
The “outbox” framing matters because it centers the author's route. In a centralized network, the platform owns the feed and the outbox. In naive Nostr use, everyone throws events at famous public relays and hopes followers query the same places. In a mature Nostr setup, your relay list tells clients where your outbox is. The feed becomes something clients assemble by following many people's maps.
This is how Nostr can grow without forcing every relay to become universal. A creator can publish on a personal relay, a paid archive and a public reach relay. A local community can use a venue relay. A group can use a moderated relay. A wallet app can use a specialized relay. Outbox-aware clients can still find the right places because the public keys publish hints.
Outbox discovery also reduces waste. Without it, a client might query a giant set of relays for every contact, creating traffic, latency and duplicate work. With it, the client can ask better questions: where does this person write, which relays are alive, which ones returned data recently, and which fallback relays make sense? Better routing is not only nicer for users; it is kinder to infrastructure.
The model still needs humility. Some users have no relay list. Some lists are stale. Some relays are down. Some clients publish poor markers. Some people deliberately avoid exposing too much relay context. Outbox discovery should be a strategy, not a dogma. It gives clients a better first move, not an excuse to ignore failure handling.
The social graph has infrastructure
Nostr often talks about the portable social graph: your public key, follows, profile and events can move across clients. NIP-65 adds a harder truth: the social graph has infrastructure. It is not enough to know who follows whom. A client also needs to know where those people publish and where their events can be read. The social graph and relay graph are intertwined.
That sounds technical, but the user consequence is ordinary. You follow someone. Your client should show their notes. If the client does not know their write relays, it may miss them. If their relay list points to dead endpoints, it may show an old profile. If the person uses a paid or private relay, you may need auth or access. If the person's community uses a local relay, you may see context only when the client respects that route.
This means discovery is no longer one global search box. It is a negotiation among identity, follows, relay lists, liveness, search relays, app defaults and operator policy. That can sound messy, but it is also what makes the network flexible. People can choose different storage and policy layers without losing their public key. The price is that clients must become better map readers.
For creators, this changes publishing practice. If you treat your relay list as an abandoned setting, your audience may split across clients. If you keep it current, your work is easier to find beyond the app you used to publish it. For communities, relay lists make local rooms discoverable without forcing identity into a closed account system. For businesses, relay lists are part of operational reach.
The big mistake is pretending infrastructure is beneath social life. On Nostr, infrastructure is part of social life. Your relay choices decide which conversations feel present, which archives survive, which local spaces feel alive and which clients can follow you into the next interface.
Good lists are short on purpose
A relay list should be long enough to make you findable and resilient, but short enough to stay meaningful. Endless lists look powerful and often behave badly. They slow clients, create duplicate traffic, leak more of your behavior to more operators and make it hard to know which relays are actually important. A good list is not a trophy shelf. It is a working route.
Start with roles. One or two broad public relays can help reach common clients. One personal or paid relay can help durability. One local relay can support a place or community when relevant. A search relay may help discovery, but it is not a normal publishing home. A wallet relay should stay in the wallet lane. A group relay should stay tied to group behavior. If a relay has no role, remove it or mark it as temporary.
Short lists also make failure easier to understand. If you publish to five relays and one fails, you can inspect the failure. If your client sprays to fifty, the UI may hide real problems behind noise. You will not know which relay mattered, which relay rejected the event, and which relay kept the copy you need later. Operational clarity comes from fewer, better choices.
That does not mean everyone needs the same number. A casual user may need a small default set. A creator with long-form work may need a dedicated archive. A venue operator may need local relays plus public announcements. A client developer may maintain test relays. A business may separate public, internal, payment and archive surfaces. The point is intent, not austerity.
When you look at a relay list, it should tell a story you can explain. “These two help people find me. This one preserves my work. This one belongs to my community. This one supports a specific app flow.” If the story is “I clicked things for a year,” the list needs repair.
Public, paid, local and personal relays belong together
NIP-65 becomes most useful when your relay setup has more than one kind of place. Public relays give reach. Paid relays can fund durability and spam resistance. Personal relays give control. Local relays give place-based memory. None of those roles replaces the others. The relay list is where they can sit together without pretending to be the same thing.
Public relays are good for discovery because many clients already know them. They are also under pressure. Spam, abuse, storage costs and free-rider traffic make public relays hard to operate forever. If you care about a post, public reach should not be the only copy. Use public relays for reach, not as a promise that history is safe.
Paid relays make the server bill explicit. A paid relay can offer stricter writes, better retention, lower spam or clearer operator accountability. It can also become a gate. Your NIP-65 list can tell clients where your paid relay lives, but people may not have access to read or write. That is not a contradiction. It is a routing fact that clients should explain.
Local relays let Nostr attach to physical or community contexts. A cafe, club, conference, hotel, coworking space, campus or city group can have a relay for local posts, badges, schedule comments, reputation, offers or operator updates. Your public key still travels. The local relay adds place memory. NIP-65 gives clients a way to know when that relay is part of your route.
Personal relays are the quiet backbone for people who publish seriously. A personal relay or paid personal archive can make your content less dependent on public generosity. It does not replace backups, but it gives your identity a home you understand. A good relay list can combine personal durability with public reach and local context. That is the shape of a mature Nostr setup.
Privacy and leakage
A public relay list is useful because it tells clients where to find you. The same usefulness creates leakage. Your list can reveal which communities, paid services, local spaces or specialized relays you use. For public profiles, that may be fine. For sensitive contexts, it deserves thought. Nostr makes many things portable, but it does not make public metadata private.
This is not a reason to avoid NIP-65 entirely. It is a reason to separate roles. You may not want every private or wallet-related relay in a public social relay list. You may use relays for encrypted or service-specific flows that do not belong in the same public map as your notes. You may want a public relay list for findability and a narrower private configuration for sensitive app behavior.
Read and write markers help, but they do not solve privacy. A marker still names the endpoint. If a local community relay is sensitive, publishing it publicly may reveal membership. If a paid relay is tied to a niche service, it may reveal preference. If a relay is used for a professional project before launch, it may reveal activity. The map is useful because others can read it. Remember that others includes strangers.
Clients should make this visible. When a user publishes a relay list, the UI should explain that it is public. When adding a relay, the UI should ask whether it belongs in the public list or only local settings. When a relay is tied to a wallet, group or private room, the UI should be careful before broadcasting it as part of the user's public identity map.
The practical balance is simple: publish enough to be findable; avoid publishing sensitive infrastructure casually. If your Nostr use is public, NIP-65 is a strength. If your use involves private groups, payments, local member spaces or operational rooms, keep your maps intentional.
When a list goes stale
A stale relay list is one of the most common causes of ghost-like Nostr behavior. Your notes exist, but another client cannot find them. Your profile looks old. Replies appear in one app and vanish in another. A follower thinks you stopped posting. The problem is not necessarily the key, the client or the protocol. It may be that your public map points to relays you no longer use.
Staleness happens easily. You try a new client. It adds defaults. You join a paid relay and forget to publish a fresh list. A public relay dies. A local event relay was temporary. A client overwrites your carefully chosen list. A relay changes policy and now requires payment or auth. Six months later, the list still looks official because it is signed by your key, but it no longer describes your actual route.
That is why clients should show age and health. When was the relay list last updated? Which relays are currently reachable? Which ones accept writes? Which ones return expected events? Which ones have NIP-11 metadata? Which ones have no obvious role? A relay list should feel like a living route, not a hidden relic.
Repair starts with a trusted client or tool. Publish a fresh list. Keep the useful public relays. Add the durable relay you actually use. Remove old junk. Mark read and write roles where the client supports it. Then test from another client. If your latest note can be found from outside your usual app, the map is doing its job.
Stale lists are not a moral failure. They are ordinary maintenance. The danger is pretending maintenance does not exist. Nostr gives you the power to move; NIP-65 gives you the responsibility to tell others where you moved.
What clients should do
A good client should treat relay lists as first-class identity infrastructure. It should publish them carefully, read them before guessing, show roles clearly and protect users from accidental sprawl. Relay settings should not be an intimidating dump of endpoints. They should be an understandable map with labels: write, read, public reach, personal archive, local community, search, wallet, group, test.
When following someone, a client should use that person's relay list as a strong hint. It should also handle missing or stale hints gracefully. If no list exists, use sensible defaults and search strategies. If listed relays fail, try fallbacks and tell the user what happened. If a relay requires payment or auth, do not hide that behind silence. The user does not need every protocol detail, but they deserve a clear reason when discovery fails.
When publishing, a client should show where the event went. Did all write relays accept it? Which rejected it? Which were unreachable? If the relay list was updated, what changed? A publish button that hides relay outcomes makes Nostr feel like magic when it works and chaos when it fails. A publish button that shows relay results turns confusion into action.
Clients should also protect the user's existing list. Overwriting relay lists without explanation is a serious UX mistake. Importing defaults can be useful, but the user should know when public metadata is changing. A client should not silently replace a durable personal setup with its own favorite endpoints. Relay lists belong to the user's identity, not to the app's branding.
Finally, clients should offer cleanup. Show dead relays. Show duplicates. Show relays with no NIP-11 response. Show relays never used for writes. Offer safe removal, but do not pretend every user knows the consequences. The goal is not to make users relay administrators. The goal is to make the map calm enough that normal people can steer.
Your relay-list audit
Start by opening the relay list your main client publishes. Do not only look at local settings. Find the public NIP-65 event if your client exposes it. Write down each relay and its role. If you cannot name the role, mark it for review. If a relay appears twice in different forms, clean it up. If a relay is dead, decide whether it still belongs as a historical fallback or should be removed.
Next, test write behavior. Publish a small harmless note. Watch which relays accept it. If your client does not show per-relay responses, use another tool. A relay in your write list should be more than decorative. If a relay rejects you because payment or auth is required, decide whether to meet that requirement or remove it from the write role.
Then test read behavior from a second client. Can the second client find your profile, latest note and older events? Does it read your relay list? Does it query the relays you expect? If the second client cannot find you, the issue may be its relay behavior, your list, relay liveness or stale cached data. The test is still useful because other people are effectively using second clients every day.
After that, compare NIP-11 metadata for important relays. Are they alive? Do they publish limits? Do they require payment? Do they advertise supported NIPs? Do they name software? A relay list without relay metadata is a weaker map. You may still use the relay, but you should know how little context it gives.
End by simplifying. Keep the relays that have jobs. Add a durable home if your work matters. Keep public reach where it helps. Keep local relays when they are actively useful. Remove forgotten experiments. Publish the cleaned list. Then put a reminder on your calendar to check again. Relay lists are not a one-time setup; they are a small maintenance ritual for a portable identity.
Search relays do not replace the map
Search relays are useful, but they should not become an excuse to ignore NIP-65. A search relay can index events from many places and help you find old notes, profiles, hashtags, long-form posts or public conversations. That is valuable. It is also a different job from telling the network where you actually publish. Search is an index over whatever the search operator has chosen to crawl, accept and retain. A relay list is your signed routing hint.
If a client leans too heavily on search, the user experience starts to look centralized again. One search service becomes the place that “knows” where things are. That may be helpful for discovery, but it is weaker than following authors' relay lists and using search as a supplement. Nostr's resilience comes from many maps and many routes, not from replacing one platform database with one magical index.
Search also has coverage limits. A search relay may miss local relays, private rooms, paid relays, fresh events, events pruned before indexing or event kinds the operator does not care about. It may rank results in ways you do not understand. It may disappear or change policy. None of that makes search bad. It makes search an additional layer, not the foundation of your public route.
NIP-65 gives clients a more author-centered path. Ask where the person says they publish. Use liveness checks to avoid dead endpoints. Use search when the relay list is missing, stale or insufficient. Use directories when you need candidates. Use NIP-11 when you need relay context. Each tool has a role. Problems start when one tool is asked to carry the whole network.
For your own setup, that means you should not assume “people can search for me” is enough. Publish a current relay list. Keep at least one durable write target. Make sure your public work appears where clients can find it without relying on a single search operator. Search helps people discover the map; it should not be the map.
Client switching is the real test
The promise of Nostr becomes real when you switch clients and do not feel like you left your life behind. NIP-65 is one of the standards that makes that possible. If a new client can read your public key, profile metadata, follow list and relay list, it has enough context to begin reconstructing your world. Without the relay list, the new client may know who you are but not where to look for what you have done.
This is why a relay list should not belong emotionally to one app. Your main client may have a tasteful relay UI and good defaults. Great. But the list itself is signed by your key because it should travel. If you move from mobile to desktop, from a social client to a writing tool, from a general app to a local event app, the relay list should help the new interface find your route. Otherwise portability becomes a slogan.
Client switching also exposes bad behavior. If one client silently publishes a bloated list, another client may inherit a mess. If one client overwrites read/write markers, another may query the wrong places. If one client hides failures, another may reveal that half your relays are dead. These moments are annoying, but they are useful. They show whether the ecosystem is respecting your identity map or treating it as app-owned decoration.
A good client-switching test is simple. Open a second client you do not normally use. Import or connect your public identity safely. Let it read your relay list. Check whether your profile, recent notes, replies and older material appear. If they do, your map is working across surfaces. If they do not, inspect which relay hints were missed, which relays failed and whether your main client has been hiding local-only assumptions.
For builders, this is the product standard: do not make people rebuild their relay life in every app. For users, it is the maintenance habit: keep your relay list clean enough that the next client can understand you. For the network, it is the difference between open identity and a collection of isolated app islands that merely share a signing format.
The same test matters for teams and places. If a club, conference, cafe or operator group asks members to use a specific client, the relay list should still make sense outside that client. The local app can offer the best experience, but the identity map should not disappear when someone opens another interface. A member should be able to carry the public key, see which local relay matters, and understand which public relays still carry broader reach.
That portability is where NIP-65 becomes cultural, not only technical. It teaches users that the app is not the network and that relay choices are part of their public presence. When a person can explain their relay list in ordinary language, they are no longer just using Nostr; they are steering it.
Fallbacks belong in that thinking too. A backup relay is useful only if you know when it receives events and when clients should query it. If every fallback is published as a primary write target, your map becomes noisy. If no fallback exists, one outage can make you look absent. The clean pattern is to keep primary relays obvious, backups documented, and dead experiments out of the public list. That discipline helps the next client help you instead of forcing it to guess which endpoint still matters. It also makes your own maintenance easier because each relay has a reason you can remember, test and explain before a real failure arrives. You are not collecting endpoints; you are publishing a working route that should survive your next app change and your next relay outage cleanly.
The same discipline matters when you represent an organization, venue, creator project or community instead of a single personal account. A public brand key may need broad discovery. A staff key may need a private write path. A venue key may need a local relay that makes sense only during operating hours. A project archive may need a durable paid relay and a separate search route. NIP-65 lets those routes be stated by the identity itself, but the list still needs editorial judgment. If every account publishes the same inherited default set, the network learns almost nothing. If each identity publishes the relays that match its real job, clients can begin to show people a cleaner, more honest map.
Sources worth opening
Use these when you want to check the standard, the related discovery work and the relay-health context behind the map.
- NIP-65: relay list metadata
- NIP-01: basic protocol flow
- NIP-11: relay information document
- NIP-50: search capability
- NIP-66: relay liveness monitoring
- Nostr Design relay guidance
- Nostr.how relay guide
- Nostr Watch relay monitoring
- nostr.co.uk relay directory
- relay.nostr.net information endpoint
- strfry relay software
- An Empirical Analysis of the Nostr Social Network
