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

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 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::"
• // 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#