Check yourself: Nostr relays, lists, and AUTH

Questions and answers, readable without JavaScript.

1. What does a NIP-65 kind:10002 event advertise?

   • A global ranking of relays
   • Your legal name and email
   • A payment invoice for the relay
   • Relays where you generally write, and relays where you generally read mentions
   Answer 1

   Relays where you generally write, and relays where you generally read mentions

   NIP-65 is a replaceable kind:10002 event. Its r tags advertise write relays (outbox) and read relays (inbox for mentions). The content field is empty.

   Read the note → · NIP-65: Relay Lists, Outbox, and Inbox — Routing Beyond One Home Relay

2. How large does NIP-65 say clients should guide people to keep each relay category?

   • Every public relay
   • About 2–4 relays of each category
   • Exactly one home relay
   • At least 20, for censorship resistance
   Answer 2

   About 2–4 relays of each category

   Clients SHOULD guide users to keep lists small — about 2–4 relays of each category. Huge lists recreate connecting to everything.

   Read the note → · NIP-65: Relay Lists, Outbox, and Inbox — Routing Beyond One Home Relay

3. What is the difference between a NIP-11 document and a NIP-65 list?

   • NIP-11 is what a relay claims it can do; NIP-65 is which relays this pubkey prefers for write versus read
   • They are the same JSON file
   • NIP-11 is signed by the user and NIP-65 is unsigned
   • NIP-65 replaces event signatures
   Answer 3

   NIP-11 is what a relay claims it can do; NIP-65 is which relays this pubkey prefers for write versus read

   A NIP-11 document does not say whether an author publishes there. A kind:10002 list does not state that relay's limits. The notes keep those jobs apart.

   Read the note → · NIP-65: Relay Lists, Outbox, and Inbox — Routing Beyond One Home Relay

4. Are outbox lists a network vote or a consensus?

   • Yes — relays count votes and lock one global feed
   • Yes, but only for kind 1 notes
   • No. They are availability preferences. Lists go stale, relays go dark, and clients merge what they can see
   • Only if every client uses the same indexer
   Answer 4

   No. They are availability preferences. Lists go stale, relays go dark, and clients merge what they can see

   The stale-lists note says outbox lists are availability preferences, not network votes. Client merge is not a global ordered feed, and that missing total order is by design.

   Read the note → · Stale Lists and Dark Outboxes: When NIP-65 Metadata Lies by Age or Uptime

5. Does "latest kind:10002" mean the whole network agreed on your relay list?

   • Yes, replaceable events are a consensus protocol
   • No. Latest-wins is a local retention rule for one pubkey and kind. Two relays can still hold different versions for a while
   • Yes, because the lowest id always wins globally
   • Only when the list has a NIP-11 signature
   Answer 5

   No. Latest-wins is a local retention rule for one pubkey and kind. Two relays can still hold different versions for a while

   For replaceable kinds, a relay keeps the latest event per pubkey and kind. That is not BFT consensus. Two honest relays can temporarily hold different versions.

   Read the note → · Stale Lists and Dark Outboxes: When NIP-65 Metadata Lies by Age or Uptime

6. What does NIP-42 AUTH prove?

   • Legal identity and payment status
   • That every relay will store your notes
   • That the event content is true
   • Possession of a private key for a connection-scoped challenge bound to a relay URL — not legal identity, payment, or network endorsement
   Answer 6

   Possession of a private key for a connection-scoped challenge bound to a relay URL — not legal identity, payment, or network endorsement

   AUTH proves this connection holds a key for this relay's challenge. It does not prove legal identity, payment status, moral standing, or that the wider network endorsed you.

   Read the note → · AUTH Is Not Identity: What NIP-42 Relay Challenges Actually Prove

7. Should a kind:22242 AUTH event be broadcast?

   • Yes, so other relays learn you are authenticated
   • Only inside a kind 10002 list
   • No. It is ephemeral. Relays must exclude kind 22242 from broadcast
   • Yes, but without the challenge tag
   Answer 7

   No. It is ephemeral. Relays must exclude kind 22242 from broadcast

   The signed AUTH event is ephemeral kind 22242. It is not meant to be published or queried. Relays MUST exclude it from broadcast.

   Read the note → · AUTH Is Not Identity: What NIP-42 Relay Challenges Actually Prove

8. How should you treat a NIP-11 relay information document?

   • As optional, self-reported metadata — a hint — because behaviour can diverge from the claim
   • As cryptographic proof the relay stores events honestly
   • As a replaceable kind:10002 event
   • As a guarantee of global censorship resistance
   Answer 8

   As optional, self-reported metadata — a hint — because behaviour can diverge from the claim

   NIP-11 is optional self-reported JSON. A relay can claim every supported NIP and still behave differently. Good clients treat the document as a hint, then check live traffic.

   Read the note → · NIP-11: How Nostr Relays Advertise What They Can Do