NIP-C6: Capability-URL References

[DeltaClimbs]

NIP-C6: Capability-URL References

Adds a tag schema and rendering convention for Nostr events that reference capability-encrypted artifacts hosted off-Nostr — where the read key lives in the URL fragment, the host is read-blind, and the event author is referencing or sharing the artifact rather than embedding its body.

Why

Capability URLs (e.g. https://example.com/cap/{id}#{read_key}) are a real privacy primitive used by several systems. Pasted naked into a Nostr event, they render as plain text. NIP-aware clients can render them as first-class objects: encryption badge, expiry hint, and — most importantly — distinguish citation (c tag, no k) from access-grant (c + k).

The schema is scheme-agnostic. Any artifact protocol whose URLs follow the <canonical>#<read_key> shape can plug in via an opaque scheme-id. No central registry; first-claim by precedent.

Backward compatibility

Uses kind:1 text notes with additive tags. Non-aware clients render exactly as they do today (the URL appears as a clickable link in content). Aware clients see the c tag, dispatch by scheme-id, and apply enhanced rendering. Aware clients MUST NOT hide events whose scheme-id they don't recognize.

Reference vs. share

Two semantics on the same schema:

• Reference (c tag, k absent): "I'm talking about this artifact." Doesn't broadcast bearer access.
• Share (c tag + k tag): "I'm handing out read access." k tag carries the read key; treat as bearer capability.

The distinction matters because pasting a URL+fragment into a public Nostr event leaks the read key to anyone who reads the post. The c-only form gives authors a way to cite an artifact without granting access.

NIP-17 DM context

The same schema serves as the inner sealed event of a NIP-17 gift-wrap. k tag MAY be present in DM context since the transport is end-to-end encrypted to the recipient.

Reference implementation

Inline TypeScript template builder in the spec; produces an unsigned event template ready for any Nostr signer (NIP-07, raw nsec, etc.).

Number choice

Picked C6 after checking that no PR (open, closed, or merged) currently claims it. Decimal alternatives in the 90s and 100s are heavily contested (3+ open PRs each). Happy to renumber per editor preference.

Open questions

• Whether the canonical event should be kind:1 with additive tags (current proposal) or a new dedicated kind. Argument for kind:1: backward compat + max reach + this is fundamentally a social-graph artifact. Argument for new kind: cleaner semantics. Open to discussion.
• Whether the spec should standardize a scheme-id registration mechanism (probably not — open-ended is fine, IANA-shaped registries are heavy).

[fiatjaf]

I feel like this is asking too much from the sender, to have to add all these tags.

If the URL already identifies itself as a capability-URL why not just rely on just that? I don't see the need for extra tags.

[DeltaClimbs]

You were right — withdrawing.

Empirical test: pasted a capability URL into Nostr, got no preview, dug into why. The actual coordination layer is OpenGraph metadata on the artifact path itself — works on every platform that does link-card rendering, no per-event tag schema needed. So the host now serves a content-free OG card (the host can't decrypt anyway — fragment never travels HTTP per RFC 3986 §3.5), and Nostr clients render the link the same way they render any other URL with OG.

Reference-vs-share is already encoded in the URL: fragment present = share (you handed out the read key), fragment absent = reference (you're citing without granting access). No k tag needed.

The whole tag schema was solving a coordination problem that OpenGraph already solves.

Thanks for the push.

[DeltaClimbs]

Follow-up on the withdrawal — opened a successor at #2329 (NIP-G6).

Both of your objections from this thread are baked in:

1. Sender burden → zero. No tags, no signer changes. Senders paste the URL exactly like today.
2. URL self-identification → preserved. Clients pattern-match on URL shape; the NIP just supplies the protocol-specific decryption knowledge (envelope format + cipher) that pattern-matching alone can't.

The question NIP-C6 was answering — how do clients know an event references a capability URL? — dissolves once you accept the URL self-identifies. The remaining question is: given a Nostr client encounters one of these URLs, what's the best rendering it can do? G6 specs that: fetch the envelope, decrypt client-side with the URL fragment, render plaintext inline in feed in lieu of the standard OG card.

Happy to take feedback at #2329 (or here, if it's about the C6 → G6 transition specifically).