NIP-43: Relay Access Metadata and Requests
Private relays need visible access rules
NIP-43 sits next to NIP-42. NIP-42 lets a client prove key control to a relay. NIP-43 asks the next product question: how does the relay tell the world who belongs, how does a new user ask to join, and how can a user ask to leave?
That matters because Nostr relays are not all public firehoses. Some are club relays, paid relays, community relays, private storage relays or service-specific relays. Without a standard access surface, every relay invents its own membership page, invite code flow and error language. Clients cannot build a common UX around that.
NIP-43 is not a full governance system. It does not say how a community decides membership. It gives relays and clients a few signed event shapes so the access story can be visible inside the protocol instead of hidden behind a website.
Lists, join claims and relay-signed access events
The relay may publish a kind 13534 membership list signed by the pubkey in the relay's NIP-11 self field. The list includes one member tag per pubkey and must include the NIP-70 protected-events - tag. The source warns that this list is not exhaustive or authoritative by itself; clients need to also consult a user's kind 10010 relay-list-style event.
Add and remove events use kinds 8000 and 8001. Both are relay-signed and point at the member pubkey with a p tag. A user can send a join request as kind 28934 with a claim tag containing an invite code. The relay answers through the ordinary OK path, using restricted: for expired or invalid invite claims.
NIP-43 also defines invite request and leave request shapes. Kind 28935 lets a relay issue a claim string on the fly, and kind 28936 lets a user request that access be revoked. These event kinds are not glamorous, but they turn private relay access into something a client can reason about.
A young relay-access NIP
NIP-43 is recent compared with the foundational NIPs. The visible history begins with hodlbod's October 2025 addition of relay access requests. Later repository-wide relay-tag cleanup touched the file in December 2025, followed by markdown code-block cleanup in June 2026.
The short history is a clue. This standard needs to be treated as a working relay-access proposal rather than mature social infrastructure. It is useful because it names the obvious objects: membership list, add, remove, join, invite and leave. The precise product conventions around those objects are still young.
That is why it must not be oversold. NIP-43 is important for private-relay UX, but adoption will be decided by real relays, clients and communities that need invite codes and membership surfaces.
This is where relay UX becomes membership UX
A relay implementing NIP-43 needs more than event emission. It needs an access database, invite-code issuance, expiry rules, add and remove publication, and a clear relationship between the relay's NIP-11 self pubkey and the signed membership events. If the relay cannot prove that those events come from the relay operator identity, clients have little reason to trust them.
A client implementing NIP-43 needs to be careful with certainty. The official source says the membership list must not be considered exhaustive or authoritative. A good UI can say that a relay advertises a membership signal, not that it has proved every possible access state.
The product payoff is straightforward: a user opens a relay page, sees whether membership exists, submits an invite claim, gets an immediate accepted, duplicate, expired or invalid response, and then sees the relay update access state. That is ordinary app UX, but it is hard to build across independent relays without a common event vocabulary.
The list can become a surveillance surface
Membership lists are convenient, but they also reveal social structure. A relay that publishes every member of a private community may expose more than users expect. The standard gives the shape; relay operators still need privacy and consent choices.
There is also a trust problem around invite claims. A leaked claim string, a long-lived invite or a badly scoped invite can turn a private relay into a public one by accident. Clients need to display claim failures plainly and relays needs to keep invite issuance narrow.
Read NIP-43 in the wild
NIP-43 adds access metadata and request events around relay permissions. It belongs to the practical world of paid relays, private relays, community relays and services that need clearer admission rules.
The product must explain the gate. If a relay denies access, charges for it or asks for proof, the user needs a reason, a price, a path to fix it and a way to avoid signing vague requests.
What changes when you actually use it
For you, NIP-43: Relay Access Metadata and Requests 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 kind 13534, kind 10010, kind 8000, kind 8001, kind 28934, kind 28935 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-43: Relay Access Metadata and Requests 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 Membership Lists, Add User, Remove User, Join Request, Invite Request, Leave Request, Implementation. Inspect kind 13534, kind 10010, kind 8000, kind 8001, kind 28934, kind 28935, kind 28936, draft because these are the pieces most likely to surface as product behavior.
NIP-43: Relay Access Metadata and Requests 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-43: Relay Access Metadata and Requests 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-43: Relay Access Metadata and Requests 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-43: Relay Access Metadata and Requests 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-01 and the adjacent source links before calling a relay 'good' or 'broken'.
Language that keeps the feature honest
Good product copy for NIP-43: Relay Access Metadata and Requests 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-43: Relay Access Metadata and Requests 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-43: Relay Access Metadata and Requests with the server behavior you can observe: accept, reject, count, search, authenticate, limit, store, delete or report. Then connect it to kind 13534, kind 10010, kind 8000, kind 8001, kind 28934, kind 28935. 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: NIP-11 Relay Information, NIP-42 Relay Authentication, NIP-70 Protected Events, Relay type nomenclature discussion. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-43 source is the anchor for exact wording, and NIP-43 commit history shows how that wording moved over time. The strongest secondary clues here are NIP-11 Relay Information, NIP-42 Relay Authentication, NIP-70 Protected Events. 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-43: Relay Access Metadata and Requests: first the human promise, then kind 13534, kind 10010, kind 8000, kind 8001, kind 28934, kind 28935, then the implementation record, then the real-world failure case. That order keeps NIP-43 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
kind 13534,kind 10010,kind 8000,kind 8001,kind 28934in the official file and check where the UI exposes the same concept. - Read NIP-01 and the adjacent source links as context before treating NIP-43 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-43: Relay Access Metadata and Requests in that order: Official NIP-43 source for the current wording; NIP-43 commit history for the change record; NIP-11 Relay Information, NIP-42 Relay Authentication, NIP-70 Protected Events 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.
