{"id":"8d000e03160c440ab54386a8e2ac82338c8a2d9cf3e3b3e9ca854891da8ea321","pubkey":"43185edecb675892824b1a37a57f3e407fbde2eda7201a3829b8cf4ba7c5b4f0","created_at":1782681148,"kind":30817,"tags":[["title","PR #2337: NIP-11 nip9b pointer (companion to NIP-9B)"],["alt","Custom NIP: PR #2337: NIP-11 nip9b pointer (companion to NIP-9B)"],["l","recreated-github-pr"],["L","org.nostr-protocol.nips"],["d","pr-2337-nip11-nip9b-pointer"]],"content":"> **Recreation note.** This is a copy of pull request [nostr-protocol/nips#2337](https://github.com/nostr-protocol/nips/pull/2337) (companion to NIP-9B), preserved as a custom NIP because my GitHub account (`mstrofnone`) is currently suspended.\n\n---\n\n## PR body\n\nNIP-11: add `nip9b` pointer for relay-enforced rules\n====================================================\n\nAdds an optional `\"nip9b\": \"34551:<hex>:<d>\"` field to the [NIP-11 Relay Information Document](https://github.com/nostr-protocol/nips/blob/master/11.md), as the machine-readable companion to the existing `terms_of_service` (human-readable URL) and `description` (freeform) fields.\n\nThis 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.\n\n## Why this NIP\n\nIf 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:\n\n- Hard-code per-relay knowledge in client code (doesn't scale).\n- Send a draft event, get a NIP-20 OK with the rules-document URI in the message, parse free-form text (fragile).\n- Probe with a no-op event (wasteful, leaks user activity to the relay's logs).\n\nAdding 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.\n\n## Scope discipline\n\n- One new optional field in NIP-11: `nip9b`.\n- Value is a NIP-19 `a` coordinate (e.g. `\"34551:<hex>:<d>\"`) — same shape relays/clients already use for NIP-72 communities.\n- No changes to any other NIP.\n- Renumbered from `nip9a` to `nip9b` in lockstep with [#2331](https://github.com/nostr-protocol/nips/pull/2331), since slot `9A` was already claimed.\n\n## Cross-reference\n\nThis PR is deliberately separated from the in-review [#2331](https://github.com/nostr-protocol/nips/pull/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.\n\n## Notes for review\n\n- Field is optional. Relays that don't advertise it behave exactly as today (no breakage for any existing client).\n- Doesn't claim a new kind, doesn't break NIP-11 v0 readers (unknown fields ignored).\n\n\n---\n\n## Proposed `11.md` diff\n\n```diff\ndiff --git a/11.md b/11.md\nindex 5caaccc..29a72fc 100644\n--- a/11.md\n+++ b/11.md\n@@ -22,7 +22,8 @@ When a relay receives an HTTP(s) request with an `Accept` header of `application\n   \"supported_nips\": <a list of NIP numbers supported by the relay>,\n   \"software\": <string identifying relay software URL>,\n   \"version\": <string version identifier>,\n-  \"terms_of_service\": <a link to a text file describing the relay's term of service>\n+  \"terms_of_service\": <a link to a text file describing the relay's term of service>,\n+  \"nip9b\": <NIP-9B rules pointer, e.g. \"34550:<hex64-pubkey>:<d-identifier>\">\n }\n ```\n \n@@ -84,6 +85,35 @@ The relay MAY choose to publish its software version as a string attribute. The\n \n The relay owner/admin MAY choose to link to a terms of service document.\n \n+### NIP-9B Rules\n+\n+A relay that enforces a [NIP-9B](9B.md) `kind:34551` rules document\n+against inbound writes MAY publish a `nip9b` pointer in this document.\n+The pointer is an addressable event coordinate that identifies the\n+rules document, in the same `<kind>:<author>:<d-identifier>` form used\n+by `a` tags elsewhere in the protocol. The most common shape today\n+binds to a NIP-72 community and therefore points at `kind:34550`:\n+\n+```jsonc\n+{\n+  \"nip9b\": \"34550:<hex64-pubkey>:<d-identifier>\"\n+  // other fields...\n+}\n+```\n+\n+The pointer is the *machine-readable* companion to `terms_of_service`\n+(human-readable terms) and `description` (free text). Clients that\n+implement NIP-9B SHOULD, on relay-info fetch, resolve the pointer to\n+the latest matching `kind:34551` event, validate outbound drafts\n+against it locally before publishing to this relay, and surface\n+violations to the user before send. Clients that do not implement\n+NIP-9B MUST ignore this field (per the \"MUST ignore unknown fields\"\n+rule above).\n+\n+The relay itself MAY also enforce the same rules server-side. The\n+rules document is signed by its owner, so an honest client and an\n+honest relay reach identical verdicts on every draft.\n+\n Extra Fields\n ------------\n \n\n```\n","sig":"5792be6814f935acf7d9a461c81ef366561f1614bee67299ae1b7930c80c6dc34166bd75a1e77e08fbb15b9f5b4d51741950378cc439c293581e2881d22a1584"}