spec: withdraw NIP-C6 normative reference; rewrite §5.4 as informational

PR nostr-protocol/nips#2327 was withdrawn 2026-04-28 after fiatjaf
review pushback ("URL self-identifies, no need for tags") and the
realization that standard OpenGraph metadata on the artifact path is
the universal substrate that gives capability URLs first-class
rendering on every platform — Nostr included — without any per-event
tag schema.

- §5.4 rewritten as informational "Sharing on Nostr" — paste the URL
  into kind:1 content; aware clients render via standard OpenGraph
  unfurl. The single normative rule retained is fragment-hygiene: the
  read key MUST NOT appear in any indexable transport-layer tag
- §9.6 (NIP-C6 bridge conformance) removed — superseded by §5.4
- §11.4 (tag schemes for capability URLs) removed — no longer relevant
- §10.1 reference updated to "indexable transport-layer tags (e.g.,
  Nostr event tags)" instead of NIP-C6-specific
- MANIFESTO.md "federation seam" sentence reframed: the capability URL
  itself is the federation seam (its shape is a contract between hosts
  and clients), not a Nostr-specific NIP

CHANGELOG bumped to 0.1.1.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: DeltaClimbs

MANIFESTO.md

@@ -16,7 +16,7 @@ Worth standardizing because the wire format is small enough to verify, the feder
 
 ## Why federation
 
-A messaging primitive that runs on one host is a hostage. A messaging primitive that runs on a hundred hosts, with a published wire spec and a conformance suite, is infrastructure. NIP-C6 — the Nostr NIP for capability-URL artifacts — is the federation seam. Any operator can stand up a host. Any client can read from any host. No single party owns the namespace, the keys, or the off-switch.
+A messaging primitive that runs on one host is a hostage. A messaging primitive that runs on a hundred hosts, with a published wire spec and a conformance suite, is infrastructure. The capability URL is the federation seam — its shape is a contract between hosts and clients, not a property of any particular implementation. Any operator can stand up a host. Any client can read from any host. No single party owns the namespace, the keys, or the off-switch.
 
 If the reference implementation disappears tomorrow, the spec survives, the conformance suite survives, the existing artifacts on every other host keep decrypting. That is the only acceptable shape for something touching encrypted communications.
 

spec/CHANGELOG.md

@@ -4,11 +4,16 @@ Per-document semver. Breaking changes do not amend an existing MOP-NNN — they
 
 ## MOP-001
 
+### 0.1.1 — 2026-04-28 (draft)
+
+- **§5.4 rewritten** as informational "Sharing on Nostr." The earlier draft referenced NIP-C6 (`nostr-protocol/nips#2327`) as a normative bridge. That NIP was withdrawn the same day in favor of the simpler "URL self-identifies + standard OpenGraph rendering" model. The URL alone is the contract; no per-event tag schema is required. Fragment-in-indexable-tags privacy rule retained as the one normative constraint.
+- **§9.6** (NIP-C6 bridge conformance) **removed** — superseded by the §5.4 rewrite.
+- **§11.4** (tag schemes for capability URLs) **removed** — no longer relevant.
+
 ### 0.1.0 — 2026-04-28 (draft)
 
-Initial draft. Extracted from the SendWyrd reference implementation as deployed at sendwyrd.com. Two normative items locked in this revision:
+Initial draft. Extracted from the SendWyrd reference implementation as deployed at sendwyrd.com. Locked in this revision:
 
-- **§5.4** — NIP-C6 scheme-id is `"mop-v1"`. Bridge tags emit this exact byte string.
 - **§6.2 and §6.5** — domain prefixes frozen as-shipped for v1 conformance. The mix of `"mop:v1:..."` (signing, reply ECIES) and `"sendwyrd:..."` (HD HKDF, seed-store) is the v1 wire. A future MOP-NNN will normalize to `"mop:v1:..."` everywhere with a versioned migration.
 
 Pre-1.0. Wire format may change before 1.0 is cut.

spec/MOP-001.md

@@ -278,24 +278,15 @@ The URI scheme `sendwyrd://w/<handle>#<K_read_b64u>` (or with path-form k-segmen
 
 > The `sendwyrd://` scheme prefix is a reference-implementation artifact. MOP-002+ SHOULD register a generic `mop://` scheme; until then, implementations MUST accept `sendwyrd://` for v1 interop.
 
-### 5.4 NIP-C6 normative reference {#mop-001-5-4}
+### 5.4 Sharing on Nostr {#mop-001-5-4}
 
-When a MOP capability URL is shared on the Nostr network, references and shares **MUST** follow NIP-C6 (*Capability-URL References*), which defines the `c`/`expires_at`/`k` tag convention for `kind:1` events and NIP-17 gift-wrapped DMs.
+A MOP capability URL is a self-describing artifact and shares cleanly across any transport, including Nostr. To share on Nostr, paste the URL into `kind:1` content (or into the inner sealed event of a NIP-17 gift-wrap for direct messages). Aware Nostr clients MAY recognize the URL pattern and render it as an encrypted-artifact card via standard OpenGraph metadata served by the relay; no special tag schema is required.
 
-NIP-C6 is the user-authored Nostr NIP for this addressing pattern; MOP is one consumer among others. The scheme-id registered for MOP-001 references is **`mop-v1`**. Implementations bridging MOP to Nostr MUST emit this exact string in the `scheme` position of NIP-C6 bridge tags.
+Implementations bridging MOP to Nostr MUST observe one privacy rule, derived from fragment-hygiene (§10.1):
 
-References:
+- The read key (URL fragment) MUST NOT be placed inside any **indexable** Nostr tag. Tags are stored cleartext on relays and are scrapeable; fragments are bearer secrets. If implementing a tag-based reference convention, the canonical URL MUST appear with the fragment stripped.
 
-- Draft text mirrored at `what/docs/spec/nip_capability_url_v1.md` in the SendWyrd reference repo.
-- Pull request: `nostr-protocol/nips#2327` (open).
-
-NIP-C6 normatively:
-
-1. The Nostr `c` tag MUST carry the canonical URL with the fragment **stripped**.
-2. A `k` tag carrying the read key turns a *reference* into a *share*.
-3. Read keys MUST NOT appear in any tag other than `k`. In particular, a fragment-bearing URL inside a `c` tag is a privacy violation: tags are indexable, fragments are bearer secrets.
-
-Implementations that bridge MOP to Nostr MUST honor these constraints.
+> An earlier draft of this spec referenced NIP-C6 (*Capability-URL References*, `nostr-protocol/nips#2327`) as a normative bridge. That NIP was withdrawn 2026-04-28 in favor of the simpler "URL self-identifies + standard OpenGraph rendering" model — the URL alone is the contract, no per-event tag schema is needed for capability artifacts to render or distinguish reference from share (fragment present = share, fragment absent = reference).
 
 ## 6. Cryptographic Primitives {#mop-001-6}
 
@@ -598,14 +589,6 @@ A conformant MOP-001 implementation — relay or client — MUST satisfy every a
 - Burn MUST clear the envelope ciphertext and cascade-delete replies.
 - Replay window MUST be enforced at `±60_000` ms on every signed operation.
 
-### 9.6 NIP-C6 bridge conformance {#mop-001-9-6}
-
-Implementations that bridge MOP capability URLs to Nostr MUST:
-
-- Place the canonical URL **without fragment** in the `c` tag.
-- Place the read key in the `k` tag if and only if read access is being shared.
-- Never embed the fragment inside the `c` tag.
-
 ## 10. Security Considerations {#mop-001-10}
 
 ### 10.1 Fragment hygiene {#mop-001-10-1}
@@ -615,7 +598,7 @@ The K_read fragment MUST NOT appear in any of:
 - HTTP `Referer` headers
 - Server access logs
 - Web analytics payloads
-- Indexable Nostr tags (per §5.4)
+- Indexable transport-layer tags (e.g., Nostr event tags, per §5.4)
 - Browser history exports if mitigatable
 
 Web clients SHOULD set `Referrer-Policy: no-referrer` on fetch requests and SHOULD rewrite the URL bar to drop the fragment after first decode (so a casual screenshot doesn't leak the read key).
@@ -666,10 +649,6 @@ A future version that adds AAD fields MUST bump `ENVELOPE_VERSION` to a new byte
 
 Body conventions like §4.9's authorship attestation are out-of-band: the relay does not parse them. New body conventions are registered by precedent (first-shipped) and SHOULD use a `mop-<convention>/v<N>` header line on the body's first line, e.g. `mop-attestation/v1`.
 
-### 11.4 New tag schemes for capability URLs {#mop-001-11-4}
-
-NIP-C6 tag extensions for capability URLs are governed by the Nostr NIP process; MOP-001 does not assert authority over them. MOP-002+ MAY define MOP-specific tags that NIP-C6-aware Nostr clients SHOULD recognize via the registered scheme-id.
-
 ---
 
 *End of MOP-001.*