Relays / Relay metadata

NIP-11: The Relay's Calling Card

NIP-11 lets a relay describe itself: name, contact, limits, supported standards, software and access rules.

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

Relays NIP-11 Sources

Relays32 min readNIP-11 metadata, operator legibility, relay limits and source trails

NIP-11: The Relay's Calling Card

NIP-11 is the small document that tells you whether a relay is willing to be legible: who it is, what it supports, what it limits, what it charges, what software it runs and how much context you get before you trust it.

The URL is not enough

A relay URL is only an address. It tells your client where to connect, but it does not tell you what kind of place you are entering. That is a problem because a relay can be many things: a broad public inbox, a paid archive, a spam-filtered write target, a profile directory, a wallet-connect transport, a group relay, a local venue layer or a private operator room. If all of those appear as bare wss:// strings, you are being asked to trust infrastructure blind.

NIP-11 fixes part of that blindness by giving relays a public information document. It does not make every relay good. It does not make operators accountable by magic. It does not replace testing. But it gives you a standard place to look before you depend on a server. The document can name the relay, explain its purpose, list supported NIPs, expose contact details, identify software, publish version information, set limits, declare payments or authentication, and sometimes point to policies or payment URLs.

This matters because relays are not interchangeable. A relay that accepts general notes for free is not doing the same job as a paid relay with restricted writes. A relay that accepts only Nostr Wallet Connect events is not a social timeline. A relay that supports NIP-86 management is signaling a different operator surface from a plain public strfry endpoint. A relay that publishes no contact gives you a different risk profile from one that names an operator and support path.

When you use Nostr casually, your client can choose defaults and keep you moving. That is fine at the beginning. But when your profile, publication, community, wallet flow, event archive or business surface depends on a relay, you need to move from “it connects” to “I know what it claims.” NIP-11 is where that shift starts. It turns infrastructure from rumor into a document you can read, compare and challenge.

The right mental model is a sign on the door. A good sign does not guarantee the room is clean, staffed or open forever. It still helps. You know the name, rules, capacity, contact and purpose before walking in. A relay without useful NIP-11 metadata may still work, but you should treat it like an unmarked room in a city you do not know.

How NIP-11 is fetched

The basic request is simple: take the relay's web host and ask for the relay information document with the Nostr accept header. A WebSocket relay such as wss://relay.damus.io maps to the HTTPS host https://relay.damus.io. A client or audit tool requests that URL with Accept: application/nostr+json. If the relay supports NIP-11, it returns JSON describing itself.

That design is quiet but important. You do not need a private API, an account or a special dashboard to learn basic relay facts. Directories such as Nostr Watch or nostr.co.uk can collect and display the same information, but the source of truth should be the relay's own host. If a directory and the relay disagree, start with the relay and then ask why the directory view is stale or enriched.

A normal browser visit may show a human page instead of the machine-readable document, depending on how the relay host is configured. That is why audit tools matter. The same host can serve a website to humans and a NIP-11 response to clients. For editorial work, product work or serious relay selection, you should check the machine-readable response directly, not only the pretty web page.

Fetching NIP-11 also reveals failure modes. Some relays do not respond. Some return invalid JSON. Some publish a minimal document with almost no context. Some advertise fields that look stale. Some expose rich limits, fee information and software versions. The variety is the point. NIP-11 lets you compare operators by what they are willing and able to publish.

Do not confuse a reachable NIP-11 document with a working relay. A host can return metadata while the WebSocket path is slow or restricted. A relay can connect but reject writes. A relay can show a good document and still be a poor fit for your use case. NIP-11 is the first inspection, not the whole inspection.

Name, description and contact are not decoration

The name and description fields tell you how the operator wants the relay to be understood. That sounds obvious until you compare real relays. relay.damus.io identifies itself with Damus and strfry. nos.lol describes broad note acceptance with spam filtering. nostr.mom is more explicit about spam and nudity filtering. relay.nostr.net names its operator context and even points to a Tor address. nwclay.paywithflash.com says it only accepts NWC events. Those short descriptions change how you should use the endpoint.

The contact field is just as practical. A relay may expose an email, a website, a Nostr identity or another support path. Damus relay publishes a maintainer email. Snort relay gives an admin contact. nostr.wine gives a domain-specific support address. relay.nostr.net points to its public web context. You do not need to contact every operator before using a relay, but if the relay becomes load-bearing, the presence or absence of a contact tells you a lot.

For a public relay, contact information is a maintenance signal. It says someone accepts that the relay is operated by a person or organization, not by the protocol itself. For a paid relay, contact becomes part of the service expectation. For a local relay, contact is how a venue, event or club can make its rules human. For a wallet relay, contact is part of incident response. If NWC messages fail at a counter, you want a trail that goes beyond “try another app.”

Descriptions also protect users from category mistakes. If a relay declares that it accepts only wallet-connect events, you should not paste it into your general social relay list and complain about missing notes. If a relay declares itself paid, you should not expect anonymous unrestricted writes. If a relay declares strict filtering, you should not assume it behaves like a neutral archive. NIP-11 lets the relay say what room it is.

Good metadata is therefore not marketing copy. It is a maintenance interface. The name, description and contact fields are the human edge of relay operations: who are you, what is this for, and where does a serious question go?

Supported NIPs are product clues

The supported NIPs list is easy to skim and easy to misuse. It tells you which standards the relay says it supports, not which user experience is guaranteed. Still, the list is one of the fastest ways to understand a relay's role. A general public relay often advertises NIP-01, NIP-02, NIP-04, NIP-09, NIP-11, NIP-28, NIP-40, NIP-45, NIP-70 and NIP-77. That cluster tells you the relay expects broad social traffic, deletion requests, public chat behavior, expiration handling, counting and protected-event context.

A paid or specialized relay may show a different shape. nostr.wine advertises NIP-42 and NIP-50 beside general relay support, which matters because authentication and search capability are part of its service surface. filter.nostr.wine advertises NIP-42, NIP-50, NIP-59, NIP-65 and NIP-94, making it feel more like a paid filter and broadcast tool than a plain public endpoint. Alby's NWC relay advertises NIP-47 because wallet-connect traffic is the point. NWClay's metadata lists NIP-47 as well and says it only accepts NWC events.

When you read the list, ask what the relay is trying to make possible. NIP-42 says auth can be part of the room. NIP-47 says wallet-connect messages may flow there. NIP-50 suggests search behavior. NIP-65 suggests relay-list or outbox context. NIP-86 points toward management APIs. NIP-11 itself says the relay is publishing the document you are reading. The list is not just compliance; it is a product map.

Also ask what is missing. If you expect search and NIP-50 is absent, test before assuming. If you expect wallet traffic and NIP-47 is absent, be cautious. If a relay is paid but does not advertise clear payment fields, inspect the surrounding site. If a client depends on a NIP the relay does not claim, the client should not blame the relay for failing to behave like a different product.

Supported NIPs can drift. Software upgrades, operator policy and custom forks can change behavior faster than metadata gets cleaned up. Treat the list as a claim, then test the behavior that matters to you. The claim is still valuable because it gives you something specific to verify.

Limits explain failure

Limitation fields are where NIP-11 gets beautifully unglamorous. They can describe maximum subscription counts, maximum result limits, maximum message size, maximum event tags, time bounds, payment requirements, auth requirements, restricted writes and other operational constraints. These are the numbers and flags that explain why a relay may feel “broken” when it is actually enforcing published boundaries.

Look at a few live patterns. Damus relay publishes a maximum result limit of 500, a large maximum message length and a high subscription limit. nos.lol advertises a smaller message size and fewer subscriptions. relay.nostr.net publishes a lower maximum result limit than many public relays. nostr.wine exposes payment-required and restricted-write behavior plus fee information. filter.nostr.wine declares auth-required and payment-required behavior. Those differences are not trivia. They shape client behavior.

A client that opens too many subscriptions against a relay with a low subscription limit may fail noisily or quietly. A client that asks for too many results may get fewer than expected. A publishing tool that creates very large events may hit message limits. A spam tool may crash into rate limits. A normal user may read all of that as “Nostr is unreliable” unless the client translates limits into plain language.

Limits also help you choose by job. A relay with low result limits may still be perfect for live social reach. It may be weak for archive browsing. A relay with strict writes may be useful for paid member spaces. A relay with higher message limits may fit media-adjacent metadata better, but you still need to consider storage and abuse. A wallet relay with narrow event acceptance may be excellent precisely because it refuses general traffic.

The best product design turns limitations into expectations. If a relay says payment is required, the UI should show that before you publish. If auth is required, the UI should explain the request. If the relay's limit is smaller than the client's query, the client should adjust or warn. NIP-11 gives software the raw material for that honesty.

Payment and auth should be visible

Payment and authentication fields are where relay metadata becomes trust UX. A relay that requires payment is not doing the same job as a free public endpoint. A relay that requires authentication is not the same room as an anonymous read path. Both choices can be legitimate. Both should be visible before the user is confused.

NIP-42 authentication lets a relay issue a challenge and ask the client to prove control of a public key by signing an auth event. That can reduce abuse, connect access to membership, unlock paid behavior or protect private rooms. The key point is that auth should feel explicit. You should know which relay is asking, which key will be used, and what behavior the authentication enables. Silent auth trains bad habits.

Payment is similar. nostr.wine's metadata is useful because it does not hide that the relay is paid. It publishes payment-required behavior, a payment URL and fee information in machine-readable form. filter.nostr.wine goes further into paid and authenticated filtering. Whether you like paid relays or not, that legibility is better than mysterious rejection notices. You can decide whether the service is worth it.

For communities and venues, auth and payment can be positive tools. A club relay may require member keys. A conference relay may require event registration. A professional archive may require payment to fund retention. A wallet relay may require narrow authorization because payment messages are sensitive. The open network stays open because the user can choose and leave; the individual room can still have a door.

The failure mode is hiding the door. If a client stores a paid relay as a default without explaining it, users feel tricked. If a relay asks for auth without naming itself clearly, users learn to approve signatures blindly. If a relay charges but publishes no terms, it invites mistrust. NIP-11 cannot solve ethics, but it gives operators and clients a place to be honest.

Software is a trust trail

The software field gives you a trail from relay behavior to implementation. Many public relays advertise strfry, including Damus relay, nos.lol, Primal public relay, Snort relay, nostr.mom, bitcoiner.social, offchain.pub and relay.nostr.net. Seeing strfry tells you the operator is using a well-known relay implementation, and it gives builders a repository to inspect for storage, performance, filtering and protocol behavior.

Other relays point elsewhere. Alby's NWC relay identifies itself as alby-nwc-relay. NWClay points to a specialized implementation and describes NWC-only behavior. purplepag.es points to its own project and advertises NIP-86, which makes sense for a profile directory and relay management surface. A relay built on khatru, nostream, nostr-rs-relay, Grain, Nostrify or a custom fork may have very different operator affordances.

For normal users, software may feel like a builder detail. For serious dependency decisions, it is not. Software affects performance, admin tools, moderation hooks, retention behavior, database choices, backup paths, index behavior, compatibility and upgrade rhythm. A relay with transparent software is easier to audit. A proprietary service can still be valuable, but you should know when you are relying on an opaque operator service instead of inspectable code.

The version field is useful for the same reason. It lets you spot stale deployments, compare behavior among relays using the same stack and notice whether an operator keeps up with changes. A version string is not a guarantee of security or maintenance, but its absence gives you less context. When a relay becomes part of your product, version blindness is not charming.

Software also tells you how portable the relay idea is. If you love a relay's behavior and it runs open software, you may be able to reproduce a similar role elsewhere. If a relay is unique and closed, your exit path depends more on the operator. Nostr is strongest when the protocol, metadata and implementation trail remain inspectable enough for people to move.

Live examples change the reading

Concrete metadata makes relay literacy real. Damus relay presents as a public strfry-backed relay with broad social NIP support and visible limits. That makes it useful as a broad client-adjacent endpoint, not as a guaranteed personal archive. nos.lol presents a similar broad public shape but explicitly mentions spam filtering and publishes tighter subscription limits. nostr.mom pushes the policy description further by naming spam and nudity filtering. Those are public rooms with different house styles.

Primal's public relay and Snort's relay both advertise recognizable client-adjacent infrastructure. That does not mean the client company owns every user experience on the network. It means those relays sit near products users already know, so they often appear in default or familiar relay sets. You should still inspect limits, contact and software before leaning on them.

relay.nostr.net is interesting because its metadata points to a public operator context and a Tor route. That changes the way you read it. It is not just another public endpoint; it is also signaling a particular infrastructure stance. bitcoiner.social and offchain.pub publish public relay metadata with contacts and strfry software. Again, the details help you decide whether you are looking at reach, community identity, operator continuity or just a convenient endpoint.

nostr.wine and filter.nostr.wine show the paid side more clearly. The first advertises paid relay access, payment-required behavior, a payment URL, admission pricing and supported NIPs including auth and search. The filter relay advertises auth-required and payment-required behavior with a subscription fee. Whether you use them or not, the metadata tells you the economic model before you trip over it.

Alby and NWClay show why NIP-11 matters beyond social posting. Alby's relay says it is for Nostr Wallet Connect. NWClay says it only accepts NWC events and advertises NIP-47. A user who reads that correctly will not treat those endpoints as timeline relays. A wallet builder who reads that correctly will inspect permissions, uptime and relay behavior as part of payment infrastructure.

What clients should show

A good client should not throw raw relay URLs at people and call the job done. It should show the relay name, purpose, payment/auth state, basic limits, supported features and operator contact when those fields matter. It should hide detail gently for beginners while keeping the inspection path one click away for anyone making serious choices.

Relay errors should use NIP-11 context. If a relay has payment_required, a publish failure should not feel like a mystery. If auth_required is true, the client should explain the signature request. If the user's query exceeds max_limit, the client should adapt or say why fewer results arrived. If the relay advertises only NWC behavior, a social client should not quietly add it to a generic publish list.

Clients should also show roles, not only URLs. Public reach, personal archive, paid write target, search relay, local venue relay, group relay, wallet relay and test relay are different jobs. A user can make better decisions when the settings surface reflects those jobs. NIP-11 provides some of the evidence; the client supplies the human framing.

For power users, clients should expose the raw document. You may want to compare supported NIPs, inspect software, verify a payment URL or copy a contact. Hiding the raw material forces people into external tools. Nostr is supposed to make infrastructure legible; the client should not rebuild platform opacity at the settings screen.

The best version is progressive disclosure. New users see “broad public relay, no payment, normal limits.” Advanced users can open the full JSON, test writes, compare liveness and manage read/write roles. Both levels matter. Beginners need calm. Operators and serious users need detail.

What operators should publish

If you run a relay, NIP-11 is your first act of respect toward users and client developers. Publish a name that people can recognize. Write a description that says what the relay is for. List supported NIPs accurately. Keep limits current. Name software and version where possible. Add a contact that you actually monitor if the relay is public, paid, local or otherwise important.

If the relay requires payment, publish payment fields and terms. If it requires authentication, say so. If writes are restricted, say so. If you filter spam, adult content, illegal material, large events, old timestamps or specific event kinds, say enough that users understand the room. You do not need a novel in the metadata, but you do need honesty.

Local relays need especially clear metadata. A venue relay, conference relay, cafe relay, hotel relay or city relay should not look like a random public endpoint. Say where it belongs, who operates it, what it stores, how long it intends to retain data, who can write and how people should get help. Local context is useful only when people can recognize the place.

Wallet and payment relays need sharper boundaries. If the relay is for NWC traffic, state that. If it only accepts certain event kinds, state that. If operators, merchants or staff depend on it, include a support path and current version. Payment infrastructure has less tolerance for mystery than public chat.

Finally, keep the document alive. Stale NIP-11 metadata erodes trust because it proves the visible promise is not being maintained. If you change software, update it. If you change limits, update them. If you move payment terms, update the URL. Metadata is not a launch task; it is part of relay operations.

How to audit a relay

Start with the NIP-11 response and write down the basics: name, description, contact, supported NIPs, software, version, payment/auth flags and limits. Then ask whether the page matches the job you want. A public reach relay, paid archive, wallet relay, profile directory and local event relay should not pass the same test. The job defines the evidence you need.

Next, test behavior from a client or a simple Nostr tool. Publish a harmless event if writes should be open. Query a known event if reads should work. Test large and small filters. Watch whether the relay returns clear errors. Try unauthenticated behavior if NIP-42 appears. If payment is required, test the before-and-after state with a small account, not your most important identity.

Then compare the relay to outside signals. Check a monitor such as Nostr Watch. Look at relay directories for stale or conflicting information. Inspect the software repository if the relay names one. Search for operator pages or public policy. If the relay is paid, read the pricing and support path. If it is local, verify that the organization behind it is real.

After that, decide the role. Use the relay for broad reach only if it is public and socially connected enough. Use it for durability only if retention, payment, backups or operator commitment make sense. Use it for wallet traffic only if the NWC behavior is narrow and documented. Use it for a community only if moderation, access and exit are clear. Avoid the lazy middle where an endpoint becomes important just because it was once copied into a settings page.

The audit does not need to be dramatic. Ten minutes with NIP-11, one test publish, one test read and one liveness check can save hours of confusion later. The relay layer rewards people who inspect before they depend.

Where metadata can mislead

NIP-11 can make a relay legible, but it can also make a weak relay look more confident than it deserves. The document is self-published by the operator. There is no central reviewer checking whether every supported NIP is fully implemented, whether the contact is monitored, whether the software version is current, whether limits match runtime behavior, or whether payment terms are still accurate. Treat the document as a claim with structure, not as a certificate.

The most common trap is stale support. A relay may advertise a NIP because the underlying software supports it in theory, while the operator's configuration, policy or fork changes the practical behavior. Another relay may support a NIP but only for certain event kinds, only after authentication or only for paid users. If your client sees the NIP number and assumes a full product promise, your UI will mislead people. The right phrasing is softer: “the relay advertises support,” then test the behavior that matters.

The second trap is missing context. A relay can publish a name, software and limits while saying almost nothing about policy. That may be fine for a hobby endpoint. It is not enough for a paid service, a venue network, a wallet relay, a local community archive or a professional publishing path. If people are going to depend on the relay, metadata should explain what the operator wants the relay to be. A technically valid NIP-11 document can still be socially thin.

The third trap is overreading contact and software. A contact email does not mean support will answer. Open-source software does not mean the deployment is well maintained. A version string does not mean the database is backed up. A payment URL does not mean the business is stable. NIP-11 gives you handles for deeper inspection; it does not remove the deeper inspection. This is exactly why a good relay decision combines metadata, liveness checks, test events, directory context and operator judgment.

For a normal user, the takeaway is simple: trust NIP-11 enough to start, not enough to stop. For a builder, it means your client should word claims carefully. For an operator, it means metadata should stay close to reality. The fastest way to lose confidence is to publish a clean document that no longer describes the relay people are actually using.

Venues, wallets and local rooms need sharper metadata

The more specific the relay role, the more important NIP-11 becomes. A broad public relay can get away with rough context because people mostly use it for reach. A local venue relay cannot. If a hotel, cafe, event, club or coworking space runs a relay, the metadata should make the place obvious. Name the venue or network. Explain whether visitors, members, staff or operators can write. Name the contact. Say whether the relay is temporary or durable. A local relay without local context feels like a random endpoint with a nice idea hidden inside.

That matters for Crays-style real-world rooms, but it also matters for the wider Nostr ecosystem. Local relays are how Nostr can become useful at conferences, meetups, campuses, hospitality spaces, cultural events and city communities without putting everyone into a closed app. The relay becomes the memory layer for a place. Public keys keep identity portable. NIP-11 tells the person at the door what the place is for.

Wallet relays need the same clarity for a different reason. When a relay carries Nostr Wallet Connect traffic, the user is no longer only thinking about posts and replies. They are thinking about invoices, permissions, wallet services, merchant devices and revoke paths. Alby's relay and NWClay are useful examples because their metadata points toward NWC rather than pretending to be ordinary social relays. That distinction should be visible in every client that touches them.

Group and moderation relays also need sharper metadata. A relay used for NIP-29-style groups, web-of-trust filtering or community moderation should explain admission and policy. Who can create groups? Who can moderate? Are writes restricted? Is auth required? What kind of content is rejected? Users can accept strict rooms when the room is honest. They get frustrated when strictness appears only as mysterious failures.

Professional archives need the most boring metadata of all: retention, payment, limits, support and exit. If someone stores long-form work, project records, event material or a public identity trail on a relay, they need to know whether the operator treats that storage as temporary, best-effort, paid, backed up or unsupported. NIP-11 cannot express every contract detail, but it can point to the policy page and make the first promise visible.

There is also a design lesson here. A specific relay should not force every user to become a protocol analyst. The relay can publish clear metadata, the client can translate it into human language, and the user can still keep agency. “This is a paid archive relay with restricted writes” is enough for most people. “This is an NWC-only relay; do not use it for social posting” is enough for a merchant. “This local relay belongs to the event and may be temporary” is enough for a guest deciding where to publish local comments.

That is why NIP-11 belongs in product thinking, not only protocol documentation. It is one of the few places where operator honesty, client UX and user trust meet in a small, inspectable file. When that file is cared for, the whole relay layer feels less like folklore and more like infrastructure you can choose with open eyes.

If you run a relay, the simplest standard is this: write the NIP-11 document as if someone smart but busy will open it five minutes before trusting you. Do not make them decode your intent from a cute name, an empty description and a list of numbers. Tell them what the relay does, who should use it, what it refuses, how long it intends to remember, when payment or authentication appears, and where support lives. Good metadata does not make the relay perfect. It makes the first conversation honest, and honest first conversations save users from turning infrastructure choices into guesswork.

Sources worth opening

Use these when you want the standard, implementation trail, monitoring context or live operator examples behind NIP-11.

Useful next pages

Back to Relays