AUTH Is Not Identity: What NIP-42 Relay Challenges Actually Prove

Nostr’s public gossip story is easy to over-read. Events are signed. Relays gossip. Anyone can open a WebSocket. From that people infer an open mesh with no gates — then hit auth-required on a DM REQ, or a write OK that refuses until they sign something.

That refusal is not a betrayal of the protocol. It is NIP-42: authentication of clients to relays by signing an ephemeral event. Events remain signed objects anyone can verify. Individual sockets may still demand proof that this connection holds a private key before restricted reads or writes.

Thesis, stated once: NIP-42 AUTH proves possession of a private key for a connection-scoped challenge bound to a relay URL. It does not prove legal identity, payment status, moral standing, or that the wider network endorsed you. Confusing “signed for this socket” with “who you are in the world” is how gated relays get misread as KYC — and how open relays get misread as having no access control at all.

This note is protocol literacy from the live NIP text. It assumes NIP-11 (what a relay claims) and NIP-65 / stale lists (where authors prefer to publish) are already in view. AUTH answers a third question: may this connection use this relay for this job?

The messages: AUTH, challenge, kind 22242

NIP-42 (draft, optional, relay-facing) adds a bidirectional AUTH frame on the WebSocket.

• Relay → client: ["AUTH", <challenge-string>]
• Client → relay: ["AUTH", <signed-event-json>]

The signed event is ephemeral kind: 22242. It is not meant to be published or queried. Relays MUST exclude kind: 22242 from broadcast. The event should carry at least two tags: ["relay", "<relay-url>"] and ["challenge", "<challenge-string>"], with created_at set to the current time. Clients MAY send several AUTH events from different pubkeys on the same connection; relays MUST treat all such pubkeys as authenticated for that session. Client AUTH messages MUST be answered with OK, like ordinary EVENT writes.

Two machine-readable prefixes matter once AUTH is in play (on OK for writes and CLOSED for refused subscriptions):

• auth-required: … — the client has not authenticated (or has no stored challenge yet) and the relay needs AUTH to fulfill the query or accept the event.
• restricted: … — the client did AUTH, but that key is still not allowed (or has exceeded its authorization).

So a failed write after AUTH is not “try signing again louder.” It is a different failure class: identity-of-key on the socket succeeded; policy still said no.

What the relay verifies (and what that means)

NIP-42’s verification checklist is short and mechanical. Relays must ensure:

1. kind is 22242
2. created_at is close to now (the NIP’s example window is ~10 minutes)
3. the "challenge" tag matches the challenge previously sent on this connection
4. the "relay" tag matches the relay URL (URL normalization allowed; domain match often suffices)

The challenge is valid for the duration of the connection, or until the relay sends a new one. The client MAY AUTH at any time; once accepted, the authenticated session lasts for that connection.

Read that list as a threat model, not as marketing:

• Replay across connections fails if challenges are fresh per connection (or rotated).
• Cross-relay reuse fails if the relay tag is checked — signing for wss://a.example should not open wss://b.example.
• Stale signatures fail under the created_at window.
• Nothing here checks a government ID, an invoice, or a social graph. Those are relay-local policies that may use the authenticated pubkey as an input. AUTH only delivers the pubkey-binding for the socket.

Motivation examples in the NIP stay in that frame: whitelist gates for publishing without requiring every event to be signed by the whitelisted key; restricting kind: 4 DM queries to chat parties; limiting subscriptions to allowlisted users. The mechanism is always “prove you hold this key on this connection.” The reason the relay cares is local policy.

Common flows: REQ, EVENT, and the auth EOSE hint

Relays often require AUTH only for some jobs. Two patterns dominate.

Subscription path. Relay may send AUTH with a challenge early, or just before refusing. Client opens REQ (e.g. kinds: [4]). Relay answers CLOSED with auth-required: …. Client signs 22242, gets OK, re-issues the REQ, and receives EVENTs. The NIP’s hard requirement for clients: store the challenge associated with that relay so an auth-required CLOSED is actionable — not a mysterious dead end.

Write path. Same choreography with OK instead of CLOSED: publish EVENT → OK false auth-required: … → client AUTH → OK on the auth event → republish → OK true (or restricted if policy still blocks).

A third signal sits on NIP-67’s optional EOSE hints. Beside "finish" and "more", a relay MAY send "auth" to say more stored matches may exist after AUTH. Relays that emit "auth" MUST send the AUTH challenge before that EOSE. Absence of hints is not completeness; "auth" means the unauthenticated view may be a subset.

None of these flows mint a network-wide session. AUTH is per WebSocket to that relay. Drop the socket, lose the session. Another relay never saw your 22242.

Why “public gossip” still has gates

Signatures authenticate events. AUTH authenticates connections to a store. Those layers stack:

Layer	Question answered	Typical NIP
Event signature	Did this pubkey commit to this content?	NIP-01
Relay document	What does this operator claim to support?	NIP-11
Outbox / inbox lists	Where does this author prefer write/read?	NIP-65
AUTH	May this socket use this relay for this job?	NIP-42

A dark outbox in the stale-lists sequel can be downtime — or auth-required / restricted the client never satisfies. From the follower’s seat both look like silence. Literacy splits them: probe reachability, read machine-readable prefixes, and know whether your client ever signed 22242 for that URL.

Civil-liberty stakes are global without a local bank story. Community relays, invite-only write sets, and DM-protecting stores use the same challenge-response. Journalists and organisers on constrained networks still meet gated sockets when operators refuse anonymous scrapes of private kinds. That is access control on gossip infrastructure — not a passport check.

What AUTH does not prove

Spell the negatives so product language cannot smuggle them back in:

• Not legal identity. A valid 22242 shows key possession for a challenge. It does not bind a legal name, device attestation, or jurisdiction.
• Not payment proof. Relays may separately require payment or whitelist membership; AUTH only identifies which pubkey speaks on the wire. NIP-42 defines no invoices or balances.
• Not content endorsement. Authenticating to publish does not make the relay vouch for the note. OK is local acceptance, not a network notary seal.
• Not cross-relay SSO. No shared auth cookie. Each relay challenges; each connection re-proves.
• Not a substitute for event verification. You still verify notes under NIP-01. AUTH never replaces id/sig checks.

What this is not

This note is not a ranked list of AUTH-requiring relays, a client setup guide, or a pitch to pay for relay access as a product or investment. It does not redefine Nostr as a permissioned ledger. It does not claim every public relay must or must not use AUTH. It does not teach bypassing relay policy, scraping restricted DMs, or evading lawful process. It does not treat restricted after successful AUTH as a protocol bug. It does not advise custody, trading, or swaps.

Educational takeaway: public signed gossip and per-relay connection gates coexist by design. When a socket asks you to sign kind: 22242, you are proving key holdership for that challenge on that URL for that connection — nothing more. Read auth-required and restricted as different sentences. Keep NIP-11 claims, NIP-65 preferences, and NIP-42 sessions in separate mental drawers.

Related on CryptoDecentral

• Nostr pillar
• NIP-11: How Nostr Relays Advertise What They Can Do
• NIP-65: Relay Lists, Outbox, and Inbox — Routing Beyond One Home Relay
• Stale Lists and Dark Outboxes: When NIP-65 Metadata Lies by Age or Uptime
• Network metrics

Further reading (primary)

• NIP-42 Authentication of clients to relays (raw)
• NIP-42 on GitHub
• NIP-42 HTML mirror
• NIP-01 Basic protocol flow (raw)
• NIP-01 on GitHub
• NIP-67 EOSE Completeness Hint (raw)
• NIP-67 on GitHub
• NIP-67 HTML mirror