PR #2337: NIP-11 nip9b pointer (companion to NIP-9B)

Published Jun 28, 2026

Recreation note. This is a copy of pull request nostr-protocol/nips#2337 (companion to NIP-9B), preserved as a custom NIP because my GitHub account (mstrofnone) is currently suspended.

PR body

NIP-11: add `nip9b` pointer for relay-enforced rules

Adds an optional "nip9b": "34551:<hex>:<d>" field to the NIP-11 Relay Information Document, as the machine-readable companion to the existing terms_of_service (human-readable URL) and description (freeform) fields.

This is the smallest possible spec change that unblocks Amethyst's tier-2/3/4 work on community-rules enforcement (see PRs #2839 / #2840), and any other client that wants to discover relay-enforced rules without round-tripping through a relay-specific REST endpoint.

Why this NIP

If a relay enforces a kind:34551 rules document published by NIP-9B, clients currently have no portable way to discover which rules document. The options today are:

Hard-code per-relay knowledge in client code (doesn't scale).
Send a draft event, get a NIP-20 OK with the rules-document URI in the message, parse free-form text (fragile).
Probe with a no-op event (wasteful, leaks user activity to the relay's logs).

Adding a single optional field to the existing NIP-11 RID is the cleanest fix: relays that opt in advertise their rules-document a-coordinate; clients fetch the document once and validate every draft locally.

Scope discipline

One new optional field in NIP-11: nip9b.
Value is a NIP-19 a coordinate (e.g. "34551:<hex>:<d>") — same shape relays/clients already use for NIP-72 communities.
No changes to any other NIP.
Renumbered from nip9a to nip9b in lockstep with #2331, since slot 9A was already claimed.

Cross-reference

This PR is deliberately separated from the in-review #2331 to keep NIP-9B's spec tight. Both are merge-ready independently; reviewers can land either in either order. The two commits in this PR reflect the slot renumber done during #2331's review.

Notes for review

Field is optional. Relays that don't advertise it behave exactly as today (no breakage for any existing client).
Doesn't claim a new kind, doesn't break NIP-11 v0 readers (unknown fields ignored).

Proposed `11.md` diff

diff --git a/11.md b/11.md
index 5caaccc..29a72fc 100644
--- a/11.md
+++ b/11.md
@@ -22,7 +22,8 @@ When a relay receives an HTTP(s) request with an `Accept` header of `application
   "supported_nips": <a list of NIP numbers supported by the relay>,
   "software": <string identifying relay software URL>,
   "version": <string version identifier>,
-  "terms_of_service": <a link to a text file describing the relay's term of service>
+  "terms_of_service": <a link to a text file describing the relay's term of service>,
+  "nip9b": <NIP-9B rules pointer, e.g. "34550:<hex64-pubkey>:<d-identifier>">
 }
 ```
 
@@ -84,6 +85,35 @@ The relay MAY choose to publish its software version as a string attribute. The
 
 The relay owner/admin MAY choose to link to a terms of service document.
 
+### NIP-9B Rules
+
+A relay that enforces a [NIP-9B](9B.md) `kind:34551` rules document
+against inbound writes MAY publish a `nip9b` pointer in this document.
+The pointer is an addressable event coordinate that identifies the
+rules document, in the same `<kind>:<author>:<d-identifier>` form used
+by `a` tags elsewhere in the protocol. The most common shape today
+binds to a NIP-72 community and therefore points at `kind:34550`:
+
+```jsonc
+{
+  "nip9b": "34550:<hex64-pubkey>:<d-identifier>"
+  // other fields...
+}
+```
+
+The pointer is the *machine-readable* companion to `terms_of_service`
+(human-readable terms) and `description` (free text). Clients that
+implement NIP-9B SHOULD, on relay-info fetch, resolve the pointer to
+the latest matching `kind:34551` event, validate outbound drafts
+against it locally before publishing to this relay, and surface
+violations to the user before send. Clients that do not implement
+NIP-9B MUST ignore this field (per the "MUST ignore unknown fields"
+rule above).
+
+The relay itself MAY also enforce the same rules server-side. The
+rules document is signed by its owner, so an honest client and an
+honest relay reach identical verdicts on every draft.
+
 Extra Fields
 ------------