From dff1a27c0c670e4bedf9a3b509bacda3984d77f2 Mon Sep 17 00:00:00 2001 From: thePR0M3TH3AN <53631862+PR0M3TH3AN@users.noreply.github.com> Date: Mon, 22 Jun 2026 09:57:59 -0400 Subject: [PATCH] docs(nip71): record dual-event vs single-canonical decision Decided to keep the dual-event model (kind 30078 canonical + additive 34235/36 mirror) rather than collapse to a single canonical 34235 note. Captures the rationale: private videos can't be public NIP-71 (no encryption), and kind 30078 is the addressing root (watch-history/comments/reactions/views/playlists/naddr/ moderation + hardcoded video filters) so switching it is a large forward-only migration not worth the interop win right now. Accepted trade-off: keep the mirror in sync on edit/delete (Phase 1 polish). Phase 0/1 builder/parser remain reusable if single-canonical is ever revisited. Co-Authored-By: Claude Opus 4.8 --- docs/nip71-migration-plan.md | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/docs/nip71-migration-plan.md b/docs/nip71-migration-plan.md index 05509fc7..3b3d7d0e 100644 --- a/docs/nip71-migration-plan.md +++ b/docs/nip71-migration-plan.md @@ -15,6 +15,24 @@ NIP-71 videos. Decisions below were made with the maintainer; see "Decisions". 1. **Kind: addressable `34235` (normal) / `34236` (short).** 2. **Opt-in, off by default** — per-video toggle; private videos never mirrored. 3. **Scope: outbound first, inbound later** (Phase 1 vs Phase 2). +4. **Dual-event model (decided 2026-06-22), NOT single-canonical.** Considered + collapsing to one note type by making bitvid's canonical video event itself + kind 34235/36. Verdict: keep kind 30078 canonical + an additive mirror. + - *Why a single note is appealing:* one event, no drift, fully discoverable. + - *Why we're not doing it (yet):* (a) **private videos can't be public NIP-71** + (no encryption) so they'd stay 30078 regardless — "one note for everything" + is impossible, only "one note for public"; (b) **kind 30078 is the addressing + root** — `30078:pubkey:d` is referenced by watch-history pointers, comments, + reactions, view counts, playlists, naddr deep-links, and moderation, plus + hardcoded video subscription filters (`nostrService.VIDEO_KIND`, + `videoPointer.DEFAULT_VIDEO_KIND`, `kinds:[30078]` across client/channel/ + search). Switching the canonical kind ripples through all of them and needs a + forward-only dual-read migration. Not worth the risk for the interop win. + - *Accepted trade-off:* two events per shared video; the mirror can drift from + the canonical, so the lifecycle must keep them in sync (auto re-publish on + edit / remove on delete) — see Phase 1 polish. + - The Phase 0/1 builder+parser are reusable if we ever revisit single-canonical + (they'd become bitvid's native 34235 read/write layer). ### Why 34235/34236 (research-validated)