NIP-42: Authentication of clients to relays
Public relays are open; useful relays often need a door
Nostr's base protocol lets a client connect to a relay and ask for events or publish events. That openness is part of the charm. It is also not enough for every relay. A paid relay needs to know whether the connected user has paid. A private group relay needs to know whether you is a member. A relay that serves older encrypted direct messages may want to restrict those reads to the participants. A relay with a write policy may allow an authenticated user to publish events that are not signed by the same key used for the access account.
NIP-42 supplies the missing handshake. The relay sends an AUTH challenge. The client signs a short ephemeral event with kind 22242, including the relay URL and the challenge. The relay verifies the signature, checks that the challenge and relay tag match, and treats the pubkey as authenticated for that connection.
That sounds like login, but it is deliberately narrower than an account system. The signed event is not meant to be published or queried. The relay is not asking for a password. It is asking the client to prove control of a Nostr key inside the current websocket session.
AUTH, kind 22242 and machine-readable refusal reasons
The visible protocol change is small: a relay may send ["AUTH", "challenge"]; a client may answer with ["AUTH", signed_event]. The signed event must use kind 22242 and include a relay tag plus a challenge tag. Relays must not broadcast kind 22242 events to normal subscribers.
NIP-42 also standardizes how a relay says no. For rejected subscriptions, the relay can close the subscription with a CLOSED message using auth-required: when authentication has not happened, or restricted: when authentication happened but the key is not allowed. For rejected writes, the relay can use the same prefixes inside OK responses.
The multi-user change matters. A client may send a sequence of AUTH messages from multiple pubkeys, and relays must treat all those pubkeys as authenticated. That fits real software where a client may manage multiple accounts, app keys or delegated workflows in one connection.
A standard simplified by relay reality
The visible history starts in January 2023, when fiatjaf drastically simplified an earlier authentication proposal and moved it toward the challenge-response shape used today. In December 2023, NIP-42 was tied into the newer CLOSED message and machine-readable relay refusal prefixes. That change made it more useful for real clients because the user can see why a read or write failed instead of staring at a silent relay.
In September 2025, Vitor Pamplona's PR #1881 allowed multi-user AUTH. In December 2025, relay tags were updated across several files. The story is therefore not one big cryptographic invention; it is a relay operations NIP being adjusted as private, paid and policy-heavy relays became more normal.
The most practical lesson is that NIP-42 is not about identity branding. It is about connection-level authorization. A relay can still make bad policy decisions, but clients at least have a shared way to prove key control and interpret rejections.
The hard part is not signing; it is timing and user state
Most Nostr libraries can already sign an event. The details that break products are the session details: storing the latest challenge per relay, retrying a request after an auth-required: response, handling several authenticated pubkeys, and showing a human explanation when the relay says restricted:.
Rust-nostr advertises support for NIP-42, and relay implementations such as nostr-rs-relay have had practical issue threads around AUTH acknowledgement and whitelisting behavior. Those discussions matter because a relay can technically authenticate a client while still leaving the UI confused if it does not respond with the expected OK message.
A serious client needs to test three flows: read requires AUTH, write requires AUTH and authenticated key is still not authorized. Those are different user states. Blending them into one generic error makes private relay UX feel broken.
Authentication can become hidden centralization
NIP-42 gives relays a clean door. It does not say who deserves a key, how payment is verified, how membership is granted or whether a relay's policy is fair. That is where product and governance questions return.
There is also a privacy tradeoff. Authentication links a pubkey to a relay connection and the requested resource. For some relays that is exactly the point. For sensitive reading patterns, clients need to avoid authenticating casually and needs to explain when a relay is asking for proof of identity.
Read NIP-42 in the wild
NIP-42 gives relays a way to authenticate clients. A relay can challenge a client, and the client can prove control of a Nostr key without sending a password.
This is where access control becomes legible. The client needs to show which relay is asking, what key is signing and why the challenge exists. Otherwise auth feels like another mysterious popup.
What changes when you actually use it
For you, NIP-42: Authentication of clients to relays 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 4, kind 22242, draft, relay, kind: 4, AUTH 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-42: Authentication of clients to relays 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 Motivation, Definitions, New client-relay protocol messages, Canonical authentication event, OK and CLOSED machine-readable prefixes, Protocol flow, auth-required in response to a REQ message, auth-required in response to an EVENT message. Inspect kind 4, kind 22242, draft, relay, kind: 4, AUTH, OK, EVENT because these are the pieces most likely to surface as product behavior.
NIP-42: Authentication of clients to relays 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-42: Authentication of clients to relays 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-42: Authentication of clients to relays 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-42: Authentication of clients to relays 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-42: Authentication of clients to relays 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-42: Authentication of clients to relays 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-42: Authentication of clients to relays with the server behavior you can observe: accept, reject, count, search, authenticate, limit, store, delete or report. Then connect it to kind 4, kind 22242, draft, relay, kind: 4, AUTH. 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, rust-nostr supported NIPs, nostr-rs-relay AUTH issue, nostr-rs-relay whitelist issue. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-42 source is the anchor for exact wording, and NIP-42 commit history shows how that wording moved over time. The strongest secondary clues here are NIP-11 Relay Information, rust-nostr supported NIPs, nostr-rs-relay AUTH issue. 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-42: Authentication of clients to relays: first the human promise, then kind 4, kind 22242, draft, relay, kind: 4, AUTH, then the implementation record, then the real-world failure case. That order keeps NIP-42 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 4,kind 22242,draft,relay,kind: 4in 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-42 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-42: Authentication of clients to relays in that order: Official NIP-42 source for the current wording; NIP-42 commit history for the change record; NIP-11 Relay Information, rust-nostr supported NIPs, nostr-rs-relay AUTH issue 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.
