How to Choose Relays Without Turning Nostr Into Guesswork
Relay choice becomes easier when you stop collecting endpoints and start assigning jobs: publish, read, search, archive, pay, moderate, host locally or carry sensitive traffic.
Start with the job, not the endpoint
A relay URL by itself tells you almost nothing. It is a door, not a plan. Before you paste it into a client, ask what job you expect it to do. Are you trying to publish ordinary notes? Keep long-form work reachable? Load replies from people you follow? Search the wider network? Avoid spam? Join a paid low-noise room? Run a local community? Carry Nostr Wallet Connect messages? Preserve an archive? Each job points to a different relay choice.
The most common mistake is to copy a huge relay list because it feels safer. It rarely is. More relays can mean duplicate events, slower clients, more spam, more metadata exposure, more broken endpoints, more confusing errors and a larger surface for policies you never read. A long list can hide the fact that you do not know where your own notes are going. A smaller set with clear roles is usually easier to understand, easier to repair and easier to explain to another client.
The second mistake is treating every relay as the same kind of infrastructure. A public social relay, a search relay, an inbox relay, a paid relay, a private group relay, a local venue relay, a wallet relay and an archive relay may all use WebSocket endpoints and Nostr events, but they do not carry the same trust model. If your client shows all of them as identical URL rows, your brain has to do the categorization. Do that categorization deliberately.
Start with your use case. If you are a casual social user, you need enough public reach and a relay list others can discover. If you publish serious essays, you need durability and a recovery plan. If you organize events, you need local context and moderation. If you build products, you need predictable NIP support and clear limits. If you connect wallets, you need separation and permission awareness. If you run a business or community, you need operators you can contact and policies you can read.
Relay selection is not a one-time setup chore. It is infrastructure literacy. You do not need to become a server operator to make good choices, but you do need to know why each endpoint is in your active set. If you cannot explain a relay's job in one sentence, remove it from the critical path until you can.
Build a small relay portfolio
A useful relay setup looks more like a portfolio than a pile. You usually want a few broad public relays for reach, one or two relays that feel like a durable home, maybe a paid relay if you want lower spam or service accountability, a search relay if your client uses search, and a local or private relay if your community has a physical or membership boundary. You may also need a dedicated relay for wallet traffic, archive work or application-specific messages.
The portfolio idea matters because it gives every relay a role. A broad public relay helps other people find you. A home relay gives you a more intentional place to write. A paid relay can reduce abuse and fund operations. A search relay handles discovery work. A local relay creates context for a venue, meetup, club or city. An archive relay protects retrieval. A wallet relay carries sensitive app-to-wallet messages. When a relay fails, the role tells you what is affected.
Do not make every relay read and write by default. NIP-65 lets you publish relay list metadata with read and write roles. That distinction is practical. You may want to write to a smaller set where your events should live, while reading from a broader set where your social graph publishes. You may want to read from public relays while writing to a paid or personal relay. You may want a relay in your list only for receiving inbox-style traffic. A client that respects those roles can route more intelligently.
A good starter shape is simple: two or three broad public relays, one trusted home or paid relay, one search route if your client needs it and one specialized relay only when you know why it is there. That is not a universal formula. It is a sanity check. If your active set has twenty generic relays and you cannot name the job of fifteen of them, you are not more resilient. You are harder to debug.
Portfolios also change over time. When you join a community, add its relay. When you leave, remove it. When you publish work you care about, add an archive or stronger home. When you experiment with a wallet connection, keep it separated. When a relay dies or changes policy, update your list instead of hoping the client magically routes around it forever.
Public relays are reach, not a storage guarantee
Public relays are the first place many people meet Nostr. They are easy to add, easy to recommend and good for broad reach. They also carry the hardest burden. A public relay receives spam, bots, duplicate events, experiments, heavy queries, abusive traffic and people who never think about server costs. Some public relays survive because their operators are deeply committed. Some survive because they are attached to products. Some slowly degrade. Some disappear.
You should use public relays, but do not confuse them with guaranteed personal storage. A public relay may drop old events, cap event size, rate-limit hard, block certain kinds, filter spam, require auth for writes, move software or change policy. Its NIP-11 document may explain those limits, or it may not. If your entire identity depends on one free public relay, you are not using Nostr's portability. You are quietly depending on one operator.
Public relays are best for general discovery and broad social propagation. If you publish a normal note and want many clients to see it, public relays matter. If you follow public figures or participate in open conversations, public relays matter. If you want the lowest possible friction, public relays matter. But serious publishing, communities, paid products, wallet traffic and local systems usually need more intentional infrastructure alongside them.
Judge public relays by observed behavior, not popularity alone. Can you fetch their NIP-11 information? Do they publish contact and limits? Are they alive in NIP-66-style monitoring? Do clients you use actually read from them? Do people you follow publish there? Are writes accepted without mysterious failures? Does spam drown useful content? Does the relay support the event kinds your client expects?
Public relay choice is also a privacy choice. Writing to many public relays broadcasts your activity widely. That may be exactly what you want for public speech. It may be too much for niche communities, testing, local rooms or sensitive app flows. Use public relays for public work. Use narrower relays when the context is narrower.
Paid relays buy a relationship, not perfection
Paid relays are often framed as the answer to spam. They can help, because charging even a small fee changes behavior and gives the operator money to run infrastructure. A paid relay can offer lower noise, clearer accountability, better retention, stricter abuse controls, higher limits or simply a more serious operator relationship. But payment does not magically prove quality. It only changes the terms.
When you evaluate a paid relay, inspect four layers. First, read NIP-11. Does it advertise payment_required, auth_required, restricted_writes, fee data, limits and contact information? Second, read the payment page. What exactly are you buying: admission, writes, reads, filtering, broadcasting, search, storage or premium support? Third, test NIP-42 auth if access is tied to your public key. Fourth, watch actual behavior over time. A paid relay that is slow, opaque or hard to contact is not automatically better than a free relay with a careful operator.
Paid relays are useful when the job justifies the relationship. If you publish work that should remain accessible, paying for a more accountable home can be rational. If you want lower spam and better moderation, paying can be rational. If you run a product or community, paying for predictable infrastructure may be cheaper than chaos. If you only need casual social reading, you may not need a paid relay at all.
Use payment as a signal, not a halo. A paid relay can still close, censor, underperform, misrepresent retention, mishandle support or drift from its original promise. Keep your key portable. Keep a backup write path. Keep your NIP-65 list current. If a paid relay becomes central to your workflow, periodically export or republish important events elsewhere.
Paid relays also need better client UX. A client should not show a paid relay failure as generic "publish failed." It should say whether auth is missing, payment is missing, the key is not admitted, the subscription is restricted or the relay is unreachable. Without that distinction, payment makes the network feel more confusing instead of more professional.
Private and local relays keep context close
Private relays are not a betrayal of Nostr. They are part of how open protocols become useful in real groups. A team, family, project, club, school, conference, hotel, coworking space or local city community may want a relay that admits specific keys, supports specific event kinds, rejects outside spam and carries context that should not be treated as global public infrastructure.
Local relays are similar, but the boundary is often place-based rather than purely membership-based. A venue may want local event posts, menus, room availability, member badges, staff announcements, point-of-sale context, booking updates or community notes. A conference may want a temporary relay for sessions, RSVPs and attendee coordination. A neighborhood may want local discovery without asking one giant public relay to understand local context.
The tradeoff is reach. A local relay can make a room feel alive, but the rest of the network may not see its content unless clients bridge or users also publish to broader relays. That is not a bug. It is the core decision. Some information belongs everywhere. Some belongs in a room. Some should be discoverable only to members. Some should be public but anchored locally. Your relay setup should match that shape.
Private and local relays need clear doors. NIP-42 auth can prove which key is present. NIP-11 metadata can explain the relay's purpose. NIP-43-style access metadata can make membership expectations more visible where adopted. NIP-86 management APIs can support operator tools. The important part is that the boundary is visible before people fail. A user should know whether they are joining a local room, a paid service, a team relay or a public feed.
If you run a local relay, do not copy public-relay assumptions blindly. You may want stricter event-kind rules, shorter retention, trusted moderators, venue-controlled announcements and public read with restricted write. You may want a relay that is excellent for one building and irrelevant elsewhere. That is fine. Nostr's strength is not that every relay serves everyone. It is that identity and events can move across rooms when the user chooses.
Search, inbox and outbox relays do different work
Search relays are specialized. NIP-50 gives clients a way to ask for search, but search quality is not only NIP support. It depends on indexing strategy, freshness, spam handling, language, event kinds, query parsing, storage and ranking. A relay that is great for normal read/write traffic may be mediocre for search. A search relay may be alive and useful even if you would not use it as your daily write home.
Inbox and outbox thinking is different again. NIP-65 relay lists let users publish where they write and where they prefer to read. Outbox discovery lets clients find the relays a user's own key declares instead of blasting every query to a random default set. That is one of the most important shifts in Nostr client behavior. You stop assuming that every post is everywhere, and you start asking the author's own map.
For your setup, this means your relay list is not decorative. It is part of your identity. If you publish a stale NIP-65 list, clients may search dead relays for your posts. If you never publish one, clients guess. If you add every experiment as a write relay, clients may waste time and reveal more than needed. A clean list helps other people find you and helps your future self move between clients.
Do not use a search relay as a privacy boundary. Search relays index public material. They can be useful, but they are not neutral magic. They decide what to index, how to rank, how to filter and how fresh results are. Use them for discovery. Use your core relay list for publishing and durable reach. Use private or local relays for bounded contexts.
Search, inbox and outbox roles should appear separately in client interfaces. If a client hides them behind one relay list, you may not know why a URL is there. A relay used for search should not automatically become a write target. A relay used as an inbox should not automatically become your archive. Role clarity reduces accidental dependence.
Wallet and sensitive relays need narrower habits
Nostr Wallet Connect makes relay choice feel more serious because the relay can sit between an app and a wallet service. The relay may not control your funds, but it can carry encrypted wallet requests, responses, timing and connection behavior. That is not the same category as a public social relay. Treat wallet-adjacent relays as sensitive infrastructure.
NIP-47 uses Nostr-style events to let apps request wallet actions. The wallet service decides which methods are allowed, what budget applies and how approvals work. The relay transports those messages. If the relay is unreliable, wallet UX suffers. If the relay is public and noisy, privacy may suffer. If the client does not distinguish wallet relays from social relays, users can approve flows without understanding the path.
For wallet relays, ask a tighter set of questions. Who operates it? Is it tied to a wallet product you understand? Does NIP-11 publish useful metadata? Does it support NIP-47 or is it only a generic relay carrying encrypted events? Does it require auth? Does the wallet connection string specify a relay you recognize? Can you revoke the wallet permission separately from relay access? Are budgets, methods and expiration visible?
Keep wallet traffic separate from casual public relay experimentation. You do not need to be paranoid, but you should avoid using random relay lists for money-adjacent workflows. A smooth social client habit can become a bad wallet habit if every relay is treated as interchangeable. Identity, payments and private app traffic deserve smaller, more intentional lanes.
The same logic applies to other sensitive contexts: private groups, moderation tools, venue operations, admin APIs, reputation systems and signed reports. If a relay carries operational consequences, choose it with more care than a meme relay. Read metadata. Test failure. Know the operator. Keep exit paths.
Read the door sign before trusting behavior
NIP-11 metadata is the door sign. It is not enough, but it is the first serious check. Look for the relay name, description, contact, supported NIPs, software, version, limitations, payments, fees and policy links. A relay that publishes none of this may still work, but it asks you to guess. A relay that publishes useful metadata gives your client and your brain a better starting point.
Limits matter in product terms. A low maximum event size may break long-form content, media metadata or complex application events. Tight subscription limits may make busy clients behave strangely. Short retention may be fine for live chat and bad for archives. Payment or auth requirements may be acceptable when visible and frustrating when hidden. Supported NIPs matter because clients increasingly depend on specific capabilities rather than generic note storage.
Compare the door sign with NIP-66-style monitoring. If NIP-11 says a relay supports a NIP but monitors do not observe that behavior, investigate. If NIP-11 says nothing about payment but writes are restricted, slow down. If NIP-11 says public but access behaves private, the relay may be changing policy, misconfigured or intentionally specialized. If NIP-11 provides no contact, you have fewer options when something important fails.
Software matters, but it is not destiny. strfry, nostr-rs-relay, nostream, Khatru, Grain and other stacks make different tradeoffs. A software name can tell you something about performance style, configuration options, filtering, storage and operator culture. But a careful operator on modest software can outperform a careless operator on fashionable software. Read the whole surface: metadata, behavior, monitoring, policy and use case.
Do not demand that every relay look professional. Small community relays can be valuable. Personal relays can be valuable. Temporary event relays can be valuable. But the less information a relay publishes, the less critical responsibility you should place on it until you have direct trust.
Test like a user, not like a spreadsheet
Relay choice becomes real only when you test it in the workflows you care about. Publish a normal note. Publish a reply. Publish a larger event if your client uses long-form or media metadata. Open another client and see whether the event appears. Search for it. Ask someone else whether they can see it. Wait a day and fetch it again. If you use the relay for reads, follow someone who publishes there and watch whether their updates arrive reliably.
Then test failure. Disconnect the relay. Does your client show a clear state? Try writing without auth to a relay that requires auth. Does the client explain NIP-42? Try a paid relay without payment. Does the client separate missing payment from network failure? Try a slow relay. Does the client hang, or does it degrade gracefully? These tests tell you whether the relay and client together produce a usable experience.
Test from more than one client because Nostr is not one app. A relay can appear fine in one client and invisible in another if the second client never queries it, ignores your NIP-65 list, mishandles outbox discovery or uses different defaults. That does not always mean the relay is bad. Sometimes the client path is bad. Testing from two clients separates relay reality from app assumptions.
Use monitoring tools as a shortcut, not a replacement. Nostr Watch, nostr.co.uk and other directories can show liveness, software, NIPs and public status. That saves time. But your specific use case still matters. If you need a local community relay, a global uptime score may not answer the real question. If you need wallet traffic, generic public relay metrics are only part of the story.
Keep notes about important relays. You do not need a formal audit for every endpoint, but you should remember why you trust a paid relay, where your long-form work is stored, which relay carries a community and which relay is only there for search. A small personal map prevents future confusion.
Relay choice is political because relays have rules
Relays sit where free speech, spam, legality, cost, harassment, jurisdiction, community norms and operator patience collide. A relay that accepts everything may become unusable. A relay that filters aggressively may feel safer but less neutral. A paid relay may reduce abuse but exclude people. A local relay may create stronger context but weaker global reach. A private relay may protect a group while making discovery harder.
That does not make relay choice hopeless. It makes it honest. You are choosing infrastructure with visible rules instead of joining a platform with one hidden rulebook. The same identity can move between relays. Events can be republished. Clients can choose routes. Communities can run their own endpoints. Operators can specialize. Users can leave. That is the political difference.
Moderation is not binary. Some relays filter spam only. Some filter illegal content. Some block harassment. Some accept only web-of-trust traffic. Some serve paid members. Some carry a group. Some may remove content for legal reasons. Some may never promise broad public neutrality. Before judging a relay, ask what it claims to be. A local venue relay rejecting random global writes is not broken. A public relay silently filtering without explanation is harder to trust.
You should not outsource your whole view of Nostr to one operator's policy. Use several roles. Keep your identity portable. Keep your relay list understandable. If a relay's moderation no longer fits your needs, leave or reduce its role. If you need a specific community context, use the relay that preserves that context. If you need broad visibility, publish beyond one moderated room.
This is where Nostr feels different from platforms. The answer to a bad policy is not only appeal. It can be exit, replication, another relay, a local room, a paid service, a web-of-trust relay or your own infrastructure. Relay selection is how that freedom becomes practical.
Build your own relay map
Your personal map should be short enough to remember. Label each relay by role: public reach, trusted home, paid write, search, inbox, outbox, archive, wallet, private group, local venue, testing. Then ask whether each role is still true. A relay that was a test six months ago should not remain in your main write list by accident. A local relay from an old event should not slow every client forever. A wallet relay should not be mixed with unrelated public traffic.
For each important relay, know the operator or at least the source. Is it run by a known Nostr app, a public community operator, a paid service, a friend, a venue, a company or an anonymous key? Anonymous can be acceptable for low-risk public discovery. It is less acceptable for your only archive or business workflow. Trust should scale with consequence.
Know the exit path. If a relay disappears, where do your new notes go? If a paid relay changes terms, can you publish elsewhere? If a local community relay shuts down, does the group have a replacement? If a wallet relay fails, can the wallet connection be rotated? If a search relay goes stale, does your client have alternatives? Relays are replaceable only when you actually know the replacement path.
Publish a clean NIP-65 relay list. That list should not be a museum of every endpoint you ever tried. It should tell other clients where you expect to be found. Use read and write markers thoughtfully. If you change your main relay home, update the list. If you run a private key for a project, publish a project-specific list rather than reusing your personal mess.
A good relay map also protects your privacy. If every app shares the same giant set, you broadcast more context than necessary. If you separate public speech, private rooms, wallet traffic and local communities, you reduce accidental leakage. You do not become invisible, but you become intentional.
Know when fewer relays are stronger
More relays feel protective because the list looks redundant. Sometimes that is true. If one write relay is down, another can still accept the event. If one read relay is slow, another may answer. But redundancy works only when it is designed. A random pile of endpoints can make every client slower, every query noisier and every failure harder to read.
Fewer relays can be stronger when each one has a clear job. A tight write set makes it easier for other clients to find your events. A clean read set reduces duplicate traffic. A separate search relay keeps search expectations away from normal storage. A dedicated wallet relay keeps money-adjacent messages out of casual relay experiments. A local relay that is used only for a venue can be tuned for that room instead of pretending to be global infrastructure.
Default relay lists deserve special caution. Defaults are often chosen for onboarding, not for your long-term identity. They may be maintained by an app team, inherited from old ecosystem habits or optimized for first-run visibility. A default can be useful, but it is not your strategy. When you import a key into a new client, compare the client's defaults with your own NIP-65 list before publishing important events. Otherwise each app slowly teaches your identity a different map.
Migration is the moment where relay discipline pays off. If you move from one client to another and your relay roles are clear, the move is calm. You bring your write relays, your read relays, your paid relay, your group relay, your search route and your wallet lane. If your old setup is just a long list copied from somewhere, migration becomes archaeology. You do not know which endpoints matter, which are dead, which are risky and which were only there because a client added them two years ago.
When you prune, do it gently. Remove one unknown relay, publish a test note, check discovery, then continue. Do not delete your whole setup because one directory says a relay is stale. Do not keep every endpoint forever because pruning feels technical. Relay selection is a small habit: name the job, test the job, keep the relay only while the job remains real.
Use risk tiers when the choice feels fuzzy. A relay used for casual public reading can be experimental. A relay used for your main write path should be known, monitored and listed intentionally. A relay used for long-form publishing or archives should have stronger retention evidence. A relay used for a private group should have visible membership rules. A relay used for wallet traffic should be tied to a product or operator you understand. A relay used for business, venue operations or reputation should have contact, policy, backups and a human owner. The higher the consequence, the less you should rely on anonymous defaults.
If a relay cannot explain its role, and you cannot explain why you need it, keep it out of the active set until one of those answers changes. Your future clients will thank you for the cleaner map.
Keep a selection rhythm
Relay selection is maintenance, not decoration. Once a month, glance at your active set. Remove dead relays from critical paths. Check whether your most important relays still publish NIP-11 metadata. Look at monitoring data for major changes. Make sure paid relays still justify payment. Make sure local or private relays still match your communities. Make sure your NIP-65 list says what you mean.
When you install a new client, do not blindly accept whatever relay list it gives you. Import your own map or rebuild it carefully. A client default may be good for onboarding and wrong for your identity. A client attached to one product may favor its own infrastructure. A client optimized for speed may choose relays that are poor for retention. A client optimized for privacy may choose a smaller set than you expect. Defaults are opinions. Treat them as starting points.
When you join a new community, ask which relay carries the community and why. Is it public, private, paid, local, web-of-trust or temporary? Does it require auth? Does it publish contact and limits? Do members also publish important updates to broader relays? Is there a backup? Community relay health is community health.
When you publish something important, check where it landed. Do not wait until you need an old post to discover that you published only to a short-retention relay. Serious posts deserve a durable home and at least one alternate path. If your work matters, relay selection is part of publishing, not only technical setup.
The real goal is calm control. You should be able to open relay settings and recognize the shape: these relays carry public reach, this one is my home, this one helps search, this one belongs to a group, this one carries wallet messages, this one is only for testing. Once you can see that, Nostr stops feeling like a bag of endpoints and starts feeling like a network you can steer.
Sources worth opening
Open these when you want the standards, practical guides, directories and operator evidence behind relay selection.
- Nostr.how: Relays
- Nostr Design relay guidance
- Nostr Watch
- nostr.co.uk relay list
- NIP-11: Relay information document
- NIP-65: Relay list metadata
- NIP-66: Relay liveness monitoring
- NIP-42: Authentication of clients to relays
- NIP-47: Nostr Wallet Connect
- Exploring the Nostr Ecosystem: decentralization and relay availability study
