NIP-86: Relay Management API
Relay operators need tools that are not feed clients
Running a relay is not only accepting websocket messages. Operators have to ban abusive pubkeys, approve events, list moderation queues, change relay descriptions, manage allowed event kinds and hand admin access to other people. Before NIP-86, each relay could invent its own private control panel.
NIP-86 standardizes the management surface as a JSON-RPC-like HTTP request sent to the same URI as the relay websocket. That keeps it near the relay without mixing it into the normal client-to-relay event flow.
The standard matters most for operator tools. A command-line tool, admin dashboard or mobile relay-management view can speak one API across multiple compatible relays.
Management methods, not social protocol messages
A NIP-86 request uses Content-Type: application/nostr+json+rpc and carries a JSON object with method and params. Responses return either result or error. The method list includes pubkey bans and allowlists, event moderation, relay name, description and icon changes, allowed kinds, blocked IP addresses and admin management.
The February 2026 update added explicit unban and unallow methods, which matters operationally. A management API that only blocks but cannot reverse cleanly becomes dangerous fast.
NIP-86 does not define who is allowed to call these methods. In practice, implementations needs to pair it with NIP-98 HTTP Auth or stronger server-side access control.
Relay management entered the NIP set late
fiatjaf added NIP-86 in November 2024 through PR #1325. hodlbod later added unallowpubkey and unbanpubkey in February 2026. Compared with early feed, identity and relay metadata NIPs, this is a later operator-infrastructure layer.
External implementation traces show the direction. The crusher86 project is a command-line tool for managing relays through NIP-86. Grain documents its NIP-86 endpoint as gated by NIP-98. Amethyst release notes in 2026 mention relay management UI and client implementation work.
That mix is exactly what NIP-86 is for: not users browsing Nostr, but operators controlling the infrastructure under it.
Admin UX needs to make destructive actions hard to do casually
A responsible NIP-86 UI needs to show current relay identity, pending queues, ban reasons, allowed kinds, IP blocks and admin permissions before offering changes. Ban and admin methods needs to require confirmation and record the reason field where available.
Authentication is not optional in real deployments. Because the NIP describes management power, not just public metadata, a relay needs to reject unauthenticated or stale requests and log administrative actions.
Good tools can make small relays more viable: one operator can moderate without building a whole bespoke dashboard.
A management API is a high-value target
A compromised NIP-86 endpoint can change a relay's policy, metadata or admin set. Treat it as production administration, not as a convenience endpoint.
There is also a governance risk. If a relay hides why bans happen, standardized tooling can make opaque moderation easier. The API needs to support reasons, audit trails and operator accountability.
Read NIP-86 in the wild
NIP-86 is a relay management API. It belongs to operators, paid relays and community infrastructure that need administrative control beyond a terminal session.
Admin power needs restraint. Deleting events, banning users or changing policy must come with authentication, logs, limited permissions and clear operator intent.
What changes when you actually use it
For you, NIP-86: Relay Management API 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, Content-Type, supportedmethods, ["<method-name>", "<method-name>", ...], banpubkey, true 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-86: Relay Management API 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 Authorization. Inspect draft, Content-Type, supportedmethods, ["<method-name>", "<method-name>", ...], banpubkey, true, unbanpubkey, listbannedpubkeys because these are the pieces most likely to surface as product behavior. Read it beside NIP-98 before treating it as isolated.
NIP-86: Relay Management API 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-86: Relay Management API 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-86: Relay Management API 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-86: Relay Management API 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-98 before calling a relay 'good' or 'broken'.
Language that keeps the feature honest
Good product copy for NIP-86: Relay Management API 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-86: Relay Management API 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-86: Relay Management API with the server behavior you can observe: accept, reject, count, search, authenticate, limit, store, delete or report. Then connect it to draft, Content-Type, supportedmethods, ["<method-name>", "<method-name>", ...], banpubkey, true. 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: crusher86, Grain API docs, Amethyst release note. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-86 source is the anchor for exact wording, and NIP-86 commit history shows how that wording moved over time. The strongest secondary clues here are crusher86, Grain API docs, Amethyst release note. 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-86: Relay Management API: first the human promise, then draft, Content-Type, supportedmethods, ["<method-name>", "<method-name>", ...], banpubkey, true, then the implementation record, then the real-world failure case. That order keeps NIP-86 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,Content-Type,supportedmethods,["<method-name>", "<method-name>", ...],banpubkeyin the official file and check where the UI exposes the same concept. - Read NIP-98 as context before treating NIP-86 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-86: Relay Management API in that order: Official NIP-86 source for the current wording; NIP-86 commit history for the change record; crusher86, Grain API docs, Amethyst release note 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.
