Outbox Discovery: How Nostr Finds People Across Relays
Outbox discovery is the practical answer to a simple problem: your events are not everywhere, so clients need a way to learn where your key actually publishes and reads.
Discovery breaks when clients guess
Nostr looks simple when you first hear it: clients publish signed events to relays, other clients read those events from relays, and your identity is your key. The hard part appears immediately after that sentence. Which relays? If Alice publishes on one set of relays and Bob reads from another set, Bob may never see Alice's event even though the protocol worked perfectly. The missing piece is not identity. It is routing.
Early Nostr clients often solved this by using big default relay lists or by blasting requests across many public relays. That can work for a small network, but it does not scale gracefully. It wastes bandwidth, duplicates events, reveals more behavior, stresses public relays and still misses people who publish somewhere else. A bigger list is not a map. It is a louder guess.
Discovery is where relay choice becomes a social problem. If your followers cannot find your events, portability feels fake. If your replies land on relays the original author never reads, conversation fragments. If your long-form work sits on a relay nobody queries, it may as well be hidden. If your client relies on stale defaults, your social graph becomes hostage to app assumptions.
Outbox discovery fixes the question order. Instead of asking every relay whether it has Alice's notes, the client first asks where Alice says she writes. Instead of treating the network as one giant undifferentiated store, the client follows relay hints attached to public keys. That turns identity into a routing clue.
The idea is not that every event is perfectly findable forever. Nostr is still a relay network with failures, policies and operators. The idea is that clients should stop guessing blindly when the user can publish a signed map.
The outbox idea is author-centered routing
In an outbox model, each author has a set of relays where they usually publish. If you want Alice's events, you look at Alice's relay list and query those relays. If you want Bob's events, you query Bob's relays. Your client can still use public defaults, search relays or cached data, but the author's own map becomes the first serious clue.
This is different from a platform timeline. A platform owns the database and decides what everyone sees. Nostr has many relays, so clients need discovery strategies. Outbox discovery is one of the strategies that keeps the network user-directed. The author declares where their events should be found. Other clients can respect that declaration, combine it with liveness data and fetch more intelligently.
The word outbox is useful because it describes the direction. Your outbox relays are where you send your events out to the network. They are not necessarily the same relays you read from. You may write to a trusted home relay and a few broad public relays, while reading from the relays used by people you follow. You may use a paid write relay, a local community relay and public read relays. Outbox discovery makes those roles visible.
Outbox discovery also helps with replies. If you reply to someone, your client should consider the author's relay list, the event's seen-on relays and your own write relays. Otherwise your reply may land only where you publish, while the original author never sees it. Good routing feels social because it asks where the conversation actually lives.
The practical shift is subtle but huge: relay selection stops being only a client setting and becomes part of identity. Your key can publish a map of where you live in the relay network.
NIP-65 gives the map a standard shape
NIP-65 defines relay list metadata using replaceable event kind 10002. The event contains r tags with relay URLs. Each relay can be marked for read, write or both. Because the event is signed by your key and replaceable, you can update it when your relay setup changes. Other clients can fetch the latest version and learn where to find you.
This is the key difference from random relay settings. A local client preference tells one app what to do. A NIP-65 event tells the network where your key expects to read and write. That does not force every client to obey. It gives clients a better clue than defaults. It also gives you a responsibility: publish a clean list, not a museum of every relay you ever tried.
The replaceable nature matters. If you move from one relay home to another, you publish a new kind 10002 event. Clients that fetch your latest relay list can adjust. If you add a paid write relay, remove a dead public relay or create a project-specific identity, the map can change with you. The protocol does not trap your key in one relay set.
NIP-65 is not a magic guarantee. A relay in your list may be dead. A client may not fetch the list. A follower may use an old cache. A relay may reject writes. A private relay may be unreadable to others. The event is a map, not terrain. You still need liveness, metadata and client judgment.
Still, signed relay-list metadata is one of the most important practical pieces in Nostr. It turns the network from "try all the relays" into "ask the person where they are."
Read and write roles stop one list from doing every job
NIP-65 lets relay tags carry read and write markers because those roles are not the same. Write relays are where your events should be published. Read relays are where you prefer to receive events or where others may find things addressed to you. Some relays can do both. Some should not.
This distinction becomes practical quickly. You may write to a personal relay, a paid relay and a few public relays, while reading from a broader set. You may use a private group relay for local coordination but not want it as a public write destination. You may use a wallet relay for NWC traffic but not for public notes. You may use a search relay for queries but not as a write home. Without roles, clients are tempted to treat every URL as interchangeable.
Write roles also affect discovery. If someone wants your notes, your write relays are the first place to look. If your write list includes dead experiments, clients waste time. If your write list omits the relay where you actually publish, clients miss you. If your write list points only to a private relay, public followers may fail. The list should reflect reality.
Read roles affect interaction. If someone wants to send you a reply, mention, private group message or app event, they may care where you read. If your read list is stale, messages can land in the wrong place. If your read list includes too many public relays, your attention surface gets noisy. If it includes private relays without context, other clients may fail without explanation.
Good clients should show roles. "Write relay" and "read relay" should not be hidden inside raw tags. You should know which relays carry your public posts, which relays you read, which relays are local, which are paid, which are private and which are specialized. Outbox discovery works best when people can understand their own map.
Your social graph becomes infrastructure input
Outbox discovery does not happen one person at a time forever. A client can build a routing picture from your social graph. If you follow a hundred people, the client can fetch their relay lists, group relays by overlap, prefer live relays, cache recent results and query the most relevant relays first. That is how Nostr can feel fast without pretending every event lives everywhere.
This also means relay diversity becomes visible. If most of your follows publish to the same few relays, those relays become important to your experience. If a community runs a local relay and its members publish NIP-65 lists pointing there, clients can discover that room more naturally. If many people use paid or private relays, clients need to handle auth and payment states without turning the feed into errors.
Social graph routing is not centralization by itself. It is a client strategy. The client uses public signed data to decide where to look. You can use another client, another strategy, another monitor or another relay set. The risk appears when clients hide their choices. If a client silently routes through its own preferred infrastructure while ignoring user relay lists, the network starts to feel platform-like again.
Outbox-aware clients should therefore be transparent. They should explain when they use a person's relay list, when they fall back to search, when a relay is dead, when a private relay blocks access and when a local cache is stale. The user does not need every packet detail, but the route should not be mystical.
For communities, this is powerful. A group can publish from a local relay. Members can list that relay. Clients can learn the room from the social graph. The result feels more organic than manually configuring every endpoint.
Freshness and liveness keep the map honest
A relay list can age. People change clients, add paid relays, leave communities, shut down personal nodes, rotate keys, abandon old endpoints and forget to update metadata. A NIP-65 event from last year may still be signed and still be wrong. Clients need freshness logic.
Freshness starts with replaceable events. Fetch the latest kind 10002 event for a key. Check when it was created. Prefer recent relay lists when available. If no relay list exists, fall back carefully to seen-on relays, global defaults, search relays or contact lists. Do not treat missing metadata as a fatal error. Plenty of valid users have incomplete relay maps.
Liveness adds reality. NIP-66-style monitoring can help clients avoid repeatedly querying dead relays. If Alice's relay list points to three relays and two have been down for weeks, the client should still respect the list but adjust expectations. It can try live relays first, show degraded state and prompt the user to update their own list when their write relays look broken.
Seen-on data is another clue. If your client receives an event from a relay, it can remember that this author was seen there. That does not replace NIP-65 because events can be mirrored or copied. But it helps bridge reality when relay lists are missing or stale. Good routing uses several clues: author relay lists, event provenance, social graph overlap, liveness, metadata and local cache.
Freshness should be visible. If a client's route is based on a relay list from months ago, that matters. If a user publishes to a relay not listed in their NIP-65 event, that matters. If a relay has been dead for days, that matters. The best clients make those clues available without burying normal users in protocol jargon.
Outbox discovery has privacy tradeoffs
A relay list reveals habits. It can show which relays you use, whether you pay for a relay, whether you belong to a local room, whether you run a home relay, whether you use a private community relay and how your identity is routed. For a public social key, that may be fine. For sensitive work, it deserves thought.
NIP-65 is public metadata. If you publish a private relay URL in a public relay list, you may reveal a relationship even if outsiders cannot read the relay. If you use the same key for personal posting, local venue operations and private group work, your relay list may tie those contexts together. Outbox discovery improves findability by publishing routes. Findability and privacy are always in tension.
One answer is key separation. Use one key for public identity, another for staff operations, another for testing, another for private groups when needed. That adds complexity, but it can keep relay maps cleaner. Another answer is role discipline: do not put every local or sensitive endpoint into your public write list unless you actually want others to use it.
Clients can help by warning when a relay looks private, local or wallet-related. They can show whether a relay list will be public. They can distinguish public write relays from private read relays. They can avoid auto-publishing local experiments into a global identity map. They can make it easy to maintain separate relay lists for separate keys.
The privacy rule is simple: publish enough routing information for the identity you want to be reachable, but do not turn every context into public infrastructure metadata by accident.
Clients should make routing understandable
Outbox discovery is mostly invisible when it works. You follow someone, their notes appear, replies find the right places and your client does not spam the whole network. But invisible infrastructure still needs visible explanations when something fails.
A good client can say: "This author publishes to these relays." "Two of those relays are unreachable." "This relay requires auth." "This relay is paid." "Your reply will also be sent to the author's write relays." "Your own relay list has not been updated since this date." Those sentences turn protocol routing into human understanding.
Relay settings should not be raw URL soup. Show roles, source and freshness. Did this relay come from your own NIP-65 list, a client default, a followed author's outbox, an event provenance record, a search result, a manual setting or a wallet connection? The source tells you whether it belongs in your active map.
Clients should also prevent accidental relay bloat. If every followed user's relays are added to your own relay settings, your setup becomes chaos. Outbox discovery should query other people's relays as needed, not permanently pollute your personal write list. Your relay list should describe where you are, not every place your social graph has ever appeared.
Finally, clients should treat updates carefully. When you change your main write relays, the client should offer to publish a new NIP-65 event. When a relay dies, the client should suggest cleaning the list. When you add a private relay, the client should ask whether it belongs in public metadata. That is how protocol power becomes a usable product.
Your publisher routine keeps you findable
If you publish on Nostr, your relay list is part of your public presence. Keep it small, accurate and intentional. Choose write relays where you actually publish. Choose read relays where you actually listen. Remove old experiments. Do not rely only on a client default you never reviewed. Do not put private or local relays into a public map unless you mean it.
After changing clients, check your NIP-65 event. Some clients may import old settings. Some may add defaults. Some may not publish relay-list metadata at all. If you move your identity to a new relay home and never update the signed list, followers may keep looking in the wrong places.
Test findability from another client. Publish a note. Open a different client. Search or fetch from your listed relays. Ask whether replies show up. If people cannot see you, inspect the map before blaming the protocol. Your key may be fine and your relay list may be stale.
For long-form work, zaps, media, communities and business profiles, be even more careful. Important publishing deserves durable write relays and a clear map. If you publish only to a short-lived relay, no routing strategy can make the event durable. Outbox discovery helps people find your events. It does not guarantee the events will remain stored.
Think of the relay list as a forwarding address for your public key. Keep it current, and the network has a chance to find you.
Operators and app builders shape discovery too
Relay operators can support outbox discovery by publishing clear NIP-11 metadata, staying reachable, returning useful errors and avoiding policy surprises. If a relay is meant to be a public write relay, say so. If it is paid, private, local, search-only or read-only, say so. Clients can route better when relays describe themselves honestly.
App builders need to resist the temptation to own the map. A client may have good defaults, but user relay lists should matter. If the app writes only to its own relay and hides that choice, portability weakens. If the app respects NIP-65, shows relay roles and helps publish clean lists, portability becomes visible.
Products with their own relays should be especially careful. A social client, wallet, media app or community tool may need a relay for performance, storage or specialized events. That is fine. It becomes a problem when the product silently replaces the user's map with product infrastructure. The better pattern is to explain: this relay is used for this product feature, and your public write relays remain these.
Search services also interact with outbox discovery. Search can help find users and events when relay lists are missing, but it should not replace the author's own map. A search relay may have stale indexes, filtering choices and ranking bias. Use search as a supplement, not as the identity routing layer.
For communities and venues, app builders can make local rooms discoverable through venue keys, QR codes, signed relay lists and group metadata. That is outbox thinking applied to real places.
Common failure patterns
The first failure is a stale list. You publish somewhere new, but your NIP-65 event still points to old relays. People miss your events because they follow your signed map and the map lies. Fix it by publishing a fresh relay list.
The second failure is overbroad lists. You add every relay you ever tried. Clients waste time, expose more traffic and hit dead endpoints. Fix it by separating active write relays from experiments.
The third failure is private leakage. You list a private or local relay publicly and reveal a relationship you did not intend to reveal. Fix it by using separate keys or keeping sensitive endpoints out of public metadata unless needed.
The fourth failure is client ignorance. A client ignores NIP-65 and uses only its own defaults. Fix it by choosing better clients, or at least testing how your current client handles relay-list metadata.
The fifth failure is stale cache. A client fetched an old relay list and never refreshed it. Fix it with clearer freshness rules, manual refresh and UI that shows relay-list dates.
The sixth failure is wrong reply routing. You reply to someone, but your client does not send the reply to relays the original author reads. Fix it with outbox-aware reply publishing that considers the author's list and event provenance.
The seventh failure is treating discovery as storage. A good relay list helps clients find where to ask. It does not make those relays keep your events forever. If durability matters, choose durable relays too.
Reply routing is where outbox discovery becomes social
Reply routing is the everyday test. When you reply to someone's event, your client has to decide where the reply should go. If it sends the reply only to your own write relays, the original author may never read it. If it sends the reply to every relay in sight, it wastes resources and leaks more activity. If it sends the reply to the relays where the original event was seen and the author's declared write relays, the conversation has a better chance of staying connected.
This is why event provenance matters. A client that remembers where it found an event has a useful clue. If Alice's note came from relay A and Alice's NIP-65 write list includes relays A and B, your reply should probably go to your write relays plus a sensible subset of Alice's relays. If Alice's list is stale but the event was seen on relay C, relay C is evidence too. The client should combine clues instead of choosing one blindly.
Mentions follow the same pattern. If you mention someone who reads from specific relays, your client can improve delivery by considering that person's read list. That does not mean every mention must be sent everywhere. It means the target's own relay map should influence the route. A social graph is not only who follows whom. It is also where those people can actually be reached.
Bad reply routing creates the illusion of silence. You reply, but the person never sees it. They reply, but you never see it. Threads look broken. People blame clients, relays, censorship or Nostr itself. Often the real problem is that the conversation crossed relay sets without a routing strategy. Outbox discovery does not solve every thread issue, but it gives clients a coherent place to start.
A good client should let advanced users inspect this. Which relays received the reply? Which relays came from your write list? Which came from the author's outbox? Which came from event provenance? Which failed? Normal users do not need this every day, but when conversations disappear, the route should be auditable.
Caching relay lists is useful until it becomes stale truth
Clients need caches. Fetching every followed user's relay list on every load would be slow and rude to relays. A client should cache kind 10002 events, cache seen-on relays, remember liveness hints and reuse recent routing decisions. Without caches, outbox discovery can make startup heavy and feeds slow.
The danger is stale truth. A cached relay list from six months ago can keep sending queries to dead endpoints. A cached seen-on relay can outlive the author's move. A cached liveness result can hide a recovered relay. Caches need timestamps, refresh rules and visible invalidation. The client should know when it is acting on fresh signed metadata and when it is acting on old memory.
Good caching has layers. A fresh NIP-65 event should beat an old one. A recent seen-on relay should inform routing but not override the author's declared map forever. NIP-66 liveness should help order attempts but should not permanently delete a relay from consideration because one monitor failed. Manual user settings should be respected, but the user should know when those settings conflict with signed relay-list metadata.
Clients can also refresh opportunistically. When you follow someone new, fetch their relay list. When a reply fails, refresh the author's list. When a relay is repeatedly unreachable, check liveness. When your own write relays change, offer to publish an updated NIP-65 event. When a cache is old, show a subtle stale state instead of pretending everything is current.
Caching is where outbox discovery becomes product craft. The protocol gives events. The client decides whether the network feels fast, respectful and truthful.
App defaults can become soft centralization
Every client needs defaults. A new user cannot begin with an empty relay map and a lecture. Defaults make onboarding possible. The problem begins when app defaults silently become the main infrastructure, even after the user's own relay list exists. If a client prefers its own relays, ignores NIP-65, hides routing and treats user relay maps as decoration, it recreates platform gravity inside an open protocol.
There are legitimate reasons for app relays. An app may use a relay for performance, spam control, media metadata, wallet messages, app-specific events, search or onboarding. That is fine when it is explained. It is unhealthy when the app makes its own relay the invisible center of your identity. You should know whether your note is published to your chosen write relays, the app's relay, the author's relay, a local room or all of those.
Outbox discovery is an antidote because it gives the client a user-centered map. The app can still provide fallbacks, but the signed map should matter. If a user declares write relays, the client should respect them. If an author declares where they publish, the client should query there. If a community declares a local relay, the client should not flatten it into a generic global default.
This is also a design challenge for power users. Do not reject all defaults as evil. Good defaults help new people. But once you understand your relay map, review defaults. Remove what no longer serves you. Keep what does. Ask whether the client publishes your NIP-65 list or only keeps local settings. Portability depends on signed public metadata, not only a hidden preference file.
The best clients make defaults feel like training wheels. Helpful at first, removable later, never welded to the bike.
Project keys need their own relay maps
Many people use more than one Nostr key. A personal key may publish public notes. A project key may publish product updates. A venue key may publish local announcements. A staff key may write to a private relay. A wallet connection key may carry NWC traffic. These identities should not all share one relay list by accident.
A project key should publish a relay list that matches the project. If the project publishes official updates, choose durable public write relays and maybe a paid or operated home. If the project belongs to a local community, include the local relay intentionally. If the key is used only for staff operations, do not publish a public relay list that exposes private infrastructure. If the key is temporary, do not leave stale relays around forever.
Venue and community keys are especially important. A venue key can act as the public doorway for a local relay. It can publish NIP-65 metadata, NIP-11 links, event announcements and group context. Attendees can discover the room through the venue key rather than copying a relay URL from a chat. That makes local infrastructure feel like part of the open graph.
Multiple identities also protect privacy. If your public personal key lists the same relays as your private operations key, people may infer relationships. Sometimes that is fine. Sometimes it is not. The cleaner pattern is to let each key publish the relay map that belongs to its role. Outbox discovery rewards that discipline because clients can follow the right map for the right identity.
When you rotate or retire a project key, update the relay map. A stale project outbox can misdirect followers long after the project moved. A clean relay list is part of responsible publishing, just like a current website link or contact address.
Search is not a substitute for outbox discovery
Search relays help when you do not know where something is, but they should not become the main routing model. A search relay has its own index, freshness, spam rules, ranking choices and gaps. It can find public material, but it does not know your intent the way a signed relay list does. Use search as a rescue path, a discovery layer and a broad query tool. Use outbox discovery when you want to follow a person, reply to them or fetch their current publishing home.
If a client treats search as the only answer, the network starts to depend on large indexes. If it treats NIP-65 as the only answer, it misses stale, missing or mirrored data. The better client uses both: signed maps first, search when the map is incomplete, and liveness to decide which doors to try.
The practical verdict
Outbox discovery is one of the quiet pieces that makes Nostr feel real. Without it, clients guess. With it, the network can ask each key where to look. That is a small change in protocol shape and a huge change in user experience.
NIP-65 gives the map. NIP-66 helps judge whether the map is still alive. NIP-11 helps understand the relays on the map. Clients turn those signals into routes. Users keep the map accurate. Operators make the endpoints honest. None of those pieces can do the whole job alone.
The best outbox setup is not complicated. Publish a clean relay list. Use read and write roles. Keep the list current. Respect other people's lists. Use liveness and metadata as reality checks. Avoid turning every experiment into public identity metadata. Treat search as a supplement. Keep important events on relays that actually keep them.
When that routine works, Nostr stops feeling like a cloud of random endpoints. It starts feeling like a network of people with signed identities and inspectable routes.
Sources worth opening
Use these when you want to check the standard, adjacent relay metadata and practical routing guidance.
- NIP-65: Relay List Metadata
- NIP-65 source on GitHub
- NIP-11: Relay information document
- NIP-66: Relay liveness monitoring
- Nostr Design relay guidance
- Nostr.how relay guide
- Nostr Watch relay monitoring
- nostr.co.uk relay directory