NIP-11: Relay Information Document
Relays need a front door
A Nostr relay is more than a WebSocket endpoint. It has policies, limits, software, operators, payment rules, admission rules, supported NIPs and sometimes legal or community context. NIP-11 gives relays a small public information document so clients and users can see that context before treating the relay as a neutral pipe.
The standard uses the same relay URI but asks for it over HTTP with an Accept: application/nostr+json header. If the relay supports the document, it returns JSON describing itself. That is a simple design choice with large practical value: the relay's metadata lives at the front door, not on a separate website a client may never find.
For users, NIP-11 is the difference between wss://some-host and a relay with a name, contact, software identity, limitations and price signals. For developers, it is where relay diversity becomes machine-readable.
Capabilities, limits, contacts and money
The basic document can include name, description, banner, icon, administrative pubkey, contact, supported_nips, software, version and terms links. The fields give clients enough information to display the relay and, more importantly, to adjust behavior.
The limitation object makes the page operational. It can advertise message length, subscription count, maximum limits, tag count, content length, proof-of-work requirement, authentication requirement, payment requirement, restricted writes, created-at bounds and default query limits. A client that ignores those fields may look broken when the relay is simply enforcing policy.
The fees object adds the pay-to-relay story: admission, subscription and publication fees. That does not make a relay good or bad. It makes the relationship visible. A paid relay, a public relay, a restricted community relay and a specialized archival relay can all use NIP-11 to describe themselves.
Relay metadata grew with relay politics
NIP-11 entered the visible repo in May 2022. The later file history reads like relay operations becoming more serious. Alltheseas added banner and icon fields in 2024, then privacy and terms fields in 2025. K. adjusted limit fields in 2025, Alex Gleason fixed default-limit semantics, and hodlbod added the self field. In 2026, fiatjaf removed bloat while Awiteb refined terms text.
The pattern is clear: as relays became products, communities and infrastructure businesses, their metadata needed to describe more than supported NIPs. A relay operator may need to state how much data it accepts, whether auth is required, whether payment is required and how a user can contact the operator.
Issues around NIP-11 without WebSocket and relay handshake ideas show the tension. Developers want simple discovery and richer negotiation. NIP-11 remains the basic public document because it is easy to fetch, easy to cache and easy for relay software to expose.
Relay software turns the document into policy
Relay implementations make NIP-11 concrete. nostr-rs-relay exposes relay information through configuration, including name, description, admin contact and advertised URL. Rust Nostr models the relay information document as a typed structure. Mattn's relay code and other small relay projects expose the same idea in different stacks.
Other standards now depend on NIP-11 context. NIP-43 uses relay access metadata and admission requests, which makes relay policy visible beyond a simple yes-or-no connection. NIP-66 relay liveness monitoring explicitly notes that relay discovery events can derive characteristics from the NIP-11 document and that advertised fields may contradict what probing finds in practice.
That last point is crucial. NIP-11 is an advertisement and a statement of policy, not cryptographic proof of behavior. A monitor can test whether the relay actually acts the way the document claims. A client can use the document as a starting signal, then observe failures and adapt.
Do not confuse advertised support with lived behavior
The main risk is overtrusting the document. A relay can list supported NIPs but implement only part of them, enforce undocumented limits or drift out of date. Clients need to treat NIP-11 as useful evidence, not a signed service-level agreement.
The second risk is user invisibility. If clients hide relay policy too aggressively, users cannot understand why a post fails, why search does not work, why a paid relay asks for admission or why an authenticated write is rejected. NIP-11 is most valuable when clients turn relay policy into plain, calm interface language.
Read NIP-11 in the wild
NIP-11 gives a relay a public information document. That turns a relay from a mysterious websocket into an inspectable service with software, contact, supported NIPs, payment, limitation and policy clues.
Use it before trusting a relay as infrastructure. A client can discover what the relay claims to support, but you still need operational judgment: uptime, moderation policy, retention, payments and whether the declared behavior matches the lived behavior.
What changes when you actually use it
For you, NIP-11: Relay Information Document is felt when a relay accepts, rejects, indexes, hides, charges for or returns events. Relays are not passive pipes. They make policy and infrastructure choices that shape what a client can show. The source terms draft, relay, Accept, Access-Control-Allow-Methods, name, pubkey matter because they are the narrow places where a product can distinguish a relay decision from a network failure.
What changes for builders and operators
For builders and operators, NIP-11: Relay Information Document is observability. Log what the relay accepted, rejected, counted, authenticated or refused. Then show enough of that to users so they can repair configuration instead of assuming Nostr is empty or broken.
What the official file makes concrete
The official file is organized around Name, Description, Banner, Icon, Pubkey, Self, Contact, Supported NIPs. Inspect draft, relay, Accept, Access-Control-Allow-Methods, name, pubkey, contact, NIP because these are the pieces most likely to surface as product behavior. Read it beside NIP-17, NIP-01, NIP-09, NIP-13, NIP-42 before treating it as isolated.
NIP-11: Relay Information Document belongs to infrastructure, not scenery. Acceptance, indexing, authentication, retention, payment and filtering all shape what you actually see.
Where it breaks
The failure mode in NIP-11: Relay Information Document is blaming the network for one server's policy. A relay may reject an event for payment, spam, size, auth, retention or software reasons. If the client collapses those cases into one empty state, the user loses the ability to act.
Where this appears outside the markdown
In the ecosystem, NIP-11: Relay Information Document lives where users rarely look and operators spend real money: websocket services, relay policies, indexes, rate limits, authentication, monitoring and retention. A good hub page has to make that infrastructure readable because relay behavior decides whether Nostr feels alive, empty, expensive or hostile.
The nearby-standard trap
The nearby-standard trap in NIP-11: Relay Information Document is treating all relay standards as one reliability story. Discovery, authentication, information documents, search, counts, monitoring and management each expose a different slice of relay behavior. Read NIP-17, NIP-01, NIP-09, NIP-13, NIP-42 before calling a relay 'good' or 'broken'.
Language that keeps the feature honest
Good product copy for NIP-11: Relay Information Document names the relay decision. It says whether access, payment, indexing, search, storage, rate limit, auth or policy shaped the result. That language gives you something to fix instead of making the network feel mystical.
What this page does not promise
NIP-11: Relay Information Document does not make every relay equal. A relay can be public, paid, local, archival, search-oriented, authenticated, heavily moderated or almost disposable. The standard gives clients and operators a way to communicate one part of that behavior. It does not replace uptime checks, policy reading, payment terms, retention expectations or the practical question of whether your own events can be found later.
Read it as a field test
Start NIP-11: Relay Information Document with the server behavior you can observe: accept, reject, count, search, authenticate, limit, store, delete or report. Then connect it to draft, relay, Accept, Access-Control-Allow-Methods, name, pubkey. A relay NIP becomes readable when it explains what a relay can honestly promise and what still depends on policy, money and operations.
Where the standard earns trust
The source links give you places to test the interpretation in public: nostr-rs-relay, nostr-rs-relay config.toml, rust-nostr NIP-11 struct, NIP-43 Relay Access Metadata and Requests. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-11 source is the anchor for exact wording, and NIP-11 commit history shows how that wording moved over time. The strongest secondary clues here are nostr-rs-relay, nostr-rs-relay config.toml, rust-nostr NIP-11 struct. Treat this evidence chain as part of the article, not as footnotes. A NIP page becomes useful when you can move from claim to source to working behavior without guessing.
Keep the chain visible for NIP-11: Relay Information Document: first the human promise, then draft, relay, Accept, Access-Control-Allow-Methods, name, pubkey, then the implementation record, then the real-world failure case. That order keeps NIP-11 useful without turning it into marketing copy or protocol trivia.
Three questions to carry forward
- What exact relay behavior is being described: discovery, auth, search, count, information, payment, moderation or management?
- Can you see whether a failure came from policy, payment, indexing, rate limit, auth or downtime?
- Does the relay expose enough public information for you to decide whether it belongs in your own relay set?
What to verify before you rely on it
- Find
draft,relay,Accept,Access-Control-Allow-Methods,namein the official file and check where the UI exposes the same concept. - Read NIP-17, NIP-01, NIP-09, NIP-13, NIP-42 as context before treating NIP-11 as a complete product story.
- Open at least one implementation, mirror, pull request or library source from the source links before trusting that the idea is mature.
- Test the unhappy path: missing relays, stale metadata, invalid signatures, blocked events, expired state, revoked permissions or unavailable media.
- Write the user-facing copy in plain language. If a standard changes authority, privacy, money, moderation or recovery, say that before the click.
Direct sources
Use these sources for NIP-11: Relay Information Document in that order: Official NIP-11 source for the current wording; NIP-11 commit history for the change record; nostr-rs-relay, nostr-rs-relay config.toml, rust-nostr NIP-11 struct for public context. The article gives you the consequence in plain language, but the source trail is where exact fields, status notes, unresolved debates and implementation proof stay checkable.
