Relays / Relay market

The Relay Market: Public Defaults, Paid Doors and Operator Trust

The relay market is where public generosity, paid reliability, specialized tools and operator reputation become visible.

Relays Relay market Endpoints, policy, metadata and reliability before the next dependency.

Relays NIP-11 Sources

Relays30 min readRelay market

The Relay Market: Public Defaults, Paid Doors and Operator Trust

The relay market is where public generosity, paid reliability, specialized tools and operator reputation become visible.

The relay market starts when you stop treating every endpoint like the same product

If you only remember one thing, make it this: a Nostr relay is not an account, not a company profile and not a neutral pipe with no choices inside it. It is an operated place where signed events may be accepted, indexed, served, refused, deleted, throttled, filtered, searched, paid for, backed up, grouped, monitored or ignored. Your key travels across the network, but the places you choose around that key shape what you can actually see and what other people can find from you.

That is why a relay market exists at all. If relays were interchangeable sockets, a directory would be enough. You would paste ten URLs, walk away and never think about them again. Real use is messier. A public client relay carries onboarding and social reach. A paid relay sells lower spam or stronger operator attention. A filter relay can act like a gatekeeper for what gets forwarded. A search relay may answer queries that normal relays do not optimize for. A wallet relay may carry Nostr Wallet Connect traffic and should not be treated like your social archive. A local relay can make a club, event, conference, hotel, school or office feel immediate without trapping identity inside one private app.

Once you see the roles, the market becomes less confusing. You are not asking which relay is the best. You are asking which promise you need for which job. You may want one or two broad public relays for reach, a personal or paid relay for dependable writes, a relay list that tells other clients where to find you, a search or directory surface when discovery matters, a wallet relay for app-to-wallet messages, and a local relay when a real group needs fast shared context. Those are different jobs. Mixing them blindly gives you a relay list that looks powerful and behaves like a junk drawer.

The deeper Nostr promise is portability, not magic. You should be able to move without losing your identity, but the move still has operational consequences. If you stop writing to an old relay, people who only query that relay may miss you. If you rely on a relay that silently drops events, your client may show success while the network barely sees you. If a relay demands authentication, payment or proof of membership, the client has to show that moment clearly enough for you to make a sane decision. If a relay keeps no archive, you need another plan for memory. Nostr gives you exits; it does not remove the need to inspect rooms.

The market also has a cultural side. Public relays are acts of generosity until abuse makes them expensive. Paid relays are healthy when the price buys a clear service, not when payment becomes a vague badge of seriousness. Community relays are useful when they serve a defined group and still respect portability. Corporate or client-adjacent relays can be convenient, but they deserve the same questions as every other operator. Who pays the server bill? Who responds when something breaks? Which software is visible? Which NIPs are advertised? Which policies are stated and which are only discovered after your event is rejected?

You do not need to become a relay operator to make better choices. You need a few habits. Open the NIP-11 document before trusting a relay. Read the supported NIPs as a claim, not a certificate. Look at the software when it is advertised. Notice whether contact, payment and limitation fields are present. Compare live metadata with what a marketing page says. Keep your NIP-65 relay list intentional. Test whether your event can be read from another client. Watch out for relays that are useful for one job but dangerous as a default archive. When you do that, the relay market stops looking like a random list and starts looking like infrastructure you can reason about.

Public relays carry the commons, but they are not your backup plan

Public relays make Nostr usable on day one. They let a new client show a feed quickly, give new keys somewhere to publish, and create shared surfaces where replies, reactions, reposts and profile updates can be found without a private onboarding ceremony. Without public relays, every new user would begin with server administration or invitation friction. That would make Nostr feel elegant to protocol people and cold to almost everyone else.

The cost of that generosity is pressure. Open write access attracts spam, scraping, abusive media, repetitive bot traffic, storage growth and boring operational work. Public relays have to choose limits. Some keep short retention windows. Some block certain event kinds or apply heuristics. Some accept many NIPs but still make quiet policy choices. Some run on visible open-source software; many of the public endpoints checked on June 22, 2026 advertise strfry in their NIP-11 metadata, including relay.damus.io, nos.lol, relay.primal.net, relay.snort.social, nostr.mom, nostr.bitcoiner.social, offchain.pub and relay.nostr.net. That common software trail is useful, but it does not make the operators identical.

Look at the limits before you depend on the commons. relay.damus.io advertised a max limit of 500 and a max message length of 1,000,000 bytes in the June 22, 2026 check. nos.lol advertised a max limit of 500 and a max message length of 131,072 bytes. relay.primal.net also advertised a 500 max limit and a larger message allowance. relay.nostr.net advertised a smaller max limit of 100 and a max message length of 262,144 bytes. Those are not moral rankings. They are clues about how much data you should ask for in one query, how a client may need to paginate, and whether an endpoint is meant for broad social reach or a narrower operating posture.

A good public relay should be appreciated, but gratitude is not a backup strategy. If you want durable memory, you need a relay that makes an archive promise or a separate storage plan. If you want strong availability, you need monitoring and redundancy. If you want low spam, you may need paid or curated access. If you want local context, a general public relay may be the wrong room. The commons is where you start, not the only place you live.

The practical rule is simple. Use public relays for reach and discovery, but do not let them become invisible infrastructure in your head. Keep a small set of known public endpoints, understand what each one seems to be good at, and remove stale defaults. A huge public relay list makes clients slower, increases duplicate traffic and gives you a false feeling of resilience. Resilience comes from role clarity: a few broad relays for reach, a dependable write path, visible relay list metadata, and a plan for search, local rooms, wallets or archives when you need them.

Paid, filter and wallet relays sell narrower promises

Paid relays make the server bill visible. That can be healthy. A relay that asks for payment can reduce spam, fund maintenance, give the operator a reason to care, and set expectations about service quality. The useful question is not whether paid is purer than free. The useful question is what the payment buys and how clearly the operator says it.

nostr.wine is the obvious example because it has become a recognizable paid relay surface in the ecosystem. In the June 22, 2026 NIP-11 check, nostr.wine advertised support for NIP-42 authentication and NIP-50 search alongside basic relay behavior, with a max limit of 1000 and a max message length of 524,288 bytes. That combination matters. It suggests a relay that cares about access control and query behavior, not only raw posting. You still need to inspect the service terms and current operator page, but the metadata already tells you that payment, search and authentication belong in the same mental folder.

filter.nostr.wine is a different kind of object. It is not just another relay in a normal posting list. It is a filter and broadcast surface. In the June 22, 2026 check it advertised NIP-42, NIP-50, NIP-65 and NIP-94, with a higher max limit of 2000 and the same 524,288-byte message length. That does not make it automatically better than a plain relay. It means the job is more specialized. If you use a filter relay, you should know what it filters, how it decides, how it interacts with your relay list, and whether the client makes the behavior clear enough that you can reverse it.

Wallet relays are even more specialized. With Nostr Wallet Connect, the relay is not primarily a public social room; it is a message route between an app and a wallet. That changes the trust shape. You care about availability, privacy leakage, event kinds, authentication, wallet permissions and whether the relay only accepts the traffic it was built to carry. relay.getalby.com and NWClay-style relays belong in that family. They are useful when a wallet and an app need a shared mailbox, but they should not be thrown into a general feed setup just because they speak Nostr.

Profile directories and discovery relays have another role again. purplepag.es, for example, is commonly understood as a profile and NIP-05-oriented discovery surface rather than a normal social timeline relay. That kind of service helps clients resolve identity context, find profile data and connect a public key to human-readable hints. It can be deeply useful while still not being your personal archive. A directory relay should be judged by freshness, data quality, supported behaviors and whether clients understand its narrow purpose.

The danger across all specialized relays is category collapse. A client asks for a relay URL, you paste one, and suddenly a wallet route, directory surface, paid write path and public feed endpoint are treated as the same thing. That is how relay setups become fragile. Specialized relays should sit in named compartments. If a relay exists for wallet messages, call it a wallet relay. If it exists for profile discovery, call it a directory. If it exists for filtering, call it a filter path. If it exists for paid writes, call it a paid write path. Naming the job is not pedantry; it protects you from building a foggy infrastructure map.

NIP-11 metadata is the first inspection, not the final verdict

NIP-11 gives a relay a public information document. The document can tell you the relay name, description, pubkey, contact, supported NIPs, software, version, limitation fields, payment URL and access hints. That is a small thing with huge consequences. Before NIP-11 literacy, a relay URL could feel like a black box. With NIP-11, a client or human can at least ask the operator to declare the basics.

You should read NIP-11 the way you read a sign on a door. It tells you what room you are entering. It does not prove the room is well run. A relay can advertise a NIP and still implement it poorly. A relay can omit contact information and still be maintained by a careful person. A relay can run visible software and still make private moderation decisions. Metadata is not trust, but lack of metadata is a signal too. If a relay wants to become part of your long-term setup and it cannot explain itself, make that count against it.

Supported NIPs deserve close reading. NIP-42 means client authentication can appear. You should expect a challenge and response flow, and your client should show you why you are signing. NIP-50 means search capability may be available, but search quality still depends on indexing and operator choices. NIP-65 matters because relay lists help other clients find where you publish and read. NIP-66 matters because liveness monitoring can describe relay health in a machine-readable way. NIP-86 matters for management APIs and is mostly relevant to operators and admin tooling. Seeing a NIP number is not the end of the conversation; it tells you which conversation to open next.

Limit fields matter more than most people think. A max limit of 500 or 1000 changes how a client should query. A max message length changes whether larger events, media metadata or unusually long content will fit. Retention fields, if present, tell you whether the relay is making an archive promise or only carrying recent traffic. Payment fields tell you whether access has a price. Restricted write or auth hints tell you when a user may face a wall. A clean client should translate these details into human language before it asks you to make decisions.

Operator trust is built in layers. First, can you identify who runs the relay or where to contact them? Second, does the relay publish metadata that matches observed behavior? Third, is the software visible or at least named? Fourth, are limits and payment terms stated before you depend on the service? Fifth, does the relay behave consistently over time? Sixth, can you leave without losing identity and without making your followers guess where you went? Nostr does not eliminate trust. It makes trust more movable and more inspectable when the tools do their job.

That is also why relay monitoring should be read carefully. A monitor can tell you whether an endpoint responds, which NIPs are advertised, maybe how fast it answers, and whether it has been reachable over time. It cannot tell you whether the operator's moderation policy matches your needs, whether the business model is sustainable, whether a local community trusts the operator, or whether the relay is right for wallet messages. Monitoring is one instrument on the dashboard, not the whole cockpit.

Operator field notes from the hub

The following notes keep the hub icons honest. They are not awards and not permanent rankings. They are a practical map of roles, based on public relay behavior, NIP-11 metadata checked on June 22, 2026 where available, and the visible source trail around each service. Use them as a starting point, then inspect the current endpoint before adding anything important to your setup.

Damus relay

relay.damus.io is a recognizable client-adjacent public relay. Its June 22, 2026 metadata advertised strfry software, support for common social relay NIPs such as 1, 2, 4, 9, 11, 28, 40, 45, 70 and 77, a max query limit of 500 and a large max message length. That shape fits a broad public social relay: useful for reach, useful for client defaults, but not something you should blindly treat as your only archive. If you use Damus or client-adjacent relays, ask whether they are part of your write path, read path or only a default that happened to be there.

nos.lol

nos.lol also advertises strfry and a familiar public-relay NIP set. The lower message length reported in the June 22, 2026 check compared with some larger public relays is a reminder that even similar-looking endpoints have different operating limits. nos.lol is useful to consider as a public social relay with visible metadata, but you still need to test whether your client can read, write and recover the context you expect. Do not use brand familiarity as a replacement for current behavior.

Primal public relay

relay.primal.net sits near a major Nostr client and media surface, so it can feel like infrastructure before you have inspected it. Its June 22, 2026 metadata advertised the name Primal Public Relay, strfry software, support for NIP-22 in addition to several common relay NIPs, a max limit of 500 and a large message allowance. Treat it as a public relay with product adjacency. That can be useful for reach and compatibility around Primal, but it should still be one part of a setup, not the whole mental model.

Snort relay

relay.snort.social is another client-adjacent public relay, and the June 22, 2026 metadata advertised strfry with common NIPs and a max limit of 500. The practical question is the same as with every client-related endpoint: are you using it because the client configured it, because your community is reachable there, or because you deliberately chose it after comparing behavior? Client defaults are convenient, but you should notice when convenience quietly becomes dependency.

nostr.mom

nostr.mom advertises itself as a public relay with moderation and filtering context. The June 22, 2026 metadata showed strfry, common relay NIPs, a max limit of 500 and a 131,072-byte message length. The interesting part is not only the numbers; it is the policy posture. A public relay that filters spam or nudity is making a room-level decision. That may be exactly what you want for a cleaner feed, but you should name it as moderation, not pretend it is a neutral mirror of all Nostr.

nostr.bitcoiner.social advertised strfry and common relay NIPs in the June 22, 2026 check, with a max limit of 500 and a 131,072-byte message length. Public material around the relay has emphasized reliability, monitoring and backups. Those are the right kinds of claims to inspect because they speak to operation rather than hype. If a relay says it is reliable, ask where liveness, backups and operator contact are visible. Reliability is not a vibe; it is a promise with evidence.

offchain.pub

offchain.pub is a public strfry relay in the checked metadata. Its profile is useful as a reminder that a relay does not need a famous client brand to be part of the commons. Smaller public relays can add diversity and reduce pressure on a few defaults, but only if users and clients understand their role. Add a public relay because it improves your reach or community context, not because every extra URL feels like free insurance.

relay.nostr.net

relay.nostr.net has a more explicitly informational posture, including public relay identity and operator context on its site. The June 22, 2026 NIP-11 check showed strfry, common relay NIPs, a max limit of 100 and a 262,144-byte message length. The lower max limit is not a flaw by itself; it tells clients to be gentle and deliberate. relay.nostr.net is useful to inspect because it connects the endpoint with a public explanation, which is exactly the kind of transparency a relay market needs more often.

nostr.wine

nostr.wine belongs in the paid relay conversation. Its June 22, 2026 metadata advertised NIP-42 and NIP-50 alongside core relay behavior, with a max limit of 1000. That makes it more than a generic public endpoint. You should evaluate it as a paid access and search-capable service: what does payment unlock, how does authentication appear, what does the relay reject, and what happens if you stop paying? Paid infrastructure can be excellent when the promise is plain. It becomes messy when people treat payment as a substitute for reading the terms.

filter.nostr.wine

filter.nostr.wine is best read as a specialized filter and broadcast layer. In the June 22, 2026 check it advertised NIP-42, NIP-50, NIP-65 and NIP-94, with a max limit of 2000. That tells you it is not merely a place to dump events. It participates in routing, filtering and discovery behavior. Use it only when you understand the job, and expect your client to show the consequences. A filter relay can make life better by reducing noise, but it can also hide why something moved or did not move.

purplepag.es

purplepag.es is a discovery and profile directory surface in the Nostr ecosystem. The key question is not whether you should post everything there. The key question is how profile, NIP-05 and directory context help other software find who you are. Discovery infrastructure is easy to undervalue until it breaks. When profile data is stale, clients feel haunted. When directory context works, Nostr feels more human because keys connect to names, relays and social context without becoming a closed platform account.

Alby NWC relay

Alby NWC relay infrastructure belongs with wallet communication, not ordinary social posting. Nostr Wallet Connect uses Nostr-style encrypted events so an app can request wallet actions without holding your spending keys. That makes the relay a mailbox between app and wallet. You should care about permissions, session scope, event handling and availability. Do not mix wallet relays into your social relay list unless you know why. The job is specific, and the risk shape is specific too.

wallet relay

A generic wallet relay should be evaluated by the NWC workflow it supports. Does it carry only wallet-related event kinds? Does it require authentication? Does the wallet let you revoke the connection? Does the app explain the permissions before you approve them? Wallet relays can make Lightning and Nostr feel smooth, but smoothness is not the same as safety. The best wallet routes make the invisible message path visible enough that you can trust it without becoming a protocol engineer.

nwclay

NWClay-style infrastructure is interesting because it narrows the relay idea down to NWC traffic. That is a good thing when the boundary is clear. A relay that only wants wallet events can reject the rest of the social universe and keep its operational burden focused. For you, the question is whether the wallet and app explain the relay as a payment control path. If they only show a generic URL, the user experience is underexplained. If they show permissions, expiration and revocation, the protocol starts to feel like a product.

Build a relay setup you can explain tomorrow

A serious relay setup should be small enough that you can explain it. You might keep a few public relays for broad reach, one dependable write relay, a paid relay if you value cleaner admission or support, a search surface for discovery, a wallet relay for NWC sessions, and a local relay when a group needs room-level memory. You do not need every category every day. You need enough clarity that removing one relay does not feel like pulling a random wire from a wall.

Start with the social path. Where does your client publish your notes, profile updates, replies and reactions? Then look at read behavior. Where does it search for other people? Does it use your contacts' relay lists, or does it hammer defaults? Then check specialty routes. Does it use a wallet relay, group relay, media relay or search relay without naming it? Then inspect NIP-65. Are your advertised write and read relays still true, or are you telling the network to look in places you abandoned months ago?

When something fails, diagnose by role. If your post is not visible, check your write relay and whether it accepted the event. If replies are missing, check where the other person writes and whether your client follows relay hints. If search is bad, do not blame every relay; ask whether you are using a search-capable relay at all. If a paid relay asks for auth, inspect the challenge. If a local community feed feels empty, ask whether people are actually publishing to the local relay or only reading from it. Role-based debugging is faster because each question has a place to go.

The relay market will keep changing. Some endpoints will disappear. Some will become stricter. Some will move from hobby infrastructure to paid service. Some will specialize around wallets, groups, media, archives or local spaces. That is not a failure of Nostr. That is the ecosystem discovering which rooms people need. Your job is to keep your identity portable while choosing rooms with care.

Local rooms and archives are where the market gets serious

The easiest relay mistake is imagining only the global social feed. That is where most people first meet Nostr, so it feels like the whole story. But the relay market becomes much more interesting when the room has a purpose: a conference, a members club, a developer team, a school, a music community, a hospitality venue, a creator circle, a neighborhood group, a research archive or a wallet product. In those cases, the relay is not a random URL behind a feed. It is the memory, admission and routing layer for a real use case.

A local relay should feel boring in the best way. It should be close to the community, fast enough that the room feels alive, clear about who can write, and easy to leave without losing your public identity. A local relay for a conference might carry session chat, speaker notes, badges, highlights and attendee introductions. A local relay for a club might carry member-only announcements, event threads and local reputation. A local relay for a product team might carry release notes, support events, device messages or narrow workflow data. None of those should require a closed social platform account if public keys and relay hints are handled well.

Archival pressure is different. A public relay can be generous without promising to remember everything forever. An archive relay needs a stronger posture: retention, backups, migration, export, disk costs, legal risk, spam management and a clear statement about what can disappear. If you want long-term memory, ask for the archive promise explicitly. Does the relay say how long it keeps events? Does it back up? Does it prune? Does it accept deletion requests? Does it mirror or deduplicate? Does it support Negentropy or other sync-friendly behavior through the wider ecosystem? A relay that feels fast today may still be a poor archive tomorrow.

That is where payment and governance meet. A paid archive relay can be a good bargain if it names the service clearly. A community archive can work if the group understands the cost and the operator has a succession plan. A free archive with no operator contact is a beautiful gift until it vanishes. You do not need cynicism here. You need adult expectations. Servers cost money, moderation costs attention, storage grows, abuse arrives, and someone has to carry the keys to the machine room.

Moderation belongs in the same conversation. A relay that accepts everything will eventually become hard to use. A relay that rejects too much can become a private platform in disguise. A relay with clear policy gives you something to choose. Spam filtering, allow lists, paid admission, proof-of-work, reports, labels, local moderation and group rules all shape the room. The question is not whether moderation exists. It always exists, even if the policy is neglect. The question is whether you can see the policy, disagree with it, and move without losing yourself.

The best relay market will not be one winner. It will be a layered set of rooms. Public relays for reach. Personal or paid relays for dependable writes. Search relays for discovery. Directory relays for identity context. Wallet relays for payment messages. Local relays for places. Archive relays for memory. Group relays for communities with rules. When clients show those roles plainly, you get choice without chaos. When clients hide them, Nostr feels random even when the protocol is doing exactly what it was designed to do.

A relay audit you can repeat in ten minutes

Pick one relay from your setup and ask six questions. First, what job does it do for you? If you cannot answer, remove it from the critical path until you can. Second, what does its NIP-11 document say right now? Look for supported NIPs, software, limits, contact and payment hints. Third, can you write to it and read the same event back from another client? Fourth, does your NIP-65 relay list tell other people to find you there, and is that still true? Fifth, what happens if the relay disappears tonight? Sixth, what would make you stop using it?

That last question is underrated. A healthy relay relationship has exit criteria. You may leave if the relay becomes unreachable, changes policy without explanation, hides payment terms, rejects events silently, stops publishing useful metadata, becomes too slow, attracts too much spam, or no longer serves the community you care about. Exit criteria turn relay choice into practice instead of loyalty theater.

Then repeat the audit across categories. Do not compare a wallet relay to a public social relay as if they were rivals. Do not compare a local club relay to a global search relay as if reach were the only value. Compare each relay with the job it claims. That is how you get a setup that feels calm: not because everything is perfect, but because every piece has a reason to be there.

Sources worth opening

Open these when you want the standard, implementation, monitor or operator trail behind the page. Treat them as live context, because relay metadata and service policies can change after publication.

Useful next pages

Back to Relays