Relays / Relay basics

Nostr Relays: Where Signed Events Actually Live

A client shows the feed, but relays decide where signed events can be written, found, filtered, searched and recovered.

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

Relays NIP-11 Sources

Relays34 min readRelay basics, NIP-11, NIP-42, NIP-65, NIP-66 and operator trust

Nostr Relays: Where Signed Events Actually Live

A client shows the feed, but relays decide where signed events can be written, found, filtered, searched, paid for and recovered. If you understand that layer, Nostr stops feeling like a magic social app and starts feeling like a network you can actually steer.

Your client is the cockpit, not the airport

Nostr gets easiest when you separate the thing you touch from the place your data travels through. The client is the cockpit: Damus, Amethyst, Primal, Coracle, noStrudel, a command-line tool, a wallet app, a local community interface. It helps you write, sign, read, search, react, zap, moderate and move around. The relay is the airport, warehouse and customs desk underneath: it accepts signed events, stores some of them, serves them back to clients, rejects others and quietly decides whether your social life feels fast, empty, noisy or reliable.

That distinction matters because Nostr's promise is not “one perfect app will replace every platform.” The promise is that your identity can survive app changes because events are signed by your key and passed through relays. You can swap clients because the client is not supposed to be the only database. But the swap works only when the new client knows where to ask, when the relevant relays still have the events, and when those relays are willing to serve them.

Most early confusion comes from treating a relay URL like a harmless setting. It is not harmless. If your client publishes to a relay nobody else reads, your note may be valid and invisible. If your profile metadata lives on a relay a new client never queries, you look half-born. If your replies sit on a relay that prunes aggressively, a conversation feels broken months later. If a wallet flow depends on a relay that is overloaded, a payment action feels like the app failed even though the missing piece is routing.

The healthiest habit is to read relays as infrastructure with character. One relay may be broad and public, useful for reach but weak as a personal archive. Another may be paid and strict, better for durability but less useful for public discovery. Another may be local to a venue, event or group, great for context and terrible as your only public outbox. A search relay can make old material visible without being the place you publish daily. A wallet relay can carry Nostr Wallet Connect traffic without pretending to be a social timeline.

Once you see those roles, the network gets less mystical. A relay set becomes a living map of how you want to be found. Your client can still hide most of the complexity, especially at the beginning, but it should not hide the idea forever. Serious use of Nostr eventually asks you to understand where you write, where others read, where discovery comes from, which relays can ask for authentication, and which operator you are leaning on when something matters.

NIP-01 gives the relay grammar

NIP-01 is the basic relay grammar. It defines the event shape and the client-relay messages that make Nostr feel simple on the surface: a client sends an EVENT, opens a REQ subscription with filters, receives matching EVENT messages, gets EOSE when stored events have been sent, and hears back through OK, CLOSED or NOTICE when the relay accepts, rejects or explains something. Those words look like protocol furniture, but they are also product behavior.

When you press publish, the relay is allowed to say yes or no. It can accept the event and return an OK. It can reject the event because the signature is wrong, the event is too large, the timestamp is strange, the event kind is not allowed, the relay requires payment, the relay wants authentication, or the relay is defending itself against spam. A good client should show that difference. “Failed to post” is almost useless; “relay rejected: payment required” or “relay rejected: authentication required” gives you a path.

When you read, NIP-01 filters decide what the relay is asked for: authors, event ids, event kinds, tags, time windows and limits. That means a feed is not a natural object. It is the result of a client choosing filters, asking relays and merging responses. Two clients can show different realities for the same public key because they ask different relays, use different filters or stop waiting at different times. That is not a bug in decentralization; it is the cost of making the data layer visible.

The EOSE message is a good example. It tells the client that the relay has sent stored events matching the subscription. It does not mean the whole network is done. It means this relay is done with this request. A timeline can look complete when one relay responds quickly and still be missing events that live elsewhere. This is why relay selection and outbox discovery matter. The client needs better hints about where to ask.

NIP-01 also makes replaceable and addressable behavior feel more understandable. Profile metadata, relay lists, community definitions and long-form notes are not magic records in a central account table. They are signed events with specific kinds and tags. Relays store and serve them under rules. If the latest replaceable event is not found, a profile looks old. If an addressable event is not on the relays a client queries, a long-form page may feel missing. The protocol grammar is simple; the operational reality is where you need taste.

NIP-11 is the door sign

NIP-11 is the relay information document, and it should be the first place you look after seeing a relay URL. A relay can expose machine-readable metadata over the same host when a client or browser requests it with the Nostr media type. The document can name the relay, describe its purpose, list supported NIPs, publish a contact, identify software, show version details, explain limits, declare whether payment or authentication is required, and sometimes point to policy or payment pages.

That is not paperwork. It is the relay's front door. When Damus relay identifies itself as a strfry relay and lists supported NIPs and limits, you learn how broad public client infrastructure presents itself. When nostr.wine declares payment-required behavior and exposes admission pricing through its metadata, you learn that you are dealing with a paid service, not a generous free endpoint. When purplepag.es advertises NIP-42 and NIP-86 beside directory behavior, you can infer that profile discovery and relay management are part of its design.

The fields also help you separate promises from guesses. A relay that publishes max_limit, max_message_length and max_subscriptions is telling client developers how not to be rude. A relay that declares payment_required, auth_required or restricted_writes is giving users a reason before the UI becomes mysterious. A contact field gives you a human or organization to inspect. A software field lets you trace the implementation and understand which features might exist underneath.

NIP-11 does not make a relay trustworthy by itself. Operators can publish stale metadata, omit policy, exaggerate support or run a fork you cannot inspect. But a missing or vague information document should lower your confidence. If a relay becomes important to your publication, business flow, group, wallet, event archive or venue network, you should not be satisfied with a bare WebSocket string. You want a named operator, clear limits, current software, visible policy and some way to know when the rules change.

The practical move is simple: when a relay matters, open its information document before you recommend it. Look for the basics, then ask what is absent. Is there a contact? Are payment terms visible? Does it say whether writes are restricted? Does it name software? Does it support the NIPs your use case needs? Are limits reasonable for your client? If the page gives you enough to make a decision, great. If it only says “relay,” treat it like infrastructure without a sign on the door.

Policy is product design

Every relay has policy, even when the operator never writes a public manifesto. The policy may live in code, nginx limits, database retention, payment gates, spam filters, moderation lists, legal caution, operator patience or pure neglect. A relay can accept most notes, reject certain event kinds, require proof-of-work, require NIP-42 authentication, charge for admission, filter explicit material, refuse very old timestamps, cap result counts or disappear after the maintainer gets tired of the bill.

This does not make relays equivalent to old platforms. A platform owns the account, database, discovery surface and exit path in one bundle. A relay is one operated place inside an open network. You can leave it, publish elsewhere and keep the same public key. But the relay still has power over the events it accepts and serves. Nostr does not remove moderation and infrastructure judgment; it moves those choices closer to the places where events live.

That is why “censorship-resistant” should be read carefully. Your key can sign anywhere, and no single relay defines the whole network. That is powerful. But an individual relay can still say no, and a client can still make the network feel narrow by using a small set of defaults. The real resilience comes from plurality: many relays, readable policies, portable identity, visible relay lists, multiple clients, and users who know how to move.

Policy is also how relays stay usable. A public relay that accepts everything forever becomes expensive and abusive fast. Spam, illegal content, duplicated events, bots, large media references, hostile queries and high-volume clients all have costs. A strict relay may feel less open, but it may also be the reason normal users can read without drowning. A paid relay may feel less egalitarian, but it can align the server bill with people who actually depend on the service.

The UX challenge is to make policy legible without making new users feel punished by infrastructure. A client should not hide relay rejection behind a vague toast. It should show when a relay requires payment, auth, smaller events or different timing. A hub like this should not rank relays as good or bad in the abstract. It should explain the policy surface so you can pick the right place for the job.

Relay lists make you findable

NIP-65 exists because discovery cannot depend on everyone guessing the same global relays. A user can publish relay list metadata to say, in effect: these are the relays where you should look for my events, and these may have different read or write roles. That turns relay choice from private client preference into a public routing hint. It is one of the quiet standards that makes Nostr more than a loose pile of endpoints.

Without relay list metadata, clients fall back on defaults, social guesses, old contact lists, search relays or brute-force querying. That can work for small networks and popular public relays, but it scales badly. A person who posts mostly through a paid relay, a local relay, a niche community relay or a self-hosted relay can become hard to find if followers never learn where to read. The events may be valid, yet the route to them is missing.

A relay list is not a guarantee. It can be stale, too long, too short, weirdly copied between clients or ignored by lazy software. But it is still a better social object than hidden client settings. It lets clients build smarter discovery. It lets power users inspect someone's routing choices. It lets communities document local relays without trapping identity inside the community app. It also gives you a way to clean up after years of adding random relays.

The important detail is that relay lists should be purposeful. More relays is not always better. A huge list can slow clients, leak more behavior, increase duplicate traffic and hide the roles each relay is supposed to play. A tiny list can make you fragile. The useful list names the places that actually matter: where you write, where others should read, where a community expects you, where your archive lives, where search can help, and where a specialized workflow runs.

When you audit your own Nostr setup, open the relay list your main client publishes. Ask whether it describes your real life or a pile of historical defaults. If you moved to a paid relay, did the list change? If you joined a community relay, is it marked in a way other clients can use? If you stopped using a dead public relay, did you remove it? Findability is not only a protocol problem. It is a maintenance habit.

Outbox discovery changes the social graph

Outbox discovery is the practical idea that clients should follow where a person writes instead of pretending the whole network lives on one shared timeline. If your profile tells the world which relays carry your events, another client can ask those relays first. That reduces waste, makes niche relays more usable and lets people build smaller, more intentional relay sets without disappearing from everyone else's feed.

The word “outbox” is helpful because it shifts attention from the viewer's favorite relay to the author's publishing path. In older platform thinking, the server owns the social graph and feed. In naive Nostr thinking, everyone throws events at a handful of large public relays and hopes discovery works. In the outbox model, the author gives you hints. You do not need to ask the entire world where their events are; you ask the places they have named.

This is especially important for local, paid and professional use. A venue may publish updates through a local relay plus a broad public relay. A creator may keep a paid archival relay for long-form material and a public relay for reach. A wallet service may use specialized NWC relays that should not be treated as ordinary social endpoints. Outbox-aware clients can respect those differences while still giving users one coherent experience.

Outbox discovery also changes the cost structure. Relays do not need to become universal everything stores. Clients can avoid spraying every request everywhere. Smaller relays can matter because they are discoverable through the people and groups that use them. That opens a path for community relays, venue relays, event relays and paid personal relays without turning them into isolated islands.

The danger is stale hints. If a user publishes a relay list and never updates it, followers may keep asking old relays. If clients overwrite relay lists carelessly, a person's public routing map can get noisy. If relay operators disappear, the outbox trail can become a memorial. The answer is not to abandon the model. The answer is better UI: show which relays are active, which are failing, which are write targets, which are read hints, and when the list was last updated.

Auth and payment change the room

NIP-42 gives relays a way to ask clients to authenticate without handing over a private key. The relay sends an AUTH challenge. The client signs an auth event that proves control of the user's key for that relay and challenge. The relay can then decide whether to allow reads, writes or privileged behavior. In plain language: the relay can ask, “who are you?” before opening the door.

That changes the room. A public relay with no auth feels like a town square entrance. A relay that requires auth for writing can defend itself against some abuse while still letting identity remain portable. A paid relay can connect auth to a membership or invoice. A private relay can restrict access to a team, event, club or operator group. A wallet relay can make sure only the right app and key pair are talking through a sensitive channel.

Authentication is not automatically privacy. Signing an auth event tells the relay which public key is asking. That may be exactly what you want for a paid or private service. It may be unnecessary for casual reads. A good client should show when a relay asks for authentication and why the request is reasonable. A good relay should avoid asking for auth where it does not need it. Invisible auth prompts train users badly.

Payment adds another layer. NIP-11 metadata can declare payment-required behavior and provide payment URLs or fee information. nostr.wine is a useful example because it openly advertises a paid relay service, supported NIPs and fee terms. A paid relay does not magically become more trustworthy, but it does answer one operational question: who pays for storage, bandwidth and abuse handling? Free infrastructure is generous; paid infrastructure can be accountable if the terms are visible.

For you, the choice is not ideological. Use public relays when reach and openness matter. Use auth-required or paid relays when the job needs clearer admission, higher reliability, lower spam or a defined relationship with an operator. Use private relays when the space is not supposed to be a public firehose. The open network stays open because you can choose among these rooms and move when a room stops fitting.

Liveness is not a vibe

A relay being listed somewhere does not mean it is alive, fast, writable, readable or useful for your location. Relay directories are starting points, not production audits. A raw list of hundreds of endpoints can help you discover candidates, but it should never be copied into a serious client or app without validation. Stale relay lists are one of the easiest ways to make Nostr feel slower than it is.

NIP-66 addresses this by defining relay discovery and liveness monitoring events. The Nostr Watch ecosystem grew around the same problem: how do you know which relays are reachable, what they claim, how they respond, and whether monitoring results can be shared through Nostr itself? A live relay map is more useful than a static bookmark because relay health changes. Servers move, operators quit, DDoS happens, policies change, certificates expire and storage fills up.

Liveness is more than ping. For a real decision, you want to know whether the relay responds over WebSocket, whether the NIP-11 document is reachable, which NIPs are advertised, whether auth or payment is required, how strict the limits are, whether writes work, whether reads return expected events, and whether performance is acceptable from the places your users actually are. A relay can connect and still be wrong for your job.

Monitoring also protects operators from vague complaints. If a client can show that a relay returned CLOSED for a filter, rejected an event with a specific reason, or stopped responding after a limit, the conversation becomes precise. “Nostr is broken” turns into “this relay is rejecting old timestamps” or “this client is asking for too much at once.” Precision is boring, and boring is what infrastructure needs.

When you build a relay set, use liveness as a recurring practice. Check candidates before adding them. Check important relays again after a few weeks. Watch for relays that were once famous but are now tired. Keep an eye on relays that support your wallet flows, groups, public identity and archive. Nostr gives you exit. Monitoring tells you when to use it.

The relay portfolio

The best relay setup is rarely one relay and rarely fifty. Think portfolio. You want a small set of relays with different jobs, clear enough that you can explain why each is there. A broad public relay helps your notes meet common client defaults. A personal or paid relay improves durability. A search relay helps discovery. A local relay serves a place, team or event. A wallet relay carries NWC messages. A group relay supports moderated community flows. An archival relay protects material you would hate to lose.

The portfolio lens keeps you from chasing lists. If you add a relay, name the role. Reach? Archive? Search? Local context? Wallet traffic? Inbox? Moderated group? Testing? If you cannot name the role, the relay is probably just noise. Noise has costs: more network requests, more metadata leakage, more confusing failure states and more places to clean up later.

Start with what your client already uses. Open the relay list. Identify broad public relays, client-specific relays and any old endpoints you no longer recognize. Remove dead ones. Add one or two reliable write targets if your posts matter. If you publish long-form work, keep a relay that has a plausible retention story. If you run a community, create a local or group relay with visible policy. If you depend on wallet actions, treat the wallet relay as financial infrastructure, not a random URL.

Then test from outside your own client. Publish a note and see whether another client can find it. Update your profile and see how long it takes to propagate. Search for an older event. Test a reply chain. If you use a paid relay, test what happens when you are not authenticated. If you use a local relay, test what a person outside the venue sees. This is how you turn a relay list from a settings page into an operational map.

The portfolio should stay small enough to maintain. You do not need to become a relay administrator just to use Nostr, but you should know which endpoints are load-bearing. The more important your profile, business, publication, venue, wallet or community becomes, the more deliberate the portfolio should be.

Public, paid, private and local are different promises

Public relays are the easiest to understand and the easiest to overtrust. They let many people write and read with little friction. They are useful for reach, onboarding and common defaults. They are also magnets for spam and abuse, and they rarely owe you long-term retention. Use them. Appreciate them. Do not make them the only copy of work you care about.

Paid relays make a different promise. They put a price near storage, bandwidth and moderation. That can reduce spam, fund better operations and create a clearer relationship between user and operator. It can also exclude people, create support expectations and fail like any business. A paid relay is not morally superior. It is a useful tool when reliability, admission control and accountability matter enough to pay for.

Private relays are for narrower rooms. A team, family, operator group, club, high-trust project, beta community or venue may need events that are not intended for a public firehose. Nostr is not automatically private just because a relay is private; event kinds, encryption, metadata and client behavior still matter. But a private relay can limit who writes, who reads and which context belongs in the room.

Local relays are where Nostr gets physical. A conference can run a relay for schedules, badges, session comments and local discovery. A hotel, cafe, club or coworking space can use a local relay for place-based reputation, offers, bookings, loyalty and community updates. A city group can make local events easier to find without forcing everyone into one app. The local relay becomes a memory layer for a place while public keys keep identity portable.

The mistake is treating these categories as a hierarchy. They are roles. A person may need all four at different moments. A creator publishes broadly, archives privately, joins a paid relay for durability and uses a local relay at an event. A business uses public relays for announcements, private relays for operator coordination, wallet relays for payments and local relays for customer presence. Relay literacy means matching the room to the job.

Software tells you how a relay breathes

The software field in NIP-11 is worth reading because implementation choices become behavior. strfry is widely visible across public relays such as relay.damus.io, nos.lol, relay.primal.net, relay.snort.social, nostr.mom, offchain.pub and relay.nostr.net. It is known as a high-performance C++ relay implementation and often appears in public relay metadata. Seeing strfry does not prove the operator is good, but it tells you where to inspect defaults, capabilities and known behavior.

nostr-rs-relay gives another path: a Rust implementation that has been used by operators who prefer that stack. nostream represents a Node/TypeScript-era relay server with a different operational feel. Khatru is less a turnkey public relay and more a framework for writing custom relays in Go, which matters for specialized behavior. Grain, wot-relay, filter-relay, Nostrify and mobile relay experiments like Citrine show that relay work is not one software monoculture.

This diversity matters because “a relay” can be anything from a broad public store to a custom policy engine. A wallet relay may accept only NWC-related events. A filter relay may enforce paid-user broadcast behavior. A web-of-trust relay may use social graph rules to decide what it accepts. A group relay may encode moderation roles. A local relay may be tuned for a venue's event kinds and retention. The implementation is where those rules become reality.

When you evaluate a relay, treat software as one evidence trail. Is the project maintained? Does it publish releases? Does the operator identify a version? Does the software support the NIPs the relay claims? Is the relay doing something custom that deserves more inspection? If the relay is load-bearing for your product, you should know whether it is a common implementation, a fork, a small custom app or a managed service.

Software also shapes exit. A relay with transparent open-source software is easier to replicate, audit or migrate away from. A proprietary relay service can still be valuable, especially when the operator is reliable, but you should understand the dependency. Nostr's openness is strongest when the data model, relay hints and implementation trail are all visible enough for you to move.

Failure has patterns

Relay problems often look like app problems because the client is where you see the pain. A post spins forever. A reply is missing. A profile image disappears. A zap-related action fails. A group does not load. A feed shows old notes. A search cannot find your work. Before blaming Nostr as a whole, ask which relay step failed: publish, store, read, filter, auth, payment, discovery or retention.

Publish failures are usually the easiest to diagnose if the client surfaces relay responses. The relay may reject the event, require payment, require auth, rate-limit you, reject old timestamps, reject oversized content, refuse the event kind or be unreachable. Read failures are trickier because absence is quiet. The event may never have been written to that relay, may have been pruned, may be hidden behind auth, may require a better filter, or may live on the author's outbox relays.

Discovery failures sit between people. Your client may not know the author's relay list. The author's list may be stale. The author may publish through a relay your client ignores. A search relay may index one set of relays and miss another. A community may rely on local relays that public clients never ask. The event exists, the signature is valid, and still the social experience feels broken because routing failed.

Retention failures show up late. A relay that felt fine during a live conversation may not preserve the thread. A public relay may prune old data. An operator may rebuild. A paid relay may change terms. A local event relay may be intentionally temporary. If you care about archives, you need a relay with a retention story and backups outside the hope that public defaults will remember everything for free.

The point is not to make you anxious. It is to give you a diagnostic map. When something fails, write down the event id, author, event kind, client, relay list, relays queried, relay responses and time. Test from another client. Open NIP-11. Check liveness. If the event matters, store it in more than one place. The network becomes calmer when failure has names.

Your audit routine

Begin with your own relay list. Which relays do you write to? Which do you read from? Which ones are defaults you inherited? Which are dead? Which are paid? Which are local? Which are specialized? If your client does not make this visible, use another tool for the audit. Your relay list is part of your public route through the network, not a drawer full of random endpoints.

Next, open the NIP-11 information document for every relay that matters. Look for name, description, supported NIPs, contact, software, limits, payment, auth and policy. You do not need every field to be perfect, but you should know what is missing. A relay with no contact and no clear limits may still be useful for casual reach. It should not be the only place your business-critical content lives.

Then test behavior. Publish a small note. Read it from another client. Update your profile. Query older events. Try the relay with and without authentication if it supports NIP-42. If it is paid, confirm what happens before and after payment. If it is local, test from outside the local app. If it is a wallet relay, test NWC flows with tiny permissions and a revoke path you actually understand.

After that, assign roles. Mark broad public relays for reach. Mark paid or personal relays for durability. Mark search relays for discovery. Mark local relays for place-based context. Mark wallet relays for payments. Mark group relays for moderated rooms. Remove endpoints that have no role. The result should be boring enough that you can explain it to a friend without opening a spreadsheet.

Finally, repeat. Relay infrastructure changes. Operators upgrade software, add auth, introduce payments, change limits, close registrations, disappear or improve. The set that worked six months ago may be stale today. A quarterly relay audit is not overkill if your Nostr identity carries real work, customers, members, readers, payments or community memory. The open web rewards people who keep their maps current.

Sources worth opening

Use these when you want to check the standards, operator pages, monitoring projects and implementation trails behind the relay layer.

Useful next pages

Back to Relays