NIP-42: When a Relay Asks You to Prove the Key
Relay authentication lets an endpoint ask for proof without owning your account. The hard part is not the cryptography. The hard part is making the moment legible enough that you know what you are proving and why.
Relay auth is not platform login
Platform login usually means one company creates the account, stores the password or session, controls the database and decides what identity means inside its walls. Nostr starts somewhere else. Your public key is the identity. Your private key or signer proves control. A relay can ask for proof before it accepts or serves certain events, but the relay does not need to own your account to do that. NIP-42 is the standard handshake for that proof.
This distinction is not semantic. If you treat relay auth like platform login, you will expect the relay to be your account home. If you treat it like a signed challenge, you understand the boundary. You are telling one relay, for one challenge, that your key is present. You are not handing over a password. You are not transferring account custody. You are not agreeing that the relay defines your identity everywhere.
That makes NIP-42 one of the practical standards that keeps Nostr usable without making every relay fully open to everyone all the time. A relay can be public for reads and restricted for writes. It can be free for browsing and paid for publishing. It can admit only community members. It can require auth before accepting high-risk event kinds. It can challenge admin tools before allowing management actions. The key remains portable; the room still has a door.
The user experience needs to preserve that architecture. The client should show which relay asks for auth. The signer should show what kind of event is being signed. The relay should publish why auth is required through NIP-11 metadata or clear policy. If any part hides the context, the user is nudged toward blind approval. Blind approval is how good cryptography becomes bad product.
Read NIP-42 as a boundary standard. It tells you how a relay can ask, “prove the key for this challenge,” without inventing a private login system. The boundary can be healthy, but only when you can see it.
The auth challenge flow
The NIP-42 flow is compact. A relay sends an AUTH message containing a challenge. The client responds with an authentication event, commonly using kind 22242, signed by the user's key. That event includes tags that bind it to the relay and the challenge. The relay verifies the signature and decides what to allow. The private key never leaves the signer when the flow is done correctly.
The tags matter because they keep the proof scoped. A useful auth event is not a general “yes, I am this key forever.” It is tied to a relay URL and a challenge value. That prevents the signed proof from being reused casually elsewhere. If a client asks you to sign an auth event and does not show the relay or challenge context, the user interface is stripping away the part that makes the proof understandable.
The relay may ask for auth before accepting an event, before opening a subscription, before allowing protected reads, before letting a client use a paid service, or before administrative actions. The exact policy is the relay's choice. NIP-42 gives the language for the challenge and response. It does not dictate the business model or moderation policy.
The standard also gives you two machine-readable failure words that matter in real software. auth-required means the relay still needs the client to perform the auth flow for the requested operation. restricted means the client may already be authenticated, but the authenticated key is still not allowed or has exceeded the authorization the relay grants. Those two states should never be collapsed into a generic error. One says: prove the key first. The other says: you proved a key, but this key still does not get that action.
The signed auth event is ephemeral. It is not supposed to become a normal published event, and relays should not broadcast kind 22242 to other clients. It should also be fresh. The NIP recommends that relays check whether created_at is close to the current time, roughly within minutes rather than days. That small freshness rule matters because stale signed challenges are exactly the kind of artifact a sloppy client could leak, cache or replay in a confusing debug session.
A relay can send a challenge immediately when you connect, or only when an operation hits a protected area. That difference changes how the interface should feel. Connection-time auth can be calm and preparatory: this relay wants proof before you use it. Operation-time auth should be contextual: you tried to write, subscribe, query or manage something, and this specific action now needs proof. A client that stores challenges per relay and responds only when needed can make the flow feel almost invisible while still keeping the decision visible.
In a good flow, the user sees a calm sequence: the relay requires proof, the client explains why, the signer displays the auth event, the user approves or rejects, and the relay either unlocks the intended operation or returns a clear reason. In a bad flow, publishing just fails, or a signer pops up with a confusing blob, or the client asks for broad permission without saying which relay is at the door.
That is why the standard belongs in UX conversations. The cryptographic flow is short. The human flow is where trust is built or lost.
What the signed event proves
The auth event proves control of a key for a relay challenge. It does not prove that the relay is good, that the policy is fair, that the client is honest, that the signer is safe, that payment terms are reasonable or that the user understood the prompt. That sounds obvious, but it prevents a lot of sloppy thinking. Authentication is evidence of key control. Trust is a larger decision.
For the relay, the proof can be enough to enforce rules. If a paid account is tied to a public key, the relay can ask for proof that the key is present before allowing writes. If a private room has a membership list, the relay can challenge keys before serving content. If an admin tool wants to call a management API, the relay can require proof from an authorized key. The relay gets a standard way to move from anonymous connection to known key.
NIP-42 also allows clients to send auth events from multiple pubkeys on the same connection, and a relay can treat those pubkeys as authenticated accordingly. That is powerful, but it raises a product question most interfaces still handle poorly: which identity is acting right now? If your client manages a personal key, an operator key and a test key, the auth prompt should make the selected key obvious. The worst possible outcome is a successful signature from the wrong identity. Technically it worked. Operationally it created the wrong access trail.
For the user, the proof is also a disclosure. You are telling the relay which public key is asking. That may be exactly what you want. It may also be more identity exposure than you expected if you were only browsing. Auth should therefore be understood as both access and signal. When a relay asks for auth, it is asking you to be visible to that relay as a specific key.
The proof is also connection-bound in practice. Once the relay accepts the signed event, the authenticated session is useful for the duration of that connection. It is not a permanent passport stored in the protocol forever. A client reconnecting later may need a fresh challenge. That is good. It keeps relay access from turning into a vague background grant that survives every context change. Long-lived product sessions can still exist around payment or membership, but the NIP-42 proof itself should stay small and current.
For clients and signers, the signed event is a design responsibility. A signer should not show auth events as indistinguishable from normal posts, zap receipts or encryption actions. A client should not batch auth approvals into vague “connect” buttons without context. The user needs to know that this signature is a relay challenge, not a public note, not a payment, and not a blank check.
When you approve NIP-42, approve the smallest useful thing: this relay, this challenge, this feature. If the prompt asks for more than that, pause.
Why relays ask
Relays ask for authentication because openness has costs. A fully open public relay can be hammered by spam, bots, abusive clients, huge queries and people who never pay the server bill. Authentication gives the operator a way to attach behavior to keys. It can reduce anonymous abuse, connect usage to payment, support private communities and make rate limits less crude.
Paid access is the easiest case. If you pay for a relay, the relay needs a way to know that your key is allowed to write or read. A password would drag the relay back toward platform accounts. A signed challenge keeps the relationship Nostr-native. The relay can recognize the key without holding the key's secret. The user keeps the same identity across clients.
Moderation is another case. A relay may allow everyone to read but require auth before writing. That does not stop all abuse, but it raises the cost of throwaway spam. A web-of-trust relay may combine auth with social-graph decisions. A group relay may challenge members before accepting group events. A local venue relay may allow event attendees or staff while rejecting random outside writes.
Protected-event flows make the same point from another angle. NIP-70 describes protected events that relays should only accept after the client performs NIP-42 auth and the authenticated client key matches the event pubkey. The aim is not to make the content secret; it is to stop third parties from reposting or pushing certain protected events on behalf of someone else without proving the publishing key. Here authentication is not a membership trick. It is a guardrail around who may present a sensitive event to the relay.
Relay access metadata adds another layer. NIP-43 sketches how relays can advertise membership lists and how clients can request admission. That kind of access model still needs a way to prove which key is asking. NIP-42 is the proof handshake; access metadata is the surrounding invitation, admission and policy language. If you separate those roles, the architecture becomes easier to reason about. Auth answers which key is here. Policy answers what this key may do.
Operational tools need auth too. NIP-86 relay management APIs are not for anonymous clients. If a relay exposes admin-like functions, it needs a way to know which key is authorized. NIP-42 can be part of that boundary, while NIP-86 defines the management actions. The combination lets operators build tooling without inventing a separate login kingdom.
Finally, relays ask because some traffic is sensitive. Wallet relays, private rooms and local operator systems need more care than a public meme relay. Auth is not the whole security model, but it is often the first gate.
Paid and filtered relays
nostr.wine is a useful example because its relay metadata openly advertises payment-required behavior and supported NIPs including NIP-42. That tells you the relay is not pretending to be an unlimited free endpoint. It is a service with an admission model. Whether you decide to use it or not, the combination of NIP-11 and NIP-42 makes the boundary visible: payment terms are part of the room, and auth can help the relay know who is entitled to use it.
filter.nostr.wine makes the point sharper. Its metadata presents a filter or broadcast relay for nostr.wine users, with auth-required and payment-required behavior. That means it should not be read as a generic public relay. It is closer to a service layer: users prove themselves, the relay applies policy, and the product value comes from filtering, broadcasting or access control.
This is where NIP-42 protects product clarity. A paid relay without standard auth has to invent a custom session model. A paid relay with invisible auth feels mysterious. A paid relay with clear metadata and a clear challenge can explain the moment: you are proving this key because this relay restricts this operation. That is the difference between an infrastructure rule and a confusing failure.
Paid relays also force better language around reliability. Payment does not guarantee permanence, fairness or safety. It only changes the relationship. You may get lower spam, clearer service expectations and a budget for operations. You may also get a relay that changes terms, closes access or fails like any service. Auth proves the key; it does not prove the business.
A paid relay should therefore expose three layers separately. NIP-11 should say the service is paid or restricted. The payment page should explain what you are buying, for which key and for how long. The NIP-42 flow should prove the key when the relay needs to check access. If those layers blur together, users cannot tell whether they are buying storage, write permission, inbox filtering, search, broadcasting, private access or simply admission to a lower-spam room.
Filtered relays need the same honesty. A relay that claims to protect you from spam, duplicate traffic or low-quality writes is making policy choices. Auth can help tie those choices to paid keys or known members, but the user still deserves to know what is filtered and what is merely unavailable. If your client silently treats every filtered relay as a normal public endpoint, you may miss posts and never know whether the absence came from policy, payment, downtime or query limits.
When you evaluate a paid or filtered relay, inspect NIP-11 first, then the auth flow, then the payment terms, then the actual behavior. If all four line up, the service is easier to understand. If any one is hidden, slow down.
Private, local and wallet rooms
NIP-42 becomes especially important outside the public timeline. A private relay for a team, project, family, club or operator group should not accept every random write. A local relay at a conference or venue may want attendees, staff or verified members to write. A wallet relay should know which key is participating in a sensitive NWC flow. These rooms are not less Nostr because they have doors. They are Nostr rooms with explicit boundaries.
A local relay can use auth to preserve local context. Imagine a club where members publish event RSVPs, venue offers, reputation notes, menu updates or staff announcements. The relay may be public enough for discovery but restricted enough to avoid spam. NIP-42 lets the relay challenge keys without making members create another platform account. The public key travels; the local room enforces its own admission.
Wallet relays need even clearer UX. Nostr Wallet Connect uses Nostr-style communication to let apps talk to wallets through relays. When a wallet-adjacent relay asks for proof, the user should understand that the context may involve payment permissions, invoice creation, lookup, spending limits or service pairing. A blind auth prompt near a wallet flow is not acceptable product design.
NWC also reminds you that relay auth and wallet permission are not the same permission. A wallet relay can require NIP-42 proof before serving a connection, while the wallet service separately decides which NIP-47 methods, budgets and commands are allowed. One layer proves the Nostr key to the relay. Another layer governs money movement. A good product keeps both visible because you may be comfortable proving identity to a relay while still refusing a spend permission or a recurring budget.
Private rooms also create privacy questions. Auth exposes your public key to the relay. If the room is sensitive, that exposure may be intended. If it is not, the client should help you understand the trade. A private relay can hide content from the public, but it cannot make your relationship with the relay invisible to the relay itself. The operator sees the authenticated key.
The healthy rule is simple: private, local and wallet relays should make their boundaries legible before asking for auth. You should know which room you are entering, who operates it, and what the proof unlocks.
Auth is a privacy signal
Authentication is useful because it identifies a key to a relay. That is also why it affects privacy. If you authenticate to many relays with the same public key, those relays know that key connected and asked for something. In public social use, that may be fine. In sensitive browsing, local membership or wallet contexts, it deserves thought.
Nostr does not hide your public identity by default. Public notes, follows, relay lists and profile metadata are already public. Still, auth adds a moment of active proof. A relay that might otherwise see a connection now receives a signed event proving key control. That can be necessary for access. It should not be treated as invisible.
Timing matters too. A relay that sees when you authenticate, which subscription follows, which event write gets retried and which client version is connected can infer behavior even if the content is encrypted or filtered. That does not mean you should avoid auth. It means you should not confuse encryption, authentication and anonymity. Each solves a different problem. NIP-42 helps a relay know the key. It does not hide the fact that the key showed up.
If you maintain separate keys for public posting, private groups, work, venues or testing, auth prompts are where that separation either holds or collapses. A careless client can authenticate the wrong key to the wrong room. A careful client can make key context visible before the signer opens. People often think privacy is only about cryptography, but in daily Nostr use it is often about choosing the right key at the right door.
Clients can reduce confusion by labeling auth prompts. “This relay asks you to prove your key before writing” is very different from “sign event.” “This paid relay needs auth to check access” is different from “connect.” “This wallet relay asks for proof before a NWC action” is different from “log in.” Language matters because people approve what they understand.
Signers also have a role. A signer should distinguish auth events from posts, deletions, encrypted-message actions, wallet events and profile updates. It should display the relay URL and challenge. It should avoid remembered permissions that are too broad. Background signing can be convenient, but auth should not become invisible simply because a user once clicked allow.
The practical privacy habit is to ask: do I want this relay to know this key is here for this reason? If yes, approve. If no, use another route or decline. That is not paranoia. It is agency.
Signers make auth human
A NIP-42 flow is only as understandable as the client and signer make it. If your private key is pasted into a random app, the app can sign auth events without giving you a meaningful decision point. If you use a dedicated signer, the signer can show the request, identify the relay, display the event kind and let you decide. That is why relay auth belongs next to signer literacy.
Desktop browser signers, mobile signers, remote signers and bunker patterns each change the moment. A NIP-07 extension may show a relay auth event inside the browser. An Android signer such as Amber may show the request from a native client. A NIP-46 bunker may receive the request through relays and ask you to approve on another device. The underlying proof can be similar while the human experience changes a lot.
The best signer behavior is calm and specific. Show that it is a relay authentication event. Show the relay URL. Show the challenge or enough of it to identify the request. Show the app asking. Show whether the permission will be remembered. Let the user reject without breaking the whole app. Keep a history so suspicious requests can be reviewed later.
A signer should also treat auth as a different class from generic signing. The event kind, the relay tag and the challenge tag are not decorative metadata; they are the whole reason the prompt is safe to understand. A signer that lets you inspect those fields gives you a way to catch strange requests. A signer that reduces everything to "allow app to sign" asks you to trust the app rather than the actual request.
The best clients do not force signers to carry all of that weight. They explain the moment before the signer modal appears, and then the signer confirms the exact event. That two-step design feels slower only the first time. After that, it becomes muscle memory: client tells you the reason, signer tells you the proof, you approve or reject with a clear head.
Remembered permissions deserve extra care. It may be reasonable to remember auth for a trusted paid relay or a local app you use every day. It may be dangerous to remember broad signing for an unknown web app. The problem is not convenience. The problem is convenience without a narrow scope.
If Nostr wants normal people to use paid relays, private rooms and wallet flows, signers have to make NIP-42 feel like a clear door, not like an alarming cryptographic interruption.
What clients should show
A good client should prepare the user before the signer opens. If a relay requires auth, the client should say which relay and why. If the reason comes from NIP-11 metadata, show it. If the relay is paid, show payment state. If it is private, show membership context. If it is a wallet relay, show the wallet action. Do not make the signer do all the explanatory work.
The client should also surface failures. If the relay returns an auth-required message, do not show “publish failed” and stop. Show that the relay asked for proof. If the auth event is rejected, show whether the challenge expired, the signature failed, the key lacks permission, payment is missing or the relay returned a policy reason. Specific failure messages build trust.
Clients should avoid auth fatigue. If every tiny action triggers an identical prompt, users will click through. Batch where safe, remember narrowly where appropriate and explain when background auth is active. But never hide auth in a way that makes the user forget which relays know the key. The goal is fewer prompts with more meaning, not fewer decisions with less agency.
After successful auth, the client should retry intentionally. If a write failed with auth-required, authenticate and then retry that write once. If a subscription was closed with auth-required, authenticate and reopen that subscription. If the relay returns restricted after auth, stop retrying and show the policy problem. Endless hidden retries make users think the network is broken. A single clear retry teaches them what happened.
Clients should also expose relay categories in settings. A public relay, paid relay, private relay, inbox relay, outbox relay, search relay, wallet relay and local relay should not all look like the same URL row. Auth prompts become easier to understand when the client already taught you what role each relay plays in your setup. That is especially important once NIP-65 relay lists, search relays and NWC relays live next to each other.
Clients should also respect different roles. A public relay that never asks for auth should not be treated as broken. A paid relay that always asks for auth should not be treated as hostile. A private relay that refuses unknown keys is doing its job. Good UX explains the category before judging it.
The interface should make Nostr's architecture feel natural: key stays with you, relay asks for proof, signer handles the signature, client explains the context, relay enforces its rule. When those pieces are visible, NIP-42 feels clean.
What operators should publish
If you run a relay that requires auth, publish that fact clearly. NIP-11 can advertise auth-required behavior, restricted writes, payment status, supported NIPs and policy links. Use those fields. Do not make clients discover your auth requirement only after users hit a wall. A relay with a door should have a sign.
Explain the reason in ordinary language. “Authentication is required for paid write access.” “Authentication is required to write to this community relay.” “Authentication is required for NWC traffic.” “Authentication is required for relay management.” Those sentences help clients and users frame the prompt. They also reduce support noise because people know the rule before failing.
Keep the challenge flow standard. Custom login pages and side channels may be necessary for payment or membership management, but the relay proof itself should stay NIP-42 where possible. The more relays invent private auth flows, the more clients and signers have to guess. Standards are boring because boring works.
Publish your challenge behavior if it affects users. If challenges expire quickly, say so. If auth is required only for writes, say so. If reads are public but writes are restricted, say so. If a successful key can still be restricted because it lacks payment, membership or admin rights, say so. Clear policy is not just documentation; it is part of the relay product.
Operators also need to be careful with URL identity. NIP-42 verification includes checking that the relay tag matches the relay URL, with normalization where appropriate. If your relay is reachable through several domains, redirects, vanity URLs or proxy paths, auth can become confusing. Pick canonical URLs, advertise them consistently through NIP-11 and client docs, and avoid making users sign for one address while their client is connected to another.
Operators should also avoid excessive auth. Do not challenge every read if the relay is meant to be public. Do not require proof when rate limits would be enough. Do not ask for auth without using it. Authentication creates identity exposure and user friction. Use it where the room needs a door, not as decoration.
Finally, monitor the human side. If users keep failing auth, the problem may be your metadata, client compatibility, signer UX, expired challenges or payment status. Relay auth is an operational surface, not a switch you flip once.
Failure patterns
NIP-42 failures have recognizable shapes. The relay may send a challenge and the client may ignore it. The client may ask the signer, but the signer may reject the event. The user may approve, but the challenge may have expired. The event may be signed by the wrong key. The relay may accept auth but still reject writes because payment or membership is missing. Each failure needs a different explanation.
Another common failure is relay mismatch. The auth event should bind the proof to the relay. If the client signs for the wrong URL, the relay should not accept it. That protects users from replay and confusion, but it can produce tricky bugs when clients normalize relay URLs inconsistently. Trailing slashes, schemes, redirects and aliases can matter. Good clients should be strict and clear.
Payment failures can look like auth failures. A paid relay may authenticate your key successfully and still refuse writes because the key is not paid up. The UI should separate those states. “You proved the key; payment is missing” is different from “auth failed.” Without that distinction, users blame signers, wallets, relays and clients at random.
Private relay failures can look like censorship. A relay may reject your write because you are not a member, not because Nostr is broken. A local relay may reject outside keys. A group relay may reject event kinds or unauthorized moderation actions. Again, the answer is not to hide policy. The answer is to name it.
Another failure comes from stale challenges. If your client stores an old challenge, disconnects, reconnects and then signs the old value, the relay should reject it. From your seat it can feel random: the signer approved, the event looks valid, but the relay still says no. The real problem is freshness. Good clients keep challenges per relay connection and discard them when the relay sends a new one or the connection resets.
A subtler failure comes from multi-key clients. If a client authenticates with one key and then tries to publish an event signed by another, the relay may reject the write depending on its policy. Sometimes that is exactly what you want, especially for protected events. Sometimes an operator wants one admin key to publish on behalf of project keys. The important part is not which policy wins everywhere. The important part is that the client and relay explain which key was authenticated and which key signed the event.
When debugging, collect the relay URL, NIP-11 metadata, auth challenge, signed event kind, public key used, client, signer, error message and payment or membership status. That sounds like a lot, but it turns a vague complaint into an answer.
Your auth routine
When a relay asks for auth, pause for two seconds. Which relay is asking? What feature triggered it? Is the relay public, paid, private, local, wallet-related or administrative? Does NIP-11 say auth is required? Does the prompt show a relay URL and challenge? Is the signer you trust handling the request? Those questions become fast with practice.
If the request comes from a paid relay, confirm that you actually intend to use that paid service. If it comes from a private community, confirm that the room is the one you meant to enter. If it comes from a wallet flow, confirm that the app and wallet relationship make sense. If it comes from a random page with no explanation, reject and inspect.
Use dedicated signers where possible. Do not paste your private key into random clients just to satisfy auth. A signer gives you a visible decision point and a history. If a client cannot work with your signer and asks for raw key custody, treat that as a separate trust decision, not as a minor setup inconvenience.
For a serious relay setup, keep a small note of which relays ask for auth and why. You do not need a spreadsheet for every experiment, but you should know your paid write relay, your inbox relay, your private group relay, your wallet relay and any admin relay. When something fails, that map saves time. When you leave a service, it tells you which permissions and payments to clean up.
Review remembered permissions. If you allowed auth for a relay months ago, check whether you still use that relay. Remove old permissions from signers and clients. Revoke or clean up paid relay access you no longer need. Auth hygiene is not complicated, but it does require occasional attention.
The goal is not fear. The goal is clean boundaries. NIP-42 is one of the tools that lets Nostr support real services without surrendering identity to those services. Use it like a keycard, not like a password you hand to the building.
Sources worth opening
Use these when you want to check the standard, relay metadata, paid-relay context and adjacent management/security work.
- NIP-42: authentication of clients to relays
- NIP-11: relay information document
- NIP-86: relay management API
- NIP-47: Nostr Wallet Connect
- nostr.wine paid relay
- filter.nostr.wine relay
- purplepag.es relay directory
- Alby NWC relay information endpoint
- NWClay relay information endpoint
- Nostr.how relay guide
- Nostr Design relay guidance
- strfry relay software
