bitvid/todo/TODO_2026-06-20_pre-launch.md

TODO — Pre-launch fixes & audits (2026-06-20)

Consolidated pre-launch backlog. Branch: unstable (promote down to beta/main later). Cadence: audit → small separately-committed fixes → cheat-resistant (mutation-verified) tests → npm run build + npm run test:unit green → commit + push.

Done this session (for context — don't redo)

• Background watch-history preload after login — 512b6c3f
• Multi-webseed support (upload + edit management)
• 10/10 file-size decompositions (real extraction, not baseline bumps)
• WebTorrent feed-scroll freeze fix (probe concurrency 96→4, maxConns caps) — 126ac75a
• "No active signer" on storage unlock after refresh — 0031d68b / f383cde4
• Relay removal routing fix (mainController.runRelayOperation) — 95071fd1
• Publish array-return fix (nostr-tools 2.17 per-relay promises; no uncaught-rejection flood) — 6984fb2e
• Empty-thumbnail-on-publish fix — f218ec32
• Relay list tab: live/dead status pills + insecure-relay hints
• Edit modal upload parity (replace video + thumbnail file) — c8a63c57
• Edit: clean up superseded thumbnail (orphan removal) — 3aef97f0
• Feed never blank: always reserve live default relays in the feed set — de515462 (+ spec test 6b63625d)
• Publish feedback: "published to N/M relays" outcome toast — 3f4299a8
• Delete safety: warn when a hosted file is left behind by locked storage — f0eecec0
• Video delete propagation: tombstones publish to write relays — afb6200b
• Watch-history delete: replace (not merge) semantics — 5f19f536
• My Videos tab (Phase 1 + 2): per-video health (no-source/dead/deleted), thumbnails, Edit/Delete, bucket reconciliation (missing-file + orphan cleanup) — 8cb03d23…9d3a0df0
• CI: visual-regression moved to its own job so it no longer blocks deploy — 73a06069
• Vercel: disable auto-deploy for unstable; deploy on demand via vercel deploy --prod — ba1f492f

Open — high priority (launch-blocking candidates)

33. Login / profile / session persistence broken with NIP-46 (Amber) — AUDIT (BUG)

Reported 2026-06-25. All symptoms observed with a NIP-46 remote signer (Amber). Likely a shared root cause in session/identity persistence + multi-account handling.

• Lost login → "unknown user". Sometimes the site loses who is logged in: the profile shows "unknown user", the profile area renders weird, and no videos load. Only a logout + hard refresh recovers it. (Session/identity state desync — possibly the NIP-46 signer connection or the persisted pubkey dropping after a refresh/idle, leaving the UI without a resolved identity.)

• Switching profiles doesn't work for logged-in users (multi-account switch is broken).

• Logout logs out everyone. Logging out the current user appears to log out every signed-in account, not just the active one (shared/global session state instead of per-account).

• Audit the whole login + profile system + user persistence across refresh and repeat visits — especially the NIP-46 path: how the active pubkey + signer connection are stored/restored, how multiple accounts are tracked, and how logout scopes to one account. Produce a plan (likely docs/), then fix.

• AUDIT done 2026-06-25 (code-level). Architecture: js/state/cache.js persists a list of saved profiles (bitvid:savedProfiles:v1) + a single active profile pubkey. There is ONE active session at a time. SignerManager (js/nostr/managers/SignerManager.js) holds a SINGLE shared this.nip46Client (one remote-signer connection). Likely root cause for ALL three symptoms: the single-shared nip46Client + per-profile restore/switch not being multi-account-aware. Specifics: - Logout-logs-out-everyone: authService.logout() IS registry-scoped (logoutSignerFromRegistry(previousPubkey)), but SignerManager.logout() calls disconnectRemoteSigner() which destroys the SHARED nip46Client — so for NIP-46 every profile that depends on it loses its signer. - Switch-doesn't-work: authService.switchProfile re-runs requestLogin with expectPubkey; for NIP-46 the shared client must be re-established for the target profile — if it doesn't reconnect, the new profile has no working signer. - Unknown-user-after-refresh: scheduleStoredRemoteSignerRestore → useStoredRemoteSigner silently fails (the catch logged via the gated devLogger), leaving this.pubkey unresolved → UI shows "unknown user".

• Diagnostics SHIPPED (2026-06-25, TEMP). Added [nip46-diag] userLogger traces (visible on unstable, where devLogger is gated off) at: scheduleStoredRemoteSignerRestore (hasStored/storedPubkey + succeeded/FAILED), disconnectRemoteSigner (keepStored/hadClient + caller stack), SignerManager.logout (previousPubkey/hadRemoteClient), and authService.switchProfile (from/to + whether requestLogin resolved the expected pubkey). Remove these once the fix lands.

• VERIFY / REPRODUCE (user action): on the phone with Amber on unstable.bitvid.network, exercise (1) fresh load, (2) switch profiles, (3) logout, and capture the [nip46-diag] console lines for each — restore succeeded/FAILED, switchProfile matchesTarget, and disconnect keepStored/hadClient/caller stack.

• THEN fix based on the captured trace (likely: per-profile NIP-46 session keyed by pubkey; don't tear the shared client on a scoped logout; reconnect on switch/restore) and REMOVE the temporary [nip46-diag] diagnostics.

1. Delete is not fully working — tombstoned videos still show in the UI

• Root cause found + fixed (afb6200b): deletes published only to the CAPPED read set (<=8) while videos publish to the full write set, so relays outside the subset kept serving the original → resurrection. Now both delete paths (soft-delete tombstone + NIP-09) use getDeletePublishRelays() (write set). Tombstone created_at was already bumped strictly-newer, so this closes the gap.
• getActiveKey mismatch — ROOT-CAUSED + FIXED (2026-06-23). js/nostr/client.js carried a STALE local duplicate of getActiveKey (added before the LEGACY guard landed in js/nostr/utils.js at 1b11cb1b). The tombstone machinery (recordTombstone/isOlderThanTombstone/applyTombstoneGuard) used the local copy, so a deleted legacy video (synthesized videoRootId = LEGACY:<pubkey>:<dTag>) keyed its tombstone as ROOT:LEGACY:… while a bare zombie from a relay keyed as <pubkey>:<dTag> → guard never matched → resurrection. Fix: client.js now imports the single canonical getActiveKey from utils.js (duplicate deleted). Regression test added in tests/nostr/client.test.mjs ("tombstone guard (legacy zombie suppression)") — in the CI suite.
• Cache / optimistic-reload angle — audited, OK. js/nostr/videoEventBuffer.js checks tombstones + deleted on every buffered event (cache-first reload honors deletions; lines ~89, 156–172).
• Mirror-resurrection angle — audited + GAP FIXED (2026-06-23). js/services/nip71MirrorSync.js listens on videos:deleted → nip71MirrorService.remove() (NIP-09 on BOTH addressable kinds 34235/34236 + empty-replace tombstone). Legacy auto-21/22 publisher stays dormant. GAP: teardown was gated on the per-video opt-in flag, which is browser-local only (bitvid:nip71-mirror:v1). A video shared on one device and deleted from another (or after a cache clear) skipped teardown → the NIP-71 mirror orphaned on other apps. Fixed in resolveDeleteSync (js/services/ nip71MirrorFlags.js): delete now ALWAYS attempts teardown when FEATURE_NIP71_MIRROR is on, ignoring the local flag (remove() is idempotent — NIP-09 + empty tombstone are no-ops if no mirror exists). The flag still gates the UI toggle; the feature flag still fully gates publishing. Spec-corrected unit test + sync-level spy tests (cross-device teardown + best-effort no-throw) in tests/nip71-mirror-flags.test.mjs + tests/nip71-mirror-sync.test.mjs.
• Verify with the user that zombies are gone on the live site after these fixes (the getActiveKey fix needs npm run build + redeploy to unstable to take effect).
• (Nice-to-have) Add a feed/view-level seed→delete→assert-not-rendered test now that the client-level guard + buffer tombstone paths are covered by unit tests.

2. Watch history delete does not work at all

• Root cause found + fixed (5f19f536): the removal path called watchHistoryService.snapshot(remaining, …) but snapshot published WITHOUT replace:true, and the default merges incoming items with the cached list — so the removed item was merged straight back (no effect). Removing the last item fell through to republishing the pending queue instead of clearing. Fixed: snapshot honors replace (incl. empty = clear), both removal call sites pass replace:true. Mutation-verified.
• Confirmed the NIP-51 list publish already uses the WRITE relays (publishRecords → getWriteRelays), so it does NOT have the #1 relay-scope bug. The replace-semantics fix is the complete fix.
• Second root cause found + fixed (fff2bef2): reads UNION items across all events relays return, and a publish only reports ok when ALL relays accept. With a flaky relay list the reduced event reached some relays while others kept the old copy; the reader deduped by event id, so stale+fresh versions of the same month (d-tag) were unioned → removed items resurrected. Now dedupeNewestPerReplaceableAddress keeps only the newest event per d-tag at both read union sites. Live on unstable.bitvid.network (module verified served).
• Third gap fixed (a3799f3f): clearing the LAST item of a month (or clearing all) didn't propagate — publishMonthRecord early-returned on an empty month, so the clearing event updateWatchHistoryList intended was never published. Now an empty month publishes a newest EMPTY replaceable event for its d-tag, so the clear takes effect (and reads see it as empty). Live.
• THE actual bug for the profile pane (4c6415c2): the profile modal's history renderer overrode remove to route through onHistoryReady → app.handleProfileHistoryEvent(), a no-op stub (return null) left from the synced-vs-local refactor. So profile-pane deletes published NOTHING (card vanished optimistically, reappeared on refresh) — which is why the earlier three fixes (publish/read layer) never helped there. Removed the override so it uses the working defaultRemoveHandler. Live.
• Logged-out / local-only delete (2f95d448): snapshot no-op'd for local-only actors, so removing from the local queue did nothing. A replace snapshot now rewrites the local queue (replaceLocalQueue). Live.
• All-relays false-failure fixed (565a9618): publishMonthRecord reported success only when EVERY write relay accepted, so on a 20+ relay list every snapshot was "partial-relay-acceptance" -> ok:false -> the logged-in remove threw "watch-history-snapshot-failed" (even though major relays accepted) AND new watches never persisted. Now success = acceptedCount > 0. Live.
• Verify with the user: logged-IN profile-pane delete + clear, AND logged-OUT local delete + clear, all stick across reload; AND that newly watched videos now appear in history (was blocked by the same all-relays bug).
• Backfill regression tests: a profile-pane wiring test (remove not routed to a no-op) — the existing profile-modal-controller test file has an unusual wrapper, so add carefully — plus a feed/view-level seed→delete→assert test. (Local + publish/read layers are already unit+mutation tested.)
• "1970-01" month bucketing FIXED (2026-06-23). Legacy/migrated history items with no real watchedAt were siloed into a literal 1970-01 month event (kind 30079) that self-perpetuated (read back as 0 → re-bucketed → re-published with 0). canonicalizeWatchHistoryItems now derives a STABLE watch time from the pointer d-tag's embedded ms-timestamp (the video creation time) and backfills it, so those items land in a real month and the 0→1970 loop stops. Only truly undecodable pointers still use the epoch bucket. Helper deriveWatchedAtFromPointer + tests/watch-history-bucketing.test.mjs. NOTE: the old 1970-01 event already on relays is left as harmless stale data (not recreated); actively clearing it was declined as extra surgery.

3a. Video-modal popover mis-positioning (zap) — FIXED 2026-06-23

The zap popover (#modalZapDialog) opened functional but anchored to the modal edge instead of bottom-end under its trigger.

• Root cause confirmed + fixed in the shared engine (js/ui/overlay/popoverEngine.js). The zap render fn returns the PRE-EXISTING in-modal #modalZapDialog verbatim (() => this.modalZapDialog, zapController.js). The engine only appended panels to the body-level portal if (!panel.isConnected), so this already-connected panel was never moved out; its position: fixed then resolved against a transformed/contained modal ancestor → edge anchoring. Fix: the engine now relocatePanelToPortal() on open (records the panel's origin: parent + nextSibling, moves it into the #uiOverlay portal) and restorePanelToOrigin() on close (and via destroy), so the host DOM stays intact and re-open works. Fresh portal-owned panels (card "⋯" menu, share/more menus, feed-settings gear) are unaffected — they're already appended to the portal, so relocate is a no-op for them. Style-safe: #modalZapDialog uses the same popover__panel card … classes the already-portaled menus use; no .modal-descendant CSS. Regression test in tests/ui/popoverEngine.test.mjs ("relocates a pre-existing in-host panel …"); all 9 engine tests + the menu-controller tests pass; build green.
• Verify with the user on the live site after deploy that the zap popover now opens bottom-end under the Zap button (and re-opens correctly).
• NOTE: the "embed" in the original report is a separate full modal (components/embed-video-modal.html, #embedVideoModal), NOT an anchored popover, so it isn't affected by this engine bug. The share/copy menu uses a fresh portaled panel and already positions correctly. If any other pre-existing in-modal panel is found mis-positioned, this same engine fix now covers it.

3. Zaps system + platform-fee zap split — DONE 2026-06-24 (full plan in docs/zap-audit-plan.md)

Audit started 2026-06-23. See the doc for architecture map + findings. Summary:

• Send-error softened (dd1ce113): recipient LNURL unreachable/CORS now shows a clear message, not raw "Failed to fetch".
• NWC connection bug FIXED (2026-06-23, launch-blocker) — parseNwcUri passed a hex secret to nostr-tools getPublicKey (needs bytes) → NWC connect threw expected Uint8Array and failed entirely. Now hex→bytes. Guarded by tests/nwc-parse-uri.test.mjs. This likely explains a lot of the "errors on send". VERIFY live: connect a wallet + send a zap end-to-end.
• Popover positioning (3a) — FIXED (see 3a).
• In-flight status + form-reset polish (2026-06-23) — "Sending…" no longer mis-toned as a warning; success path fully resets the form (resetZapForm).
• "Have to click the Zap button ~3-4 times before it opens" — ROOT-CAUSED + FIXED (2026-06-23). Diagnosed with click instrumentation: the button is intentionally hidden+disabled until the creator's Lightning address resolves (a profile fetch, ~2s) — but .video-modal__action-button sets display: inline-flex, which OVERRODE the UA [hidden] { display:none }, so the button rendered and looked clickable while still a disabled no-op. Disabled buttons don't fire click, so the first clicks did nothing until it flipped enabled. Fix: .video-modal__action-button[hidden] { display:none } (css/tailwind.source.css) so the zap button only appears once it's enabled/ready (restores the intended "show zap only when zappable" design). The earlier in-flight-open toggle tweak was harmless but NOT the cause. VERIFY live: the zap button appears a moment after the modal loads and opens on first click. FOLLOW-UP (optional UX): the ~2s appear-delay is the creator-profile fetch; could show the button immediately and resolve the address lazily if the delay annoys.
• Receipt success-reporting + discovery FIXED (2026-06-23) — a paid zap whose kind-9735 receipt couldn't be validated was shown as a red error; now it's a success-with-note (the NWC preimage proves payment). Receipt lookup now queries the reliably-indexed #e/#a/#p tags (not the unindexed #bolt11) and polls a few times for a late receipt. See docs/zap-audit-plan.md.
• Platform-fee fallback verified no-bypass — junk override falls back to the configured fee, not 0.
• CORS / LNURL — DECIDED 2026-06-24: accept graceful degradation, no proxy. Keep the visual zappability flag (walletZappabilityCheck / lnurl-unreachable) as the honest fallback when a recipient's LNURL host sends no CORS headers. Rationale: - Browser-enforced CORS can't be bypassed from page JS; the only universal fix is a proxy, which breaks the static/no-custody rule AND adds a real security surface (the proxy can swap the returned bolt11 → steal the zap unless it verifies description_hash). Not worth it for a static app. - The fee/receipt model is fundamentally incompatible with a CORS-blocked recipient in a static client: the platform-fee split needs to fetch the creator's invoice in-page, which is exactly what CORS blocks. - WebLN was evaluated and rejected: its only CORS-bypassing primitive (webln.lnurl()) pays directly — no NIP-57 receipt, no split, no deterministic amount — so it degrades a zap into an unattributed tip and bypasses the platform fee. Not acceptable as a silent fallback. Net: the current behavior is the right answer for a static, no-custody client.
• Remaining audit items — DONE 2026-06-24. #3 fully closed. - Split correctness (js/payments/zapSplit.js): platformShare = floor(amount*fee/100), creatorShare = amount - platformShare — the creator always gets the remainder, so no sats are lost or invented; a sub-1-sat fee rounds to 0 and the whole zap goes to the creator (no zero-amount platform send). Fee is clampPercent-bounded to 0–100 and a junk override falls back to the configured default (can't be bypassed or swallow the zap). Fixed the creator==platform edge: when the platform fee would pay the same Lightning address as the creator, the split now collapses to a single full-amount payment (was sending two invoices to one wallet → extra routing fee + duplicate receipt). Cheat-resistant tests added in tests/zap-split.test.mjs (testCreatorEqualsPlatformCollapsesToOnePayment, testSplitRoundingPreservesEverySat). - "Fee landed in my own wallet" — NOT a bug (expected): occurs when the sender is the platform operator (the platform fee correctly returns to them) or on a self-zap (you get your own creator share back). The fee recipient is always the configured platform address, never the sender's. - Receipt validation (9735): already fixed 2026-06-23 (author + bolt11 + description-hash match, with polling for late receipts); confirmed green (tests/zap-receipt-pool.test.mjs, validator tests in zap-split). - NWC budget/retry UX: already actionable — detects budget-exhausted, shows "Increase your wallet zap limit or reduce the platform fee, then retry…" plus the remaining-share summary and a Retry button. - General clunkiness: maintainer confirms the flow is working well; closed as accepted.
• Comment box confirmed WORKING (the "message doesn't work" was the popover mis-position making it hard to use — see 3a).

4. View counter accuracy & reliability — DEEP AUDIT — DONE 2026-06-24

Audit finding (2026-06-24): counts INFLATE. viewCounter.js dedupes locally by (viewer, time-window) correctly, but two things defeated it: (a) generateViewEventDedupeTag built the kind-30079 d tag with random entropy + exact timestamp, so every view was a UNIQUE event and relays could not dedupe the parameterized-replaceable event; (b) exactCountForPointer runs a NIP-45 COUNT (raw event count, no per-viewer dedupe) and bumped the displayed total UP to it (max(deduped, raw)). Net: reloads / multi-device / re-watches each added a view.

• Root fix — deterministic, window-bucketed d tag (viewEvents.js): scope:viewer:bucket, no entropy. Kind-30079 view events are now genuinely replaceable, so relays collapse a viewer's repeat views in a window into ONE event → the NIP-45 COUNT is accurate AND scalable, and max(deduped, raw) stops inflating. buildViewEvent no longer invents a random d tag (nostrEventSchemas.js). Transition: pre-existing entropy events age out over VIEW_COUNT_BACKFILL_MAX_DAYS. Tests: tests/view-event-dedupe.test.mjs (same-window dedupe, next-window separate, per-viewer/per-video, no auto-d).
• tests/view-counter.test.mjs un-quarantined + green. Triaged the whole monolith: pinned the legacy hydrate/subscribe path (the batched SubscriptionManager added later silently shadowed the mocks), made the dedupe-window test bucket-aligned (was flaky on time-of-day), and corrected the hydrateVideoHistory root-timestamp assertions to the refactored unit boundary (map vs the syncActiveVideoRootTimestamp field step). Removed from the QUARANTINE map. Spec corrections logged in TEST_INTEGRITY.md (SCN-view-counter-legacy-path, SCN-hydrate-root-timestamp).
• Cross-relay UNDER-count fixed (2026-06-24). The "exact" path (watch page + popularity chart) relied on the NIP-45 COUNT, but countEventsAcrossRelays returns bestEstimate = the SINGLE relay with the most events — it can't union across relays, so it under-counts when views are spread across relays (e.g. card showed 19 while the chart's uncapped list union showed ~63). exactCountForPointer now lists view events across ALL relays (uncapped, one on-demand list — not a storm) and folds the UNION into the deduped dedupeBuckets (one per viewer-window); total = the set size, so it's accurate AND monotonic (never spuriously decreases). Per-relay COUNT is kept only as a lower-bound floor when the list truncates (>2000), flagged partial. The popularity modal now passes { exact: true }, and since the count flows through the shared pointer state, opening a video corrects its count everywhere (grid cards converge). Test: testExactCountUnionsAcrossRelays in tests/view-counter.test.mjs. NOTE: grid cards (no exact) still use the §17-capped batched backfill (approximate, storm-safe) until the video is opened — acceptable accuracy/cost tradeoff.
• reactionCounter.js (likes/kind-7) audited — accurate, no fix needed. It does NOT use NIP-45 COUNT; it lists kind-7 events and dedupes via applyReactionToState keyed by pubkey (one reaction per user, latest-wins), with per-content totals. No raw-count inflation. (Kind-7 isn't replaceable, so listing+dedupe is the only accurate model; the only limit is the hydration cap for viral content — undercount, not inflate — a future scalability nicety.) Underpins the popularity chart (#26) / Trending (#27).

5. Card-hide / video-liveness check — full plan in docs/video-liveness-plan.md

Audited (2026-06-23). Finding: the hide/show policy is already correct (cardSourceVisibility.js hides only when neither CDN nor WebTorrent is healthy; un-hides when WebTorrent flips green). The real gaps:

• Speed (URL_PROBE_TIMEOUT_MS 8s → 4s): dead hosts yield a fast verdict so unplayable cards hide quickly. WebTorrent probe stays generous (swarm).
• Probe accuracy: confirmed the card probe already uses the video-element probe (confirmPlayable:true, actually loads media) — accurate, not the opaque HEAD. No change needed.
• Multi-source: ingest adapter exposes sources (all video imeta urls; collectVideoSources); urlHealthController.probeUrlList probes them in order — healthy as soon as one plays, offline only if all fail. So a dead primary host no longer hides a video with a working mirror.
• Player fail-over at play time (2026-06-24). Playback now tries each hosted source in turn before dropping to P2P. The PlaybackSession builds an ordered, de-duped hostedSourceCandidates (primary URL first, then the video's imeta sources); attemptHostedPlayback takes a candidateUrl and the url-first execution loop advances to the next mirror on probe-fail/stall/ timeout (cleaning up watchdogs + resetting the element between candidates), only calling WebTorrent after all hosted mirrors fail. sources plumbed coordinator → strategy → session; single-source videos behave exactly as before. Tests: tests/services/playbackService_multisource.test.mjs (candidate construction; the full async fail-over flow is covered by the playbackService_order suite in CI). ROLLBACK: revert the loop in playbackService.js to the single attemptHostedPlayback() call + drop the sources plumbing.
• Made the policy config-driven for live A/B testing (2026-06-24). New CARD_LIVENESS_POLICY (config/instance-config.js): show-pending (default, unchanged) | hide-foreign (foreign/ingested hidden until a source verifies; native stays show-pending) | hide-all. Owner's own cards always visible. Flip it live without a rebuild: window.__BITVID_CARD_LIVENESS_POLICY__ = "hide-foreign" then refresh/scroll. Implemented via a data-foreign provenance flag on the card + getCardLivenessPolicy() in cardSourceVisibility.js. Tests: three policy scenarios in tests/video-card-source-visibility.test.mjs (also un-broke 3 pre-existing VideoCard tests by adding the missing IntersectionObserver JSDOM stub).
• Probe speed — prefetch ahead of scroll (2026-06-24). Both liveness probes were already viewport-gated (IntersectionObserver, on-screen-first, WebTorrent priority-queued + concurrency-capped). Added a configurable LIVENESS_PROBE_PREFETCH_MARGIN (default 600px) applied to both observers' rootMargin, so cards just below the fold verify before the user scrolls to them — makes hide-until-verified feel instant. Override: window.__BITVID_LIVENESS_PREFETCH_MARGIN__.
• Deadlock fixed (2026-06-24). First hide-foreign test made ALL foreign/ NIP-71 content vanish: a hide-until-verified card starts display:none, which has no layout box, so the IntersectionObserver never fires for it → its liveness probe never runs → it never gets a healthy verdict → hidden forever. Fix: cardNeedsEagerLivenessProbe() + eager-probe such cards on onCardRegister (fires regardless of visibility) in both gridHealth and urlHealthObserver, instead of waiting for an intersection that can't happen. Still concurrency-capped/priority-ordered; show-pending unchanged. Default is now hide-foreign.
• DECIDE after live A/B: confirm hide-foreign feels right (foreign cards now verify-then-appear); else flip CARD_LIVENESS_POLICY in instance-config.

18. Embed button / modal on the video player does not open — FIXED 2026-06-23

• Root cause: event-name mismatch. VideoModal.handleEmbedRequest dispatched "action:embed", but ModalManager listens for "video:embed" (which opens EmbedVideoModal), and dispatch() does not remap names — so the embed button fired an event into the void. (Share survives the same mismatch only because shareBtn also toggles a popover directly.) Now dispatches "video:embed". Regression test in tests/video-modal-zap.test.mjs.
• Sibling bug FIXED (2026-06-23): handleCopyRequest had the SAME mismatch — dispatched "action:copy" with no listener (manager listens for "video:copy-magnet" → app.handleCopyMagnet), and #copyMagnetBtn has no popover fallback, so the standalone copy-magnet button was also dead. Now dispatches "video:copy-magnet". Covered by the same regression test.

19. Direct messages: can read but cannot SEND — FIXED 2026-06-23

• Root cause: missing controller delegations. Clicking Send threw this.controller.handleDmAppShellSendMessage is not a function. The DM app-shell renderer wires its callbacks on this.controller (the ProfileDirectMessageController), but the controller was missing the delegation methods that forward to this.actions — so Send AND mark-read, mark-all-read, read-receipts/typing toggles, and open-settings all threw and did nothing. Added the six delegations. The send path itself (encrypt → sign → publish, NIP-04 default / NIP-17) was fine. Regression test tests/dm-controller-delegations.test.mjs. VERIFY live: typing + Send actually delivers a message.
• Follow-up: "Message" button targeted the wrong person. Clicking Message on a profile (or anyone you'd never DMed) set the recipient, but buildDmConversationData discarded it — a recipient with no existing thread wasn't in conversationMap, so it fell back to conversations[0] (the top conversation). The inbox silently jumped to the top thread and any message sent went to THAT person ("says sent but I don't see it"). Fixes: (a) setDirectMessageRecipient now focuses the selected recipient's conversation; (b) buildDmConversationData synthesizes an empty conversation for a selected-but-threadless recipient and honors it as active (incl. activeRemotePubkey fallback for the composer target); (c) the legacy renderProfileMessages list no longer clobbers a non-null recipient. Regression: tests/ui/dm-conversation-focus.test.mjs. VERIFY live: Message a brand-new person, confirm the thread opens on THEM and the sent message lands in that conversation after refresh.

20. Feed / grid loading reliability — some videos missing (BUG) — FIXED (streaming/first-relay-wins render is a separate latency follow-up under #17d)

Two related intermittent symptoms; likely the same root cause (a one-shot, all-relays-settle fetch that drops slow-relay results — see 17d).

• Profile / Channel page sometimes doesn't pull in all of a creator's videos. Root cause: loadUserVideos rendered ONLY the live fetch, which REPLACES the grid — so when a relay holding a video transiently failed this load, that video vanished even though it was known in memory/cache. Fixed by unioning the live events with already-known events (mergeChannelVideoSources, live-wins-on-id) before render, so the grid is a superset and never shrinks; existing dedupe-by-root + access checks still handle versioning/deletes. Regression: tests/channel-video-merge.test.mjs. (Streaming/first-relay-wins UX is still the 17d follow-up.)
• "Paginating between pages" was tab-switching: videos present in one feed tab missing in another. Root cause shared with #21: all general tabs read the SAME active set and only re-ranked, and the rankers never dropped — so tabs were near-identical and any apparent "missing" was the lack of a distinct identity. Addressed by giving each tab a real identity (see #21).
• Remaining: streaming/first-relay-wins incremental render (17d UX) is still open as a latency follow-up, not a correctness bug.

21. "For You" / Explore / Recent: make each a genuinely distinct feed — DONE

Root cause: RECENT, FOR_YOU, EXPLORE all sourced the full active set and only re-ranked (and the rankers never drop), so with thin signals they all collapsed toward freshness and looked identical. Gave each a structural identity:

• For You = "your people first" (4873a431): the scorer tags forYouTier (2 followed author / 1 interest·watch match / 0 other) and the sorter leads with tier regardless of raw score, then score within tier; watched already suppressed. No-signal (logged-out / no follows) falls back to an author-interleaved discovery order so it never mirrors Recent. Tests: tests/for-you-tiering.test.mjs.
• Explore = "new-to-you + diverse, less recency" (087cf410): freshness weight down (0.25→0.12), novelty up (0.30→0.35), a soft followed-author penalty (reads subscriptionAuthors in the Explore runtime) so non-followed creators surface, and more variety via the diversity sorter (MMR λ 0.7→0.5). Test: explore follows-penalty in tests/feed-engine/explore-scorer.test.mjs.
• Recent = chronological (unchanged).
• Render bug that masked ALL of the above (2026-06-24): VideoListView.render re-sorted the grid by date unless metadata.preserveOrder was set, and only Explore set it — so For You's tiering and Kids' scoring were discarded at render and shown chronologically (looking identical to Recent). Fixed by setting preserveOrder for For You / Trending / Kids in the refreshFeed cases. This is why the feed-identity work "didn't show" until now.
• Follow-up (optional): Explore per-VIDEO "already watched" suppression (currently only topic-novelty, not per-video) — needs the watch-history preload wired into the Explore refresh like For You has. And a Trending tab (popularity) once view-count/zap data is reliable.

Open — medium priority

6. Test S3 (generic, non-R2) functions — DONE 2026-06-24

• Audited; was more covered than it looked. Already tested: upload/thumbnail/ .torrent (s3UploadService.test.mjs, s3-upload-*), CORS guidance (s3-upload-cors-guidance.test.mjs), and delete/edit cleanup provider-aware path-style — incl. the documented vhost bug (r2-delete-video-storage.test.mjs asserts cleanup uses forcePathStyle:false for generic S3; s3-upload-publish-cleanup-integration.test.mjs covers the full upload→delete round-trip). forcePathStyle is plumbed through upload + delete.
• Closed the real gap: public-URL resolution. The upload tests mock buildS3ObjectUrl, so the actual path-style/vhost URL logic in js/storage/ s3-url.js had no focused test. Added tests/storage/s3-url.test.mjs (11 pure- function scenarios): path-style → bucket in PATH; vhost → bucket as host subdomain (no double-prefix); endpoint path-prefix preserved; bare-endpoint https upgrade; key/slash normalization; explicit publicBaseUrl wins; missing inputs → "". Also covers s3Service.derivePublicBaseUrl/buildS3ObjectUrl.
• [~] Provider forcePathStyle DEFAULTS (generic→path-style true, aws→vhost false) are a 3-line internal config map (resolveForcePathStyle/PROVIDER_TESTS, not exported); not unit-tested in isolation (would require exposing internals). Behavior is exercised via the upload/delete tests above. Acceptable minor gap.

7. Mobile + video-card layout

• Improve mobile layout and the video card layout.
• Improve mobile UI broadly (reiterated 2026-06-25) — not just the card: nav/ sidebar, modals, the player, forms, and touch targets across the app.
  • Profile modal tabs → app-grid on mobile (2026-06-25). Below 1024px (the full-width menu view), the profile modal's tab nav (.profile-modal__nav: Account/Relays/Wallet/Storage/…) renders as a 3-column grid of icon tiles with the title centered below each icon, instead of the vertical list. Desktop keeps the vertical nav. Token-only; validated live in-browser. css/tailwind.source.css. (NOTE: the sidebar is NOT a grid — an earlier sidebar version was a misread and was reverted.)
• Consider removing the CDN/WebTorrent source badge from the card (clutter).
• Run npm run test:visual after layout changes; update baselines deliberately.

41. Native browser dialogs → site notification system — DONE 2026-06-30

• DONE 2026-06-30. Replaced every alert()/confirm() (no prompt() existed) with the app's notification system so dialogs are styled + consistent. - alert() (13) → toasts: this.showError where the component already had it (UploadModal), else notifyError/notifySuccess via a new js/ui/appNotify.js (routes to the app's NotificationController). - confirm() (~13) → a new promise-based showConfirm() dialog (js/ui/confirmDialog.js) — a bv-modal modal-always-on-top overlay returning Promise<boolean> (Confirm/Cancel/backdrop/Escape, danger variant focuses Cancel). Importable anywhere, so future confirmations use it too. Stacks above other modals and is typable thanks to the stacked-modal focus fix. - Migrated: UploadModal, MyVideosController, ProfileStorage/Wallet/Relay controllers, profileModalController, subscriptionHistoryController, settingsRestorePrompt (default confirm now showConfirm), nostr/client (deleteAllVersions). confirmSyncOverwrite helpers made async (the sync layer already awaits confirmOverwrite). Tests: tests/confirm-dialog.test.mjs (6). Build + lint clean; affected suites green. NOTE: npm run build/lint do NOT parse JS — verify migrations by importing the module / running its test.

42. Admin whitelist edit fails with nsec / NIP-46 (only NIP-07 worked) — FIXED

• DONE 2026-06-30. Editing the admin whitelist/blacklist worked with a NIP-07 extension but silently failed with nsec and NIP-46 (Amber). Root cause: adminListStore.persistNostrState signed with window.nostr.signEvent directly (and required requestDefaultExtensionPermissions), so non-extension logins threw "nostr-extension-missing". Fix: sign with the active signer (getActiveSigner() from the registry — works for extension/nsec/NIP-46, all expose signEvent), and only run the extension-permission prompt when the signer is an extension (type === "extension"/"nip07"). Regression test added to tests/admin-list-store.test.mjs (nsec signer used while window.nostr.signEvent throws). Build + lint clean.
• AUDIT DONE 2026-06-30 — clean (adminListStore was the only bug). Swept every .signEvent(, window.nostr, and ensureExtensionPermissions/ requestDefaultExtensionPermissions caller: - Signing: NO window.nostr is used to sign/encrypt anywhere. Every publish path signs with the active signer (signer.signEvent): subscriptions, userBlocks, hashtag prefs, relay prefs, moderationService reports, nip71MirrorService, encryptedSyncFacade, DM seal + legacy DM (nostr/client signingAdapter defaults to the active signer), DM relay list, admin lists. - Extension-permission gates: every caller (reactions, comments, subscriptions, userBlocks, watchHistory, relayManager, DM relays) guards the request behind a signer-type (extension/nip07) or capability check, so nsec/NIP-46 skip it and go straight to active-signer signing — they never hit the extension-missing failure that broke admin lists. - Decrypt: gates on the active signer's nip04/nip44 capability with window.nostr only as a fallback; nsec (closures) + NIP-46 (remote) both decrypt fine. - Cleanup note (low priority): js/auth/signingAdapter.js (createNip07SigningAdapter, defaults to window.nostr) is dead production code — referenced only by its own test, no app callers. Harmless; remove or repoint at the active signer if ever reused.

43. Logged-in profile card at the top of the profile modal (UX)

• DONE 2026-07-03. An "Acting as " identity pill now renders top-center on EVERY pane, straddling the header divider (negative block-start margin — the modal is full-screen, so the header edge is the overlap surface). Avatar + name come from the same resolveMeta path as the Account pane card (profile cache first), populated in renderSavedProfiles so it refreshes on every profile switch; hidden when logged out; clicking it jumps to the Account pane. Markup in components/profile-modal.html, styles in css/tailwind.source.css (.profile-modal__identity*), wiring in profileModalController. Test in tests/profile-modal-controller.test.mjs (26 pass). Lint + build green.
• VERIFY on unstable: open any pane → pill shows the active identity; switch accounts → it updates; log out → it disappears; click → Account.

44. In-modal storage selector for uploads (UX)

• DONE 2026-07-03. The upload modal's storage summary now has an "Upload destination" (hidden with <2 connections) listing every configured connection ("Provider — bucket", default labelled). Selecting one becomes the upload target for THIS modal (per-modal override; the account default is untouched — set that in Profile → Storage) and loadFromStorage re-resolves summary + credentials immediately. A stale selection (connection deleted) falls back to the default. Inline unlock was already covered by #56's gate. Logic in uploadModalStorageUnlock.js (pickTargetConnection/renderConnectionPicker, UploadModal file-size budget). Tests: tests/upload-storage-picker.test.mjs (2 scenarios). Lint + build green.
VERIFY on unstable: with 2+ connections configured, open Upload → Storage Status → switch destination → summary updates and the upload lands in the chosen bucket; with 1 connection the picker stays hidden.

45. Upload modal: suggest tags from the user's previous videos (UX) — DONE 2026-07-01

• DONE 2026-07-01. The Hashtags section of the upload modal now shows one-tap chips of the user's most-used past hashtags ("Reuse a tag from your videos:"). Source: app.getUserHashtagSuggestions() reads the user's own videos (nostrService.getActiveVideosByAuthors([pubkey])) and ranks their hashtags via js/utils/hashtagSuggestions.js rankHashtagsByFrequency — count = number of videos using each tag, normalized (case + #) and deduped per video, ties broken alphabetically (top 12). Tags come from video.nip71.hashtags (falls back to raw t tags minus bitvid's fixed t=video marker). Clicking a chip adds it to the NIP-71 t repeater (skips duplicates); already-added chips dim + disable. Hidden for users with no past tags. Rendered on modal open. Tests: tests/hashtag-suggestions.test.mjs (5, pure ranking). Lint + build green.

46. Feed auto-refreshes after posting a video (UX) — DONE 2026-06-30

• DONE 2026-06-30. publishVideoNote now (1) optimistically injects the just-published legacy event into the shared client cache via a new nostrClient.ingestLocalVideoEvent(rawEvent) (+ thin nostrService wrapper), so the new video shows in the feed instantly, before the relays echo it back; and (2) refreshes via the canonical refreshAllVideoGrids({ reason: "video-published", forceMainReload: true }) instead of a bare loadVideos() — so it refreshes whichever feed is active (For You / Explore / Recent) plus the subscription and channel grids, and forces a render (bypassing the load cooldown) so the injected video is actually shown. ingestLocalVideoEvent mirrors live ingestion (convert → root created_at → tombstone guard → allEvents/activeMap), so it obeys the same dedupe/active-key rules (#20/#21): a later relay copy of the same event (same created_at) won't duplicate it, and an older revision can't overwrite a newer active entry. Tests: tests/optimistic-feed-insert.test.mjs (6 — surfaced instantly, no-duplicate on re-ingest, newer-wins, older-doesn't-clobber, invalid→null, garbage handled).

47. "Most Zapped" sidebar tab (trending-by-zaps)

• NEXT (planned, not started): bitvid-native zap tally. Full spec + ordered task checklist in docs/zap-tally-plan.md. Problem: NIP-57 zap receipts (9735) are published by the RECIPIENT's LNURL server, and custodial wallets (Strike) don't — so paid zaps leave no on-relay record and can't be counted globally. Fix: bitvid publishes a payer-signed, preimage-verified zap event on successful send (as strong as a 9735 via the preimage→payment_hash + description_hash→zapRequest binding, reusing the existing bolt11 decode in zapReceiptValidator.js), counted alongside real 9735s (deduped by payment_hash, 9735-preferred). Behind FEATURE_ZAP_TALLY (default off). Plan also covers a SECOND orange zaps-over-time line on the per-video Popularity chart with a legend (red=Views/orange=Zaps) and visible date labels (docs §5.9). See the plan for the file-by-file changes. Current state (commit cbc62306): 9735 counting + optimistic bump + durable local ledger (bitvid:sentZaps:v1) already shipped; the tally is the missing global/cross-user source.
• DONE 2026-07-03. Full Trending-pattern clone ranked by SATS: - js/zapTotals.js — per-pointer kind-9735 aggregation. The feed's getZapTotal reads the cached total AND schedules a BATCHED one-shot receipt fetch (#a/#e chunks via the L1 SubscriptionManager — the direct-pool lint gate applies) for unknown/stale pointers (2-min TTL; zero-receipt answers cached too). Amounts: nip57 bolt11 parse, falling back to the zap request's amount tag (msats); receipts deduped by id so re-fetches never double-count. - Feed: js/feedEngine/mostZappedFeed.js + createMostZappedSorter (sorters.js refactored to a shared count-ranked sorter — Trending behavior unchanged: sats/views desc, recency tie-break, author spread, trusted-muted sink). - View: views/most-zapped.html + js/mostZappedView.js (re-runs the feed on zapTotals' change signal, same settle-in pattern), sidebar link, viewManager registry, feedCoordinator case/loader, FEED_TYPES.MOST_ZAPPED, FEATURE_MOST_ZAPPED_FEED flag (default on; off hides the tab like Trending's flag). Tests: tests/zap-totals.test.mjs (5). Lint + build green.
• Follow-up DONE 2026-07-03 — per-card zap badges. Video cards now show the zap total in bitcoin ORANGE (new --color-zap token, both themes), RIGHT-ALIGNED in the engagement row (views/comments stay left; CSS margin-inline-start: auto on .video-card__zaps). Hidden until a nonzero total is known (no "0 sats" noise). Binder (js/ui/views/videoCardZapTotals.js, VideoListView file-size budget) fills [data-zap-total] from the shared zapTotals cache — bind() also schedules the batched receipt fetch, and one change listener updates every bound card as batches land. Test: tests/video-card-zap-totals.test.mjs (drives the REAL store).
• VERIFY on unstable: open Most Zapped → zapped videos rise as receipts load (unzapped feed reads as Recent at first) and their cards show the orange right-aligned sats badge; unzapped cards show no badge; zap a video → within ~2min of tab re-entry its rank + badge reflect the new total.

48. Fluent profile switching across signing methods (nsec / NIP-46 / NIP-07) — DONE 2026-06-30

• nsec switching FIXED 2026-06-30. Switching to a saved nsec profile used to fail silently ("secret-required") — switchProfile called the nsec provider with no passphrase and never prompted. Now handleProfileSwitchRequest detects an nsec target, checks the stored key (getStoredSessionActorMetadata + evaluateStoredNsecSwitch — must be a persisted nsec for THIS account), prompts for the PIN/passphrase via a new showPasswordPrompt dialog (js/ui/promptDialog.js), and calls switchProfile(pubkey, { unlockStored: true, passphrase }). authService.switchProfile now forwards unlockStored/passphrase → requestLogin → the nsec provider's unlockStoredSessionActor restores the signer and activates the account. Wrong PIN → "Incorrect PIN/passphrase" toast; no stored key / different account → a clear "log in with its nsec" toast. So you can switch NIP-07 → nsec fluently. Tests: tests/stored-nsec-switch.test.mjs (6, pure gate) + tests/password-prompt.test.mjs (6, dialog). Build + lint clean; auth suites 25/25.
• NIP-46 switching FIXED 2026-06-30. Confirmed the same bug: switching to a saved NIP-46 account called the provider with no reuseStored, so it started a fresh handshake (needing a new connect URI/QR) instead of reconnecting. Now handleProfileSwitchRequest sends { providerId: "nip46", reuseStored: true } for NIP-46 targets → switchProfile forwards reuseStored → the nip46 provider's useStoredRemoteSigner reconnects the stored session and activates the account. On failure → "Couldn't reconnect to this account's remote signer" toast.
• Wrong-account guard (all methods) 2026-06-30. requestLogin now enforces expectPubkey (only set by switchProfile): if a single-slot stored session resolves to a DIFFERENT account than requested, it rejects with pubkey-mismatch instead of silently switching to the wrong profile. Also protects NIP-07 (switching to an account the extension isn't currently on now fails clearly instead of grabbing the extension's active account). Tests in tests/authService.test.mjs (option forwarding + expectPubkey rejection).
• Multiple nsec accounts — DONE 2026-06-30. The encrypted-key store is now per-pubkey (bitvid:sessionActors:v2 = { [pubkeyLower]: { privateKeyEncrypted, encryption, createdAt } }), following the existing bitvid:<thing>:<npub> convention (profileCache, nwcSettings, …). Several saved nsec accounts each keep their own key on the device, so the switcher can move between them. The legacy v1 single slot is kept in sync as the "last-saved default" (boot restore / no-arg reads) and is migrated into the map on first read. readStoredSessionActorEntry, getStoredSessionActorMetadata, and unlockStoredSessionActor all take an optional target pubkey; the nsec provider threads expectPubkey through so a switch unlocks the requested account (not the last-saved one), with the expectPubkey guard as a backstop. IndexedDB mirror is now keyed per-pubkey too. Added listStoredSessionActorPubkeys(). Tests: tests/session-actor-multi-account.test.mjs (7 — per-account resolve, list, clear-one-keeps-others, no-arg default, no-arg wipe, v1→v2 migration, missing-account returns null).
• Multiple NIP-46 accounts — DONE 2026-06-30. The remote-signer session store is now per-user-pubkey (bitvid:nip46:sessions:v2 = { [userPubkeyLower]: session }), mirroring the nsec store. Several saved NIP-46 accounts each keep their own reconnectable session, so the switcher can move between them. The legacy v1 single slot is kept in sync as the last-connected default (boot restore) and migrated into the map on first read. readStoredNip46Session and getStoredNip46Metadata take an optional target pubkey; writeStoredNip46SessionSync writes both the map (keyed by userPubkey) and the v1 default; clearStoredNip46Session(pubkey) forgets one account (no-arg wipes all, for logout). SignerManager.useStoredRemoteSigner({ pubkey }) selects the target account's session and, on access-denial, forgets only that account; the nsec/nip46 providers thread expectPubkey through so a switch reconnects the requested account (with the expectPubkey guard as a backstop). Added listStoredNip46SessionPubkeys(). (nip46Connector.js is dead code — the live path is entirely in SignerManager.) Tests: tests/nip46-multi-account.test.mjs (7).

8. Orphan storage garbage-collection tool

• Largely delivered by the My Videos tab (9d3a0df0): lists bucket objects no live note references and offers per-file delete (under the user's prefix only).
• Bulk "Delete all" orphans — DONE 2026-06-30. Added a "Delete all (N)" button to the orphaned-objects header in My Videos (shown only when >1 orphan). One confirmation → a single deleteStorageKeys({ keys: allOrphans, pubkey }) call (already array-capable + unlock-gated + prefix-scoped). Refreshes the list on success and reports partial outcomes honestly ("Removed 2 files (1 could not be deleted)"); surfaces storage-locked as an unlock prompt. Tests: tests/my-videos-bulk-orphan-delete.test.mjs (5 — all-keys-in-one-call, cancel, storage-locked, partial, empty no-op). Build + lint clean; My Videos suite 37/37.
• Remaining (optional): surface the same orphan control from the Storage settings pane (currently only in My Videos).

9. Cap the cold-login relay-REQ storm further

• Biggest source fixed (a8e9f520): the community-blacklist load fired one kind-30000 REQ per curator (~28-32 parallel) at cold start. Collapsed into a single batched multi-author REQ (js/adminListBatch.js), routed through the subscription manager. This was the dominant kind 30000 storm.
• VERIFY the batching actually reduced it. A later logged-OUT load (2026-06-23 00:45) STILL showed kind 30000=32 — either that build wasn't loaded, or there's ANOTHER kind-30000 source besides loadCommunityBlacklistEntries (admin editor/whitelist/blacklist lists? a per-author follow-set fetch?). Re-check on a fresh hard-refresh; if still ~32, trace the actual emitter.
• from_hex root-caused + FIXED (2026-06-23). The sanitizer (HEX64_FILTER_FIELDS, toolkit.js) covered ids/authors/#e/#p/#q but NOT the NIP-22 UPPERCASE root tags #E/#P, which relays also hex-decode and which the kind-1111 comment subscriptions (commentEvents.js) query by. An odd-length root event-id/author there bypassed the sanitizer and got the whole REQ rejected ("uneven size input to from_hex"). Added #E/#P to the sanitized fields; test in tests/filter-hex-sanitize.test.mjs.
• Relay from_hex REQ rejects fixed (733cb593): one odd-length/non-hex value in ids/authors/#e/#p/#q made strict relays reject a whole REQ; now sanitized at the pool choke point (normalizeFilterList).
• Remaining: logged-IN cold-start WoT/social-graph fan-out (~94-104 REQ/s, bracketed by [lists-sync-start]…[lists-sync-complete]). Logged-OUT is now clean. The spike is per-contact hydration over the user's ~25 follows/trusted contacts: kind 30000 (follow sets), 30002 (block lists), 30005/30015 (interest sets), 10050 (DM relay hints), plus 0 (profiles). NOTE: mutes (kind 10000) are ALREADY batched (moderationService.refreshTrustedMuteSubscriptions, one multi-author filter). Fix = apply the same multi-author batching to the other per-contact fetches (userBlocks 30002, hashtagPreferences 30005/30015, follow-set/contacts hydration 30000, DM 10050) and/or DEFER non-feed-critical ones (DM relays, interest sets) until after first render. Multi-subsystem + sensitive (trust) → do as a dedicated perf pass, not a rushed change. Source still to pin: the loop issuing 30000/30002/30005/30015 per contact.
• REQ tracer SHIPPED (2026-07-03) to pin those emitters empirically — static search found NO per-contact list loops (mutes already batched), so the hypothesis needs data. js/nostr/reqTelemetry.js hooks the shimmed pool.sub choke point (every sub/list flows through it) and aggregates kinds + relay fan-out + emitting call site per 10s window. Zero-cost off. To trace: on unstable run localStorage.setItem("bitvid:reqTrace","1"), reload (cold login), read the [req-trace] console logs (or window.__bitvidReqTrace.report()); the top rows name the emitters and the batching/deferral pass follows directly from that data.

22. Anti-spam: validate npub on application / submission forms

• DONE 2026-06-24. Added a shared, testable NIP-19 validator (js/utils/validateNpub.js, exposes window.validateNpubHex) and wired it into all four embed submission forms (components/iframe_forms/): - Application (applicantNpub, required): submit is blocked unless the npub decodes to a 64-char hex pubkey; the hex is also written into the application body for canonical storage/whitelist matching. - Feature-request / bug-fix / feedback (userNpub, optional): the npub stays optional, but a non-empty value must be a valid npub or submit is blocked with a clear inline error. Validation decodes via the real nostr-tools nip19 (checksum + prefix + hex shape), so spam/free-text/note1…/tampered npubs are rejected. Unit tests: tests/validate-npub.test.mjs (real nostr-tools). Pairs with #23 (submissions should become structured data, not DMs).
• VERIFY live: open each form embed — application rejects a junk npub and only sends with a valid npub1…; the optional forms send when the npub is blank but reject a malformed one.

23. Admin submissions tab — structured submissions + approve/deny UI (SCALING)

• Replace the current DM-based submission flow with custom structured data (a dedicated Nostr event kind / addressable record, or app data) instead of free-form DMs, so submissions are parseable and actionable.
• Add an Admin → Submissions tab with a nicely formatted UI: each submission rendered with its fields and an Approve / Deny action that applies the corresponding change (add to whitelist, add to blacklist, etc.) without manual list-editing. This is foundational for scaling moderation as the platform grows.
• Define the submission schema + the admin action → list-mutation mapping; reuse the existing admin list stores (whitelist/blacklist) for the writes.

24. User-level allowlist override for the Web-of-Trust mute list — CORE DONE 2026-07-08

• Core render-time allow-override — DONE 2026-07-08. A per-author (per-npub) override that ALWAYS shows a creator's content, overriding the inherited WoT/trusted-mute warning (blur/hide) for every one of that author's videos until reset. Stored in a dedicated cache (bitvid:moderationAuthorOverrides:v1, js/state/cache.js) and applied as the final allow-override at the single render-time integration point (js/services/moderationDecorator.js — sets overrideActive when getAuthorModerationOverride(pubkey).showAnyway). Two entry points: (a) the Safety tab "Trusted creators" npub input + list with per-row Reset (ProfileModerationController), and (b) an "Always show creator" button on every blurred/warned surface (VideoCard, VideoModal, SimilarContentCard) that dispatches a video:trust-author event handled once in applicationBootstrap.js. Tests: tests/author-moderation-override.test.mjs (5). Committed a0131c71 (Safety tab) + 5844a36a (overlay button).
• Remaining (deferred, not blocking launch): NIP-51 sync + import. The override is currently device-local (localStorage), not a published NIP-51 list, so it doesn't roam across devices and can't be imported/shared. Follow-up: persist as an encrypted/opt-in NIP-51 list and make it importable, reusing the cross-login sync machinery (#15).

25. Per-video / per-event admin block list (granular moderation) — DONE 2026-07-01

• DONE 2026-06-30 (full vertical slice). Admins (any editor — same gate as the author blacklist) can now hide a SINGLE video without blocking its author. - Record: a published kind-30000 NIP-51 list under d-tag bitvid:admin:event-blacklist, carrying blocked event ids as e tags (NOTE_TYPES.ADMIN_EVENT_BLACKLIST schema; participantTagName: "e"). Loaded/persisted through the existing admin-list machinery (adminListStore loadNostrState/persistNostrState) and cached like the others. - accessControl: eventBlacklist Set + getEventBlacklist()/ isEventBlacklisted()/addToEventBlacklist()/removeFromEventBlacklist() (editor-gated, normalizes hex or nevent/note) + onEventBlacklistChange. - Render filter: already existed (app.blacklistedEventIds, honored by every feed/grid/search/playback path) but was fed only by the static ADMIN_INITIAL_EVENT_BLACKLIST config. Now app._rebuildBlacklistedEventIds() merges that static base with the dynamic admin list, and an onEventBlacklistChange listener rebuilds + refreshes the grids on change. - UI: a "Block this video" item in the per-video ⋯ menu (editor-only, via videoMenuRenderers), handled by handleBlacklistEventAction (js/ui/moreMenu/blacklistEventAction.js). - Helpers extracted to js/adminEventBlacklistHelpers.js to keep adminListStore / accessControl / moreMenuController under their size caps. Tests: tests/admin-event-blacklist.test.mjs (9 — record helpers + editor-gated action, fallbacks, refusal, publish-failure). Build + lint clean; admin/access/moderation suites 56/56.
• Follow-up DONE 2026-07-01. The admin pane is now organized into a sub-tab toolbar (Whitelist / Blacklist / Blocked videos / Moderators — Moderators tab super-admin-only) and a Blocked videos tool surfaces the per-event list: view every blocked video (title+author when cached, else shortened id), unblock per row (confirm → removeFromEventBlacklist), and add by nevent/hex id. Reuses the existing accessControl event-blacklist API + onEventBlacklistChange (live re-render) and refreshes the grids on change; no backend changes. Row logic in js/ui/profileModal/blockedVideosSection.js; wiring in ProfileAdminController. Tests: tests/profile-blocked-videos.test.mjs (7) + updated profile-modal-controller admin test for the sub-tab layout.

26. Video popularity / view-count chart (public, three-dots menu) — DONE 2026-06-24

• Shipped. A "Popularity" item in the ⋯ menu opens a public views-over-time chart (js/viewCountChart.js). buildViewCountTimeSeries buckets the raw kind-30079 view events by the counter's dedupe window (one view per viewer per day) into a cumulative series; buildViewCountChartSvg renders a token-colored (currentColor/text-accent) SVG area+line — no chart lib. The modal fetches via listVideoViewEventsWithDefaultClient, shows the total, and updates live by subscribing to subscribeVideoViewEventsWithDefaultClient (debounced re-render); cleans up on close (Esc/backdrop/✕). Lazy-loaded from the menu handler. Tests: tests/view-count-chart.test.mjs. Built on the trustworthy #4 counts.
• FUTURE: feed the same data into a creator dashboard showing the creator their videos' ranking + performance over time (separate, larger effort).

27. "Trending" tab — recently-added sorted by view count — DONE 2026-06-24

• Shipped. New FEED_TYPES.TRENDING tab: the active (recently-added) source ranked by VIEW COUNT (recency tiebreak, trusted-muted last). Gated by FEATURE_TRENDING_FEED (default ON; flag-off hides the sidebar link and skips registration). Relies on the now-trustworthy view counts (#4). - createTrendingSorter (sorters.js) reads counts from the injected runtime.getViewCount, which resolves each video's pointer (the app's canonical deriveVideoPointerInfo) against the shared viewCounter cache — the same counts the grid cards already load. - Live re-rank: viewCounter now emits a coalesced onViewCountsChanged signal; while the Trending view is active it debounce-re-runs the feed (cheap re-rank over the in-memory active set, no relay re-fetch), so the order settles into true trending as counts stream in. Cold cache ⇒ reads as recency, then improves. - Pipeline extracted to js/feedEngine/trendingFeed.js (feedCoordinator is at its size cap); thin delegations + a getVideoViewCountSnapshot export. - Wiring: FEED_TYPES + flag, feedCoordinator load/refresh cases, app.js wrappers, applicationBootstrap registration, viewManager init + js/trendingView.js, views/trending.html, sidebar link. - Tests: tests/trending-sorter.test.mjs.
• FUTURE: benefits from the unified streaming grid (#17d); consider a time- windowed "trending" (views in the last N days) once view-over-time data (#26) lands, instead of all-time totals.

31. ⋯ menu "Event Details" button does nothing (BUG) — fix landed, VERIFY

The wiring is structurally intact (menu item event-details → handler case → handleEventDetailsAction → EventDetailsModal.open), so the failure was a SILENT one: handleEventDetailsAction only opened the modal if (… && payload .video) and never caught the async open() rejection, and open() ran the (throwable) renderVersion BEFORE actually showing the modal. Hardened:

• handleEventDetailsAction no longer fails silently — surfaces "No video selected" / "unavailable", falls back to app.eventDetailsModal, and .catch()es the open promise.
• EventDetailsModal.open now calls openStaticModal FIRST, then renders in a try/catch, so a render hiccup can't leave the click looking dead.
• The ⋯ popover is dismissed before opening the modal.
• Actual root cause (2nd live test): BOTH Event Details and Popularity reported "No video selected" from the video modal's ⋯ button. The modal trigger declares its context as data-more-dropdown="modal", but attachMoreMenuHandlers read only data-context → defaulted to "card" → skipped the modal-only video resolution → opened the popover with a null video, so the panel's data-event-id was empty and every action failed. The panel is built from entry.context.video, so this nulled the whole menu. Fixes (all in moreMenuController.js): 1. Read context from data-more-dropdown as well as data-context. 2. Modal branch falls back to this.videoModal.activeVideo when getCurrentVideo() is null (deep-link opens don't set playback's currentVideo). 3. Defense-in-depth: handleEventDetailsAction resolves the video from app.videosMap.get(eventId), and view-stats uses a new getVideoByEventId callback (dropping a risky || currentVideo). Regression tests added in tests/more-menu-controller.test.mjs.
• VERIFY live: click ⋯ → Event Details AND ⋯ → Popularity in the video modal AND on a grid/channel card; both should open the correct video.

32. Whitelisted author's video won't play — "not from a whitelisted author" (BUG)

Reported 2026-06-25: a video from a known-whitelisted author refused to play ("This content is not from a whitelisted author." at playbackCoordinator .playVideoByEventId). The source URL was confirmed 100% healthy (HTTP 200, video/mp4, range + CORS *) — the block is the whitelist gate, not the source.

• Root cause + fix: canAccess format asymmetry. accessControl keeps the whitelist in TWO sets — whitelistPubkeys (hex) and whitelist (npub) — and canAccess checked only ONE based on the caller's input format (npub→npub set, hex→hex set) without cross-deriving. playbackCoordinator passes the author's npub, so it consulted only the npub set; if the entry was present in only the hex set (e.g. the hex decode hadn't run / a normalization mismatch), a genuinely whitelisted author read as "not allowed." Fixed canAccess to cross-derive both forms and check BOTH sets (false-negatives only; a non-whitelisted author is still denied). Tests: tests/access-control-canaccess.test.mjs.
• Added a dev-gated diagnostic at the playback rejection (playbackCoordinator) logging hex/npub, whitelistMode, set sizes, and inNpubSet/inHexSet — so if it still denies, we know instantly whether the author is genuinely off the list (→ then it's the separate "ingested foreign content shown in a whitelist-mode feed but unplayable" question) vs a load race.
• VERIFY live: replay the failing nevent. If it plays → fixed. If it still denies, paste the new [playback] access denied — whitelist diagnostic line.

28. Beacon torrent app stuck — spinner never resolves (BUG) — FIXED 2026-06-24

• Root cause: the processing overlay (torrent/app.js) was gated on WebTorrent's metadata-ready callback (client.add(magnet, opts, cb) / client.seed). That callback only fires once metadata arrives from peers, so a magnet with no live seeders never resolved it and the spinner span forever — and a torrent that emits its own 'error' (bad/duplicate magnet) didn't always reach the client-level handler. (NOT the null.fill crash (#10); the client constructs fine — this was a missing timeout/failure path.)
• Fix: added a watchdog around the overlay. beginProcessing() arms a 30s PROCESSING_TIMEOUT_MS timer; if the op hasn't completed it drops the overlay and warns ("still searching for peers — it'll keep trying in the background") while the torrent stays in the table and keeps announcing. handleTorrentReady, the client error handler, and destroy() all clear the watchdog. addMagnet/seedFiles now wrap add/seed in try/catch and attach a per-torrent 'error' listener so bad magnets fail visibly.
• Tests: tests/torrent/beacon-watchdog.test.mjs (JSDOM) — a no-peers magnet drops the spinner + warns; a ready torrent resolves it and a stale watchdog can't re-fire.
• VERIFY live: open the beacon, paste a dead magnet → spinner should clear with a warning after ~30s instead of hanging; paste a live magnet → resolves.
• SEPARATE BUG — spinner-on-load, FIXED 2026-07-09. Reported: beacon.html "just shows a spinner." Root cause was NOT the watchdog (that's compiled into the bundle fine) but a CSS specificity trap from the data-ds="new" redesign: .ds-overlay-backdrop { display: flex } (an author rule) overrides the UA [hidden] { display: none }, so the processing overlay — hidden in the HTML — rendered on load as a full-screen backdrop covering the whole page. Fix: added .ds-overlay-backdrop[hidden] { display: none } (specificity 0,2,0 wins) in css/tailwind.source.css — same guard the video modal already uses (css ~2663). No JS needed; the JS inline-style toggle still works. Rebuilt CSS + dist. VERIFY live: beacon.html loads to the form (no spinner); the spinner only appears while adding a torrent.

29. Admin-whitelisted users bypass the Web-of-Trust (anti-abuse) — DEFERRED (YAGNI)

DECISION 2026-06-24: defer until there's a real brigading incident to scope against. The premise is sound (an admin vouch is a stronger, non-brigadeable signal than crowd-sourced WoT mutes/flags), but it's a speculative anti-abuse feature and the right scope is best decided against a real case. Low risk to defer at small scale: WoT mutes come from trusted muters, so brigading requires coordinating people already inside the trust graph. One caveat: there's currently no admin override to rescue a creator who does get WoT-hidden, so if it happens, ship this promptly.

Scaffolding already exists — when needed, this is a small, localized change:

• js/feedEngine/stages.js (~1143): adminWhitelist is already computed per video (adminStatus?.whitelisted === true) and there's an adminWhitelistBypass = false placeholder right beside the hide decision (~1210-1229) + a hideBypass framework ("viewer-override" / "feed-policy"). Wire "admin-whitelist" as another reason.
• Scope it correctly (the design refinements):
  1. Bypass only the WoT mute/report HIDE layer — that's the brigadeable part.
  2. Never override a viewer's OWN block/mute — those are a separate, earlier filter (reason: "viewer-block", stages.js:934), so the bypass naturally won't.
  3. Open scope question (decide against the real case): bypass soft report categories (nudity/spam/general mutes) only and still HIDE hard/illegal categories — vs. bypass everything. Categories ARE distinguished (reportType), so either is feasible. Leaning soft-only so a whitelist can't force-show illegal.
• When a real example appears: flip the placeholder with the scope above + tests.

30. Blossom storage support (bring to par with R2 / S3) — full plan in docs/blossom-plan.md

• Add Blossom (nostr-native blob storage) as a first-class upload provider alongside Cloudflare R2 / generic S3 / B2. Slots into the existing service.uploadFile({…}) → {url,key} seam (mediaUploader.js:38) as a new blossomService + isBlossomProvider branch — Blossom's upload is simpler than S3 (no SigV4/multipart/bucket/CORS), and auth is a signed nostr event (kind 24242, BUD-11) that reuses bitvid's existing signer (no new crypto).
• Best practice (researched 2026-07-09): use the maintained blossom-client-sdk v5 (hzrd149) — ESM, only dep @noble/hashes which bitvid already vendors. Spec has modularized: BUD-01 retrieval, BUD-02 /upload, BUD-11 auth (kind 24242, NIP-40 expiration, t/x/server tags, Authorization: Nostr <base64url>), BUD-12 /list+DELETE, BUD-03 kind-10063 discovery, BUD-04 mirror, BUD-05 /media, BUD-06 preflight. Core min = 01+02+11; add 03/06/04.
• Design shifts (decisions D1–D10 in the plan): multi-server list + mirror (Blossom's whole point vs one bucket), kind-10063 read/publish, /upload for video (keep bytes for torrent) + optional /media for thumbnails, keep the magnet/torrent parity, and a keyless multi-server config form (no access-key/secret/bucket) — which also removes the encrypted-cred-sync surface for Blossom users (there's no secret, only server URLs + the signer).
• Flag-gated FEATURE_BLOSSOM_STORAGE (off = no trace), vendored SDK, phased: P0 flag+vendor, P1 upload+config UI, P1.5 discovery, P2 list/delete+orphan-GC+mirror, P3 extras. Lift = medium (upload core is SDK glue; the config UI is the main cost). Public blobs only (D10 — no private content on base Blossom).

34. NIP-71 mirror: videos show "not mirrored" + duplicate on re-mirror (BUG) — FIXED 2026-06-29 (only live Amber VERIFY remains)

Reported 2026-06-25. Relates to #17 (NIP-71 interop) / the bitvid→NIP-71 mirror.

• Mirrored videos report as NOT mirrored. All videos were mirrored, but the UI now shows them un-mirrored even though the NIP-71 mirror events exist. The "is this mirrored?" detection is wrong/stale (likely the mirror-state lookup doesn't find the existing kind-21/22 mirror, or a flag isn't persisted/derived).

• Re-mirroring creates DUPLICATES. Because they read as un-mirrored, mirroring again publishes a SECOND NIP-71 event, so NIP-71 clients show two copies of the same video. The mirror should be idempotent (addressable/replaceable, or detect the existing mirror and update it) instead of creating a duplicate.

• Delete/un-mirror correctly removes BOTH copies (so the dedup key is shared) — confirms the publish path is creating a true duplicate, not a distinct event.

• Fix: make mirror detection reliable + the mirror publish idempotent. See js/nostr/nip71Mirror.js / js/services/nip71MirrorFlags.js.

• AUDIT done 2026-06-25. Two root causes: 1. Detection is device-local. isMirrorEnabled(pubkey, videoRootId) (nip71MirrorFlags.js) reads a localStorage flag (FLAG_KEY), NOT the actual published mirror events — so a cache clear / other device / lost flag reports "not mirrored" even though the 34235/34236 events exist on relays. 2. Kind is unstable → cross-kind duplicate. buildNip71MirrorEvent (nip71Mirror.js:177) uses short = hasDims && height > width → kind 34236, else 34235. The d-tag is deterministic (["d", videoRootId]), but (34235,pubkey,d) and (34236,pubkey,d) are DISTINCT addressable events. When a video has dimensions on one mirror attempt but not another, the kind flips, so re-mirroring publishes the OTHER kind → two copies in NIP-71 clients. "Delete removes both" confirms the shared d-tag / two-kind duplicate.

• FIX (a) Idempotent publish + self-heal — DONE 2026-06-25. nip71MirrorService.publish() now looks up the author's existing mirror (both kinds) via the SubscriptionManager chokepoint and reuses the existing kind so a re-publish REPLACES the same addressable coordinate instead of creating the cross-kind duplicate. If both kinds already exist (the bug's aftermath), it self-heals by NIP-09-deleting the stale-kind coordinate. An explicit options.short override still wins. Also added findMirror(video) (relay-truth {mirrored, kinds, duplicate}). Dependency-injected; 4 new scenario tests in tests/nip71-mirror-service.test.mjs (12/12 green); lint clean (no direct pool.list — uses getSubscriptionManager().list).

• FIX (b) Relay-truth detection in the UI — DONE 2026-06-29. Added batched nip71MirrorService.findMirrors(videos) → Map<videoRootId, {mirrored, kinds, duplicate}> (one relay lookup per root via Promise.all, all through the SubscriptionManager chokepoint). MyVideosController.renderRows now fires refreshMirrorStates(rows) after the synchronous (local-flag) render: it looks up relay truth, reconciles the device-local flag to match (so the flag becomes a correct cache, not the source of truth), and corrects each mirror button's label ("Shared ✓" / "Share to apps"). Buttons are tagged data-mirror-root for the batched update. Fire-and-forget — never blocks render; detection failures fall back to the local flag. 4 new behavioral tests in tests/my-videos-mirror-relay-truth.test.mjs (jsdom: promote unmirrored→shared, clear stale shared, per-row batch reconcile, button tagging); build + lint clean.

• VERIFY on unstable with Amber: re-mirror an already-mirrored video → it should replace (one copy), and a previously-duplicated video should collapse to one.

35. Admin whitelisting tool is slow & cumbersome — improve with application forms

• The current admin whitelist tool is slow and clunky to use. Improve the UX when we integrate the application/submission forms (#22) and the Admin Submissions tab (#23) — e.g. approve-an-application → add-to-whitelist in one action, batch operations, and faster list mutation. Couples with #22/#23.

36. Storage unlock doesn't work with nsec login (BUG)

• ROOT-CAUSED + FIXED 2026-06-29. Audited the whole nsec unlock path and built an empirical repro: the crypto layer is correct — with real nsec cipher closures (createPrivateKeyCipherClosures), storageService.unlock round-trips master-key encrypt→lock→decrypt perfectly (NIP-44). Both nsec login paths (registerPrivateKeySigner, unlockStoredSessionActor) register a signer exposing nip04Decrypt/nip44Decrypt. The real failure is session-shape after a page reload (user-confirmed repro): a persisted "remember this key" nsec session restores the logged-in pubkey + UI but NOT the in-memory signer (the private key is only passphrase-encrypted). ProfileStorageController's fallback (ensureActiveSignerForPubkey) can only rebuild an extension signer, so an nsec user hit a dead-end: storage unlock found no signer and showed the misleading "No active signer found. Please login." even though they look logged in. Fix: detect this exact case (getLockedStoredNsecSession — a saved nsec key for the account being unlocked via getStoredSessionActorMetadata) and surface an actionable error/status ("Your saved key is locked after reload — re-enter your passphrase from the Login menu to unlock it, then unlock storage") in both the Unlock-button flow and the passive Storage-pane status text, instead of the generic no-signer / no-decryptor messages. New error code storage-unlock-locked-nsec-session. Tests: tests/storage-unlock-locked-nsec.test.mjs (6, behavioral). Build + lint clean.
• Follow-up (UX nicety) — DONE 2026-06-30. Clicking "Unlock Storage" on a locked persisted-nsec session now auto-opens the login modal straight to its existing unlock-saved-key (passphrase) flow, so the user re-unlocks in one step. Added a side-effect-free openLoginModal service to profileModalServices (app.loginModalController.openModal — no add-account callback, idempotently ensures the modal exists first); reportLockedNsecSession({ autoOpenLogin }) calls it only from the user-initiated unlock click, NOT the passive pane render (no surprise popups). After the user unlocks, the signer is active app-wide and re-opening the storage pane auto-unlocks. Tests extended (8 total: asserts auto-open fires on click, stays closed on passive render).
• VERIFY on unstable: nsec-login with "remember key" + passphrase, reload the page, open Profile → Storage → the status should read the actionable re-unlock hint (not "No active signer"); after re-entering the passphrase via Login, storage unlocks normally. ([storage-unlock] console line confirms the locked-key branch.)
• Same fix for the UPLOAD modal — DONE 2026-06-30. The Upload modal's "Unlock storage" had its OWN unlock path (UploadModal.handleUnlock) that dead-ended on a reloaded persisted-nsec session with "No signer available to unlock storage." Added promptStoredNsecUnlock(pubkey): when the active account has a locked saved nsec key (getStoredSessionActorMetadata), it shows an actionable message and opens the login modal's unlock-saved-key (passphrase) flow (onRequestUnlock, wired in initUploadModal → app.loginModalController.openModal) instead of the alert. After the user re-enters their passphrase the signer is active and the upload proceeds. Tests: tests/upload-modal-nsec-unlock.test.mjs (5). Build + lint clean.

37. Channel playlists — creator-curated custom note lists

• Let creators build playlists (custom curated lists of their videos / notes) surfaced on their channel. Likely a NIP-51 set (kind 30005 "curation sets" or a bitvid-specific addressable list) referencing video events, with create/edit/ reorder UI on the channel page and a playlist view. Research the list shape + where it slots into channel profile + the feed engine.

38. Generic S3 doesn't work with Backblaze B2 — add B2 as a first-class provider

• DONE 2026-06-30. Added Backblaze B2 as its own provider (PROVIDERS.B2 = "backblaze_b2"). Root issue: B2's S3 endpoint is region-scoped (s3.<region>.backblazeb2.com) and a public bucket is addressed virtual-hosted, so the public download URL is https://<bucket>.s3.<region>.backblazeb2.com/<key> — not derivable from a pasted generic-S3 endpoint. Implementation: - deriveB2Endpoint(region) (js/storage/s3-url.js, re-exported from s3Service): region → https://s3.<region>.backblazeb2.com; returns "" for auto/blank/pasted host so callers can require a real region. - storageService: PROVIDERS.B2 + resolveB2Endpoint (explicit endpoint wins, else derive from region) + a PROVIDER_TESTS[B2] handler (derived endpoint, forcePathStyle:false). - Public URL strategy = S3-style virtual-hosted (user-chosen): auto-derives to https://<bucket>.s3.<region>.backblazeb2.com; an explicit Public Access URL (custom domain/CDN) overrides it — the save path now passes the user's URL to prepareS3Connection (also fixes generic-S3 silently ignoring a custom CDN URL). - UI (profile-modal.html + ProfileStorageController): "Backblaze B2" option + helper; for B2 the raw Endpoint field is hidden (region drives it), Region shows a us-west-004 example, force-path-style toggle hidden (B2 is virtual-hosted), and save/test derive the endpoint from region (clear "enter your region" error if missing). UploadModal shows B2-specific labels. - Tests: tests/storage-b2-provider.test.mjs (8 — endpoint derivation, virtual- hosted public URL, end-to-end validate, explicit override, object URLs). All s3/storage suites green (50); build + lint clean.
• VALIDATED against a real B2 account 2026-06-30. Read-only b2_authorize_account on the live bitvid bucket confirmed the derivation EXACTLY: B2's reported s3ApiUrl = https://s3.us-west-004.backblazeb2.com = deriveB2Endpoint("us-west-004"); bucket is allPublic → S3-style playback URL works. Key file caps (read/write/list/delete) ✓.
• CORS helper modal (provider-aware) — DONE 2026-06-30. Empirically confirmed the gotcha: B2's web-console "Share everything…" presets write DOWNLOAD-only CORS (s3_get/s3_head, b2_download_*) — no s3_put/s3_post — so browser uploads CORS-fail. Added a "CORS setup help" button (shown for all bucket providers) opening a provider-aware modal: - Backblaze B2 → B2-native rules JSON (upload + ranged-playback ops) + the b2 update-bucket --corsRules … command. - Custom S3 → standard S3 CORSConfiguration JSON + aws s3api put-bucket-cors --endpoint-url <endpoint> …. - Cloudflare R2 → standard S3 JSON + Cloudflare-dashboard guidance (R2 → bucket → Settings → CORS Policy) and the AWS-CLI command against the derived R2 endpoint. Origins pre-filled from getCorsOrigins(); copy buttons for JSON + command. bitvid still auto-applies CORS on Save (R2/S3 via ensureBucketCors) — this is the manual fallback for when the key lacks CORS-write permission. Logic in js/ui/profileModal/storageCorsHelp.js (buildCorsHelpContent switches on provider; keeps the controller <1000 lines). Tests: tests/storage-cors-help.test.mjs (10 — per-provider rules/command + DOM switch). Build + lint clean.
• VERIFY live on unstable: pick Backblaze B2, enter region (us-west-004) + bucket + key/secret, Test → passes; apply the CORS helper's rules; upload a video → plays from https://<bucket>.s3.<region>.backblazeb2.com/....
• Per-provider connections (no overwrite/clash) — DONE 2026-06-30. The UI saved every provider into a single shared "default" connection id, so configuring B2 overwrote R2 (etc.). The service layer + upload path + sync already supported a MAP of connections keyed by id (listConnections/defaultForUploads/ exportAccountRecord) — only the controller collapsed them. Now each provider type gets its own slot keyed by provider id (cloudflare_r2/backblaze_b2/generic_s3): save writes that slot (preserving a single active defaultForUploads, and lazily migrating the legacy "default" slot to its provider id), and switching the provider dropdown loads that provider's saved credentials (or clears the fields for a fresh entry). Sync already carries the whole record, so all providers sync together. Logic extracted to js/ui/profileModal/storageConnections.js (saveProviderConnection + pure helpers; keeps the controller under the 1000-line cap). Tests: tests/storage-connections.test.mjs (7 — pure default/dup logic + integration: R2+B2 coexist with one default, re-default switch, legacy-default migration, and the export carries both). Storage + profile-modal suites 69/69; build + lint clean.
• Upload wrong-service routing FIXED 2026-06-30 (multi-provider regression). With both B2 + Cloudflare configured, an upload could fail with "S3 endpoint is required." when the upload modal's tracked activeProvider drifted out of sync with activeCredentials (user: "selector on Backblaze but the modal set for Cloudflare") — an R2 connection (accountId, no endpoint) got routed through the S3 service. Fix: MediaUploader.uploadVideo/uploadThumbnail now route by the CREDENTIALS' own provider (credentials.provider || meta.provider || provider), so a stale modal provider can't pick the wrong service. Test: tests/media-uploader-provider-routing.test.mjs (4). Build + lint clean.
• Follow-up (cosmetic): the upload modal's summary provider label can still show a stale provider until reloaded — refresh loadFromStorage when the storage default changes in the Storage pane (functional routing is already correct).
• B2 / generic-S3 upload contract mismatch FIXED 2026-06-30. Uploading to a Backblaze B2 (or any generic-S3) bucket failed with "S3 endpoint is required." Root cause: MediaUploader calls service.prepareUpload(npub, { credentials }) (the r2Service contract), but s3UploadService.prepareUpload took (settings, …) — so the npub string became the settings (no endpoint). Also a storageService.getConnection() result keeps bucket/endpoint/region under .meta, which validateS3Connection reads at the top level. Fix: s3UploadService.prepareUpload now accepts (npub, { credentials }) and flattens meta → top-level via flattenS3Settings. (R2 was unaffected because its service already used that contract.) Also: the storage Test now derives/passes the B2 public URL so it stops falsely warning "Public Bucket URL is missing." Tests: tests/services/s3-upload-prepare-contract.test.mjs (3 — flatten + npub-ignored + back-compat). Build + lint clean; upload/storage suites 46/46.

39. Image uploads should prefer uploading to configured storage (UX)

• Profile image + banner upload — FIXED 2026-06-30. The UI was already wired (ProfileEditController.handleUpload: resolve connection → uploadFile → auto-fill the URL field), but it was broken: it passed a hex pubkey to r2Service.resolveConnection(), which only decoded npub1… strings (safeDecodeNpub) → hex resolved to null → "Storage configuration missing" and the Upload button stayed disabled even with storage configured. (Thumbnails worked because mediaUploader uses listConnections(pubkey) directly.) Fix: resolveConnection now accepts a hex pubkey OR an npub. The rest of the chain is already provider-agnostic — resolveConnection returns the defaultForUploads connection (any provider) with its endpoint/baseDomain/ forcePathStyle, uploadFile routes R2 vs generic-S3 by provider, and buildPublicUrl builds the right URL — so this now works for R2 / B2 / Custom S3. Test: tests/r2-resolve-connection-hex.test.mjs (3, with nip19.decode throwing on hex to prove the hex path, not npub decoding). Build + lint clean.
• VERIFY live: unlock storage, Edit Profile → upload a picture/banner file → uploads to the active provider's bucket and the URL auto-fills.
• Extend the pattern to any remaining image-URL inputs that still only accept a pasted link (video thumbnail in upload/edit already uploads via mediaUploader). Audit for others (e.g. future channel/branding image fields) and reuse the helper.

Open — lower priority / infra

10. WebTorrent null.fill seeding crash

• Investigate the vendored webtorrent.min.js null.fill error on wire handshake; may require a bundle update or patch.
• Bounded investigation DONE 2026-07-03. The vendored bundle is webtorrent 2.5.11 (~2 years old; upstream latest is 3.0.16). The bundle has exactly two .fill( sites: a piece-bitfield fill and this.buffer.fill(void 0) — fast-fifo's clear(), the queue streamx uses under bittorrent-protocol's wire Duplex. "null.fill on wire handshake" = that queue being touched after stream teardown (use-after- destroy in the streamx/fast-fifo layer). No matching public upstream issue found, but webtorrent 3.x now PINS streamx to an exact version (2.25.0) — consistent with upstream having chased this bug class.
• Fix path: vendored-bundle update to 3.0.16 as its OWN task (playback- critical → own branch/soak, NOT bundled with other work): rebuild js/webtorrent.min.js + .map, re-test URL+magnet playback, seeding, the beacon app (torrent/), and the SW streaming path; rollback = keep the old bundle file. Check 2.x→3.x breaking changes against js/webtorrent.js usage first. Without a repro for the crash, a blind local patch is guesswork — the update is the honest fix.

11. Harden flaky tests (CI gate reliability)

• tests/ui/uploadModal-reset.test.mjs ("UploadModal Reset Logic") — FIXED 2026-07-05. The "guard against zombie callbacks" subtest mocked modal.generateTorrentMetadata / resolveUploadIdentifier, but handleVideoSelection drives the upload through this.mediaUploader.uploadVideo (a DIFFERENT object with its own helpers) — so the mediaUploader still ran real createTorrentMetadata()/hashing on a synthetic {name:"video.mp4"} file, throwing "invalid input type" as async activity AFTER the test ended (node:test flags that as an uncaughtException) plus captureVideoMetadata() calling URL.createObjectURL(file) → "must be an instance of Blob". Not intermittent anymore — it was a consistent, wrong-boundary mock. Fix: mock at the real DI boundary — modal.mediaUploader.uploadVideo = () => delayedUpload (the controllable pending promise) + stub modal.captureVideoMetadata. Now hermetic, no webtorrent/Blob, deterministic (3/3 exit 0, # pass 3). Mutation-verified: breaking the videoUploadId zombie guard makes the test fail (# fail 1). See TEST_INTEGRITY.md.
• Audit e2e parallel-load flakiness too.

11b. SILENTLY-EXCLUDED unit tests — 20 files never run in CI (found 2026-06-23)

2026-07-03 addendum — stale-default failure was hiding in local runs: tests/app/hash-change-handler.test.mjs had been failing since 04621efc (2026-06-24) made TRENDING the deliberate logged-out landing — the test still expected most-recent-videos. It went unnoticed locally because npm run test:unit | tail reports the PIPE's exit code, not npm's (lesson: never pipe the suite when reading its exit status). Spec-corrected to assert views/trending.html (integrity note in the test file); all 3 tests pass. scripts/run-unit-tests.mjs only collects *.test.mjs|*.test.js files whose content contains node:test (line ~54). 20 test files use bare assert + top-level await instead, so the runner skips them WITHOUT WARNING and they are referenced by no other CI script. They rot invisibly (this is how the delete-flow test below was failing on main unnoticed).

• tests/nostr-delete-flow.test.mjs — FIXED + brought into CI (converted to node:test; stale write-relay config + removed-pool.sub subscription harness corrected; see TEST_INTEGRITY.md 2026-06-23).
• Add a guard so this can't recur: make run-unit-tests.mjs emit a visible WARNING (or fail) when it finds a *.test.{mjs,js} lacking a node:test import, listing each skipped file. (Decide warn-vs-fail — fail would immediately red-CI on the ~11 broken files below until they're triaged.)
• Runner guard SHIPPED (2026-06-23). scripts/run-unit-tests.mjs now collects EVERY *.test.{mjs,js} (no more node:test content filter) and runs both styles. Known-broken files are listed in an explicit QUARANTINE map — loudly reported on every run (never silently skipped), and a stale-entry check flags any quarantine path that no longer exists. The 10 PASSING orphans below now run in CI automatically (no per-file conversion needed). - PASS, now in CI: nostr-view-event-bindings, nostr-rebroadcast-guard, watch-history-feed, subscriptions-feed, discussion-count-service, feed-engine, zap-split, nostr-view-events, watchHistory/watch-history-telemetry, unit/ui/thumbnailBinder.
• ALL broken files triaged + un-quarantined (COMPLETE 2026-07-05). The QUARANTINE map in run-unit-tests.mjs is now empty; every unit test file runs in CI. Per-file diagnosis + spec-correction history below (each got the stale-vs-real-bug investigation the delete-flow file got): - watch-history (#2) — DONE + UN-QUARANTINED 2026-06-23. Three stale tests, all spec-corrected to shipped behavior (see TEST_INTEGRITY.md): (1) testWatchHistoryPartialRelayRetry asserted snapshot THROWS on partial acceptance (contradicting 565a9618) → now asserts success / no-throw / no-republish / queue-emptied; (2) testWatchHistoryServiceIntegration set a logged-in pubkey different from the queried actor (history files under the logged-in pubkey now) → aligned; (3) same test asserted session===true for a logged-in watch (the pre-fix bug) → corrected to session!==true. The full 2669-line file passes via the CI runner and was removed from QUARANTINE. - nostr-boost-actions — ✅ DONE + UN-QUARANTINED 2026-06-25: STALE SPEC. The test required buildRepostEvent to throw /missing-event-relay/ with no relay hint, but a relay hint is a NIP-18 SHOULD (not MUST) — the builder degrades to a two-element e tag so a user can always repost. Replaced with an exact assertion of the valid output (kind 16 + e/p/k tags). See TEST_INTEGRITY.md. - view-counter (#4) — ✅ DONE + UN-QUARANTINED 2026-06-24: the failures were (a) the deterministic-d-tag accuracy fix (no more random d tag, so no auto-d either), (b) the batched SubscriptionManager silently shadowing the legacy mocks, (c) a time-of-day-flaky dedupe-window setup, and (d) a moved root-timestamp unit boundary. All fixed; full file green. See TEST_INTEGRITY.md. - zap-shared-state (#3) — ✅ DONE + UN-QUARANTINED 2026-06-23: stale fee-fallback test (expected 0; the function correctly falls back to the configured default so a junk override can't bypass the fee) — corrected. - video-modal-zap (#3) — ✅ DONE + UN-QUARANTINED 2026-06-23: surfaced TWO real zap bugs (in-flight status mis-toned warning→neutral; success path now uses the holistic resetZapForm) + spec/harness fixes (completion-count reset+complete; receipt render asserts on the inner zapController's element after the VideoModal→sub-controller refactor). - nwc-client (#3) — REAL production bug FIXED 2026-06-23: parseNwcUri passed a hex secret to nostr-tools getPublicKey (needs bytes) → NWC connection broken. Fixed + guarded by the real-tools tests/nwc-parse-uri.test.mjs. The mock-based nwc-client.test.mjs STAYS quarantined — its nostr-tools mock is shadowed by the frozen canonical toolkit the bootstrap installs; needs a mock-injection rework. - nostr-count-fallback — ✅ DONE + UN-QUARANTINED 2026-06-25: STALE TEST after a refactor. countUnsupportedRelays moved from NostrClient to its ConnectionManager; the test read it off the client (undefined.has). Repointed the assertion at client.connectionManager.countUnsupportedRelays. No behavior change. - admin-list-store — ✅ DONE + UN-QUARANTINED 2026-06-25: STALE HARNESS (no production change, no assertion weakened). Community curator lists are fetched via the BATCHED SubscriptionManager (cold-start relay-storm fix) which the harness didn't mock; the mock-"hex" curator values started with "npub" so parseCommunityBlacklistReferences decoded them twice; and createListEvent omitted the d tag that selectNewestEventsForReferences matches on. Fixed all three to be faithful to production. See TEST_INTEGRITY.md. - nostr-publish-rejection — ✅ DONE + UN-QUARANTINED 2026-07-05. The two spec precondition fixes had already landed (dev-mode override at top; NIP-71 auto-publish spec-corrected to expect ZERO calls with FEATURE_PUBLISH_NIP71 off). Remaining issue was a post-completion HANG: the file imports the full app stack (js/app.js + subscriptions + userBlocks) whose module-load timers/connection managers keep the event loop alive after all assertions pass. Applied the repo's established bare-assert setTimeout(() => process.exit(0), 50) exit after cleanup. NOTE: it was never actually in the QUARANTINE map (only 2 entries: user-blocks + nwc-client), so it had been silently hanging any local npm run test:unit (no per-file timeout unless UNIT_TEST_TIMEOUT_MS is set). - nwc-client — ✅ DONE + UN-QUARANTINED 2026-07-05. (1) Mock-shadow fixed: the bootstrap's frozen canonical toolkit is preferred by readToolkitFromScope, so the per-section window.NostrTools mocks never took effect (real @noble rejected the fake keys). Removing the scope canonical lets the resolver fall through to each mock. (2) Spec correction: one section expected a rejection when the toolkit "lacks nip44," but mergeWithCanonical ALWAYS backfills the canonical nip44 (even explicit nip44:null), so nip44_v2 is never absent — the wallet now advertises a genuinely-unsupported scheme (nip44_v3) to exercise the same UNSUPPORTED_ENCRYPTION path, and the assertion also checks error.code. - user-blocks — ✅ DONE + UN-QUARANTINED 2026-07-05. Post-completion HANG: the decrypt-timeout section installs a never-resolving nip44Decrypt that leaves a background decrypt-retry timer alive (manager.reset() doesn't cancel it). Applied the same setTimeout(() => process.exit(0), 50) exit after the final assertion. - dm-block-filter — ✅ DONE + UN-QUARANTINED 2026-07-05. A FOURTH, pre-existing hang surfaced by running the full suite with a per-file timeout (it was never in the map, so it had been silently hanging local npm run test:unit). All subtests PASS, then node:test never exits. Root cause (diagnosed via process.getActiveResourcesInfo): the "integration with loaded user block list" test's manager.loadBlocks() opens a LIVE block-list subscription through nostrClient's real SimplePool aimed at the test's fake relay URLs, leaking 4 TCP sockets + reconnect timers. NOT the decrypt-retry timer (verified absent). Nulling the pool did NOT help — loadBlocks calls ensurePool() (userBlocks.js:967) to re-create+connect a real pool when pool is falsy. Fix (node:test-SAFE, no force-exit): make the test hermetic — (1) a TRUTHY stub pool so ensurePool() is skipped, (2) a no-op getSubscriptionManager so the subscription opens nothing; the block MERGE still runs via the stubbed fetchListIncrementally. Verified: clean run exits 0 (# pass 12), AND a deliberately broken assertion still exits 1 (# fail 1) — failures are NOT masked. See TEST_INTEGRITY.md. - QUARANTINE map is now EMPTY — every unit test file runs in CI.

12. Promotion: unstable → beta

• After this batch soaks and the high-priority items land, promote unstable → beta for hosted-domain QA (per the release pipeline in CLAUDE.md). Never push directly to beta/main — always promote from the previous stage.

Open — My Videos tab follow-ups (deferred from the build)

13. My Videos enhancements

• Restore (un-delete) action for deleted rows — republish a prior live version so a tombstoned video can be brought back from the management tab.
• info.json sidecar on upload — write a small metadata file next to each uploaded object (title, event id, root id, date) so orphaned files can be identified by name even after their note is gone from relays. PRIVACY GUARD: skip private videos (the bucket is public) or only mirror already-public fields. Path-based reconciliation stays the baseline (sidecar is additive, future-only).
• Show orphan size/last-modified (from the ListObjectsV2 metadata) on orphan rows to make triage easier; consider grouping by folder.
• Replace the window.confirm on orphan delete with the app's confirm/modal for a consistent, less jarring destructive-action UX.
• External (non-bucket) URL liveness is unverifiable from the browser — currently left "OK/unverifiable" on purpose. Optionally add a server-side/HEAD check later if false-confidence becomes a problem.

Open — deploy / CI infra (from this session)

14. Deploy workflow + CI gate health

• On-demand deploy is now the norm for unstable (auto-deploy disabled). Deploy with vercel deploy --prod (repo is linked to bitvid-unstable). Decide whether to apply the same git.deploymentEnabled:false to beta, and whether to ever set the Vercel Production Branch = unstable if auto-deploy is wanted again.
• Visual-regression baseline is environment-sensitive / stale (committed baseline from 2026-03 vs current CI Chromium/font rendering → ~1.4% diff). It's no longer deploy-blocking (own job) but the job is red. Regenerate the baseline inside CI's environment (or pin fonts / run visual in a fixed container) so it's a trustworthy gate again — relates to #11.

Open — enhancements (security-sensitive)

15. Encrypted cross-login sync of storage credentials + NWC wallet (opt-in)

Goal: optionally sync the S3/R2 storage credentials AND the NWC zap wallet URI across logins/devices via an encrypted Nostr note, unlocked by the logged-in signer — so users don't re-enter them on every device. Opt-in only; off by default.

Status (2026-06-21): COMPLETE — shipped to unstable. Core + Storage + NWC wallet sync + offer-to-pull-on-login all live. Follow-ups only: cross-device merge (restore currently REPLACES) and upgrading the login confirm() to a styled modal.

Design / approach:

• Shared core js/nostr/encryptedSync.js (DI, unit-tested): NIP-78 app data (kind 30078) replaceable events, namespaced d-tags, NIP-44-encrypted to self with NIP-04 fallback. Facade js/nostr/encryptedSyncFacade.js wires it to the live client/signer. (commits 0abb82b9, 6f7f4196, 7376ff91)
• Storage creds: re-encrypt the WHOLE on-disk account record to self (its meta is plaintext — bucket/endpoint names — so transporting the bare envelope would leak those). storageService.exportAccountRecord / importAccountRecord; storageSyncService (d-tag bitvid:storage-connections).
• NWC URI is a bearer SPENDING secret stored via nwcSettingsService — encrypted to self under d-tag bitvid:nwc; gated behind an explicit window.confirm spend warning. walletSyncService + Wallet pane UI. Disconnecting the wallet while synced also wipes the note.
• Relay/replaceable lessons applied: publish to the WRITE relays (getDeletePublishRelays), created_at forced strictly-newer, read takes the newest event per d-tag (reads routed through the subscription manager, not pool.list). NWC will reuse the same core.
• Storage UX: opt-in "Sync these settings to my Nostr account (encrypted)" toggle + "Restore" button + public-relay/key-compromise warning in the Storage pane (shown only when unlocked). Re-pushes on save when enabled.
• Wallet UX: toggle/restore in the Wallet pane + spend warning + confirm.
• Offer-to-pull on login: one-time per-pubkey prompt (settingsRestorePrompt + encryptedSync.exists list-only peek), wired in app.maybeOfferSettingsRestore (deferred, non-blocking). Reuses the pulls.
• Clear/disable: clear() publishes a cleared marker so the wipe propagates (empty-replaceable-publish lesson); disable() calls it.

Threat model / cautions (write these into the feature + docs):

• The encrypted blob lives on PUBLIC relays: NIP-44 hides contents but not the fact that this pubkey stores bitvid creds. Acceptable, but document it.
• Anyone who compromises the user's Nostr key can decrypt these (same trust root as everything else they sign) — make the opt-in copy explicit about that.
• NWC URI = spending capability; treat as highest-sensitivity. Consider a confirm + "this lets any device with your key spend from this wallet" warning.
• Never log decrypted creds; clear in-memory copies on logout (existing rule).
• Decryption goes through the (single-threaded) signer — respect the NIP-07/46 decrypt budget + circuit-breaker invariants; don't block login on it.

Open — new content-type support (needs research first)

Note: live streams and short-form video are almost certainly NOT the same thing — they're two different NIPs. Confirm the exact kinds/tags before building.

Shared requirement for #16 + #16b: each is a NEW left sidebar tab, and each must be independently enable/disable-able from the instance config file (config/instance-config.js, like the existing feature flags). When a tab is disabled it must be completely absent — no tab, no subscriptions, no trace — exactly as if it were never added (the current default state). Build both behind their own config flags from the start.

16. Nostr live streams — INGEST / watch-only (zap.stream, shosho.live)

Dev plan: docs/live-ingest-plan.md (decisions open + Phase 0 research spike). Ingesting live streams (watch others' streams) and PUBLISHING a stream ("go live", #16c) are TWO separate functions and must each have their OWN config flag — the maintainer wants to enable/disable ingest and publish independently.

• Likely NIP-53 Live Activities: kind 30311 (live event; carries the streaming URL — usually HLS .m3u8 — plus status live/planned/ended, title, host p tags), and kind 1311 (live chat). zap.stream and shosho.live publish these.
• Watch-only scope: discover/list live (status=live) events, render the HLS stream in the player, optionally show live chat (read).
• New "Live" sidebar tab, gated behind its own INGEST config flag (see shared requirement above) — disabled by default until shipped.
• Research: confirm NIP-53 kinds + tag shapes, how zap.stream vs shosho.live populate streaming/recording, and HLS playback support in the player.

16c. Publish live streams — "Go Live" from bitvid (like zap.stream)

Dev plan: docs/live-publish-plan.md (FUTURE — after #16 + #16b; static client + optional Media Node/Bridge split; MediaMTX; NIP-98 bridge auth; archive→VOD reuses the s-tag/info.json model. Decisions open.)

• Let users broadcast their own stream (camera / desktop / arbitrary source) to Nostr via bitvid, the way zap.stream does: publish a NIP-53 kind-30311 live event (status live → ended), push the media to a streaming endpoint (HLS), and keep the event updated. This is the OUTBOUND counterpart to the #16 ingest.
• Separate config flag from ingest — the maintainer wants to enable/disable "go live" independently of watching live streams.
• Develop a PLAN first (this is a large effort): the streaming pipeline (getUserMedia/getDisplayMedia → encoder → HLS/WHIP ingest server), where the media is hosted (zap.stream uses an external streaming server — bitvid likely needs the same or a configurable endpoint), event lifecycle, and chat publish (kind 1311). Note: pure-static bitvid can't host the media itself; identify the streaming-server dependency early (relates to the CORS/edge constraints).

16b. Nostr short-form video notes — watch-only (new sidebar tab)

Dev plan: docs/shorts-plan.md (decisions open; ingest already exists).

• Short-form (vertical/portrait) video is NIP-71 kind 22 (the short-form counterpart to kind 21 normal video) — distinct from live streams. bitvid already ingests NIP-71 (see #17), so much of the parsing exists; this is about a dedicated "Shorts" sidebar tab with a short-form-appropriate UI (vertical player, swipe/next feel) that lists kind-22 notes.
• Gated behind its own config flag (see shared requirement above) — disabled by default until shipped.
• Research: confirm kind-22 tag shape vs kind 21, and whether to reuse the NIP-71 ingest adapter / feed pipeline or a dedicated shorts feed.
• OPEN QUESTIONS for the maintainer (raised 2026-06-23): (1) Should "Shorts" pull from the SAME whitelisted authors as the main feed, or its own discovery scope? (2) Does short-form need its own moderation/NSFW handling, or inherit the existing filters? (3) Same for "Live" — scope of who/what is listed?

17. NIP-71 interop (full plan in docs/nip71-migration-plan.md)

Research done; decisions locked. See the plan doc — it supersedes the rough notes below. Summary:

• Opt-in, off by default. Dual-event: keep canonical kind 30078; add an addressable 34235/34236 mirror (d=videoRootId, edits in lockstep). 34235/36 are NOT deprecated — current NIP-71 designates them for editable content.
• WebTorrent rides standard NIP-94 imeta fields (magnet, i); private videos never mirrored; HTTPS url required to mirror.
• Phase 0 (commit 0e2f683b): buildNip71MirrorEvent (js/nostr/nip71Mirror.js) maps a bitvid video → addressable 34235/36 event; magnet/i/ox added to the imeta builder+parser; mutation-verified tests. Flag still off, no UX.
• Phase 1 (in progress): - [x] 1a (e20191d6): nip71MirrorService.publish + the ALLOW_NSFW_CONTENT gate (instance that forbids NSFW won't mirror it outward). - [x] 1b (58f19095): remove teardown — NIP-09 delete (both addressable kinds) + empty-replace tombstone. - [x] 1c/1d (783c7df0): My Videos "Share to apps" opt-in toggle wired to the mirror service via new FEATURE_NIP71_MIRROR flag (on) + nip71MirrorFlags (per-video opt-in). Ineligible videos show the reason (private / NSFW-blocked / no-url). LIVE on unstable. - [x] Auto-sync (89d9a62b): mirror stays in lockstep on edit/delete, event-driven via nostrService videos:edited/deleted (no nostrService growth). Edit re-publishes (or unshares if now-private); delete tears down + clears the flag. - [x] Hashtags (a1bf7b15, e793b359): the upload modal's existing NIP-71 hashtag editor already emits t tags (feed scoring reads them); the mirror now carries them too (from t tags / nip71.hashtags). So publish + feed + mirror hashtags all work. - [ ] Remaining polish (low value): capture dimensions at upload (short 34236 + imeta dim — defaults to 34235 now); optional account-level "auto-share new public videos". - NOTE: legacy FEATURE_PUBLISH_NIP71 (videoPublisher.js auto-21/22) stays OFF/dormant — superseded by the opt-in 34235/36 mirror; clean up later.
• Phase 1.5: NIP-89 handler reg (kind 31990 → "Open in bitvid" elsewhere); NIP-51 kind 30005 portable playlists.
• Phase 2: inbound ingest of external NIP-71 videos — LIVE on unstable. - js/nostr/nip71IngestAdapter.js (foreign 21/22/34235/34236 → bitvid video; content-warning→isNsfw; skips bitvid mirrors; surfaces nip71.publishedAt), js/services/nip71IngestService.js (whitelist-scoped subscription, hydration retry, deferred-until-feed-ready, throttled refresh), wired in applicationBootstrap. Admin toggle FEATURE_NIP71_INGEST (instance-config) default ON. - Whitelist model: ingest is scoped to whitelisted authors and reuses the existing render-time filter (whitelist/NSFW/blacklist/private). When the admin disables whitelist mode, ingest opens to all authors (capped). - KEY FIX: the feed's resolve-posted-at stage was firing a per-video hydrateVideoHistory() network fetch for each ingested video (no kind-30078 history exists) → relay storm + feed hang. Fixed by surfacing nip71.publishedAt so the stage short-circuits. - Verified live: Goblinbox (Nostube) content renders; liveness check works.

17c. NIP-71 on-boarding + cross-ecosystem dedup (IMPORTANT — full plan in docs/nip71-onboarding-plan.md)

Make NIP-71 interop two-way and guarantee a video is never shown twice. See docs/nip71-onboarding-plan.md for the full dev plan. Locked decisions: creator-initiated self-import (model A — can't forge others' notes), dedup on explicit import-link + content hash/infohash (no fuzzy url/title), import grants CDN url + WebTorrent (bitvid extras come free), one-shot import + re-run button.

• Phase 1: cross-ecosystem dedup (js/utils/videoDeduper.js): collapseCrossEcosystem keyed per-author on fileSha256/ox/infoHash + an eid namespace linking on-board provenance (importedFrom); prefers the bitvid (kind-30078) version. Composed into dedupeVideos (root-dedup THEN cross-ecosystem) and routed through the shared chokepoint app.dedupeVideosByRoot → covers the feed stage + channel + search at once. Pure + mutation-verified. (Hash-less dual-posts still can't dedup — documented limitation; covered once on-boarded videos carry the provenance link.)
• Phase 2: creator-initiated import — discover the logged-in creator's own NIP-71 videos lacking a bitvid version; offer FULL import (re-host to THEIR storage + optional WebTorrent) or REFERENCE import (keep external URL, no re-host); publish a kind-30078 signed by them with an ["imported-from", <orig>] provenance tag. Same-pubkey-only guard; ALLOW_NSFW gate; reuses ingest adapter + storage/upload + videoPublisher.
• Phase 2b: externally-managed storage flag — imports NOT produced by our storage system (reference imports / external URLs) must be explicitly flagged (externalStorage: true, durable — not just the isUrlUnderBase heuristic) so storage tooling never treats them as bitvid-owned: My Videos shows an external badge (never "missing from bucket"), orphan reconciliation excludes them, the delete "hosted file left behind" warning is suppressed, liveness stays unverifiable. Full (re-hosted) imports set the flag false.

17d. Unified video-grid loading (streaming + optimistic) — follow-ups

Goal: every grid loads with the same fast UX. Status: cross-ecosystem dedup (17c Phase 1) is live at the shared chokepoint; main feed already streams + has a persisted cache; channel/search now render optimistically from allEvents (incl. ingested NIP-71). Remaining:

• Streaming channel/search fetch. loadUserVideos does a one-shot pMapSettled(relays, pool.list) and renders only after ALL relays settle, so a slow relay holds up the grid (~2-3s). Switch to the subscription manager's streaming + render incrementally (first-relay-wins), like the main feed's buffered subscription. Extract the fetch into channelProfileVideos.js (channelProfile.js is at its size cap).
• Per-channel persisted cache (channelProfileVideos.js, bitvid:channel-videos:v1): cold hard-refresh of a profile now paints the last-seen videos from localStorage before relays connect, then the live fetch replaces them. Bounded (60 videos/channel, 20 channels LRU), strips raw tags. Tests + mutation-verified.
• My Videos: include NIP-71 in its allEvents read so a creator's own cross-posted videos appear in management too (reuse the cross-ecosystem dedupe so the bitvid version wins).
• Consolidate the bespoke loaders (channel/search/My Videos) behind one shared streaming grid source so future grids inherit streaming + optimistic + dedupe for free.

17b. Channel Profile wall shows only bitvid videos, not NIP-71 (LAUNCH-BLOCKER)

• Fixed (js/channelProfileVideos.js): the channel grid now fetches the author's NIP-71 videos (kinds 21/22/34235/34236) alongside kind-30078 via buildChannelVideoFilters, and convertChannelEvent routes NIP-71 events through buildVideoFromNip71Event (skips bitvid mirrors). Existing dedupe-by-root + canAccess in buildRenderableChannelVideos handle precedence/gating. Logic extracted to a helper so channelProfile.js stayed under its size cap. Tests + mutation-verified.

40. Dead @media queries: var() in media conditions is invalid — FIXED 2026-06-25

Found 2026-06-25 while fixing the profile-modal mobile grid. Many media queries use @media (max-width: calc(theme("screens.lg") - var(--breakpoint-edge-offset))). CSS custom properties are NOT allowed inside @media conditions — Chromium/Brave drop the ENTIRE block, so all those rules are DEAD (confirmed via matchMedia: the var() form returns false where it should match; the literal calc(... - 0.02px) works). The --breakpoint-edge-offset token was introduced to satisfy the design-token lint (no raw measurements), but it silently broke every media query that used it.

• Audit all var(--breakpoint-edge-offset) (and any other var()) inside @media conditions in css/tailwind.source.css and replace with a valid literal-resolving form (e.g. @media (max-width: theme("screens.lg")), which compiles to a literal). The profile-modal nav grid (#7) already uses this.

• Decide whether the token-lint should EXEMPT @media conditions (so the offset token can stay) or whether to drop the offset pattern entirely.

• Re-verify the responsive rules that were silently dead (e.g. the profile-modal menu/pane-hide block, and the line ~1398/1433 player/modal rules).

• FIXED 2026-06-25. Replaced var(--breakpoint-edge-offset) with the literal 0.02px in all 4 @media conditions (css/tailwind.source.css). 0.02px was ALREADY exempt in the design-token lint, so the offset token was never needed — using it just produced invalid, dead media queries. Verified valid via matchMedia. This RE-ACTIVATES 3 previously-dead mobile blocks (intended behavior that had silently never worked): full-screen modals on mobile, profile-modal menu/pane switching, and the video-card tap-active state — plus the profile-nav app-grid.

• VERIFY live on a phone: modals should now be full-screen; tapping a video card shows the active lift/accent/marquee; profile modal tabs are the app-grid.

49. Relay-ack false-negatives on the generic content-publish path (HIGH-STAKES)

Same bug class as the list-publish fix (commit 47f2a9a8): all-timeout ≠ rejection.

• DONE 2026-07-03 — generic content publish is unconfirmed-tolerant, with HONEST outcome messaging at every consumer. The three bare assertAnyRelayAccepted call sites now use assertAnyRelayAcceptedOrUnconfirmed (all-timeout → summary.unconfirmed, soft success; explicit rejections STILL throw RelayPublishError): - signAndPublishEvent (js/nostr/publishHelpers.js — video publish, edit, repost, mirror, videoPublisher) + rebroadcastEvent. - revertVideo (js/nostr/client.js) — so a slow-ack tombstone no longer aborts deleteAllVersions midway (kind-5 hard delete now always runs). Honesty plumbing (the reason this was deferred): - The relay tally (attachRelayPublishSummary, now also attached on EDIT) carries unconfirmed; describePublishOutcome maps accepted=0 + unconfirmed → WARNING "sent, but no relay has confirmed receiving it yet" — never a fake "published to N relays", never a hard failure. Zero-accepted WITHOUT the flag stays the hard error. - Edit: editModalController reads the tally and says "update sent, not confirmed yet" instead of "updated successfully" when unconfirmed. - Revert: revertModalController tracks per-entry summaries and only says "Reverted…" when a relay ACKed; otherwise "sent, not confirmed yet".
• Delete semantics — decided CONSERVATIVE. A false "deleted" is worse than a false "failed": anyRelayAcceptedInSummaries (js/nostrPublish.js) scans every tombstone + kind-5 summary; handleDeleteModalConfirm only claims "All versions deleted successfully!" when ≥1 relay ACKed something, else "Delete request sent, but no relay has confirmed it yet — the video may reappear until relays catch up." (Empty set = nothing to publish = confirmed.) Tests: tests/relay-ack-unconfirmed-content.test.mjs (6, incl. end-to-end signAndPublishEvent all-timeout vs rejection). Lint + build green.
• VERIFY on unstable: with a slow/unreachable relay set, publish + edit + delete a test video — messages should read "sent/unconfirmed", never "failed", and the content should be correct after a refresh.

50. isDevMode — keep it; fix the test-harness gap (LOW priority)

• Decision (2026-07): KEEP isDevMode. It's used in ~26 files, chiefly to gate runtime schema validation in js/nostrEventSchemas.js (event builders validate against their schema only in dev — catches malformed events without the prod cost), plus dev-only verbose logging and dev-only feature flags (FEATURE_SEARCH_FILTERS). Removing it would drop that safety net or force validation into prod. Not a candidate for removal.
• DONE 2026-07-02 (quarantine triage): tests/nostr-publish-rejection.test.mjs fixed + un-quarantined — dev-mode override set before config import, and the stale NIP-71 auto-publish expectation spec-corrected (FEATURE_PUBLISH_NIP71 is deliberately off; the mirror is the interop path). File passes fully in CI. Original note: tests/nostr-publish-rejection.test.mjs asserts isDevMode === true but never sets globalThis.__BITVID_DEV_MODE_OVERRIDE__ before importing js/config.js, so it fails in a non-dev env (isDevMode falls back to IS_DEV_MODE = false). Fix: force dev mode via the override in that test's setup. Fails identically on committed HEAD — pre-existing, low priority.
• (Optional) sweep other tests that assume dev mode without forcing the override, for consistency.

Open — rough edges found in hands-on testing (2026-07-01)

Reported by the maintainer after live testing on unstable. Several share a root cause with #36 (a persisted nsec session restores the pubkey + UI but NOT the in-memory signer after a page reload, because the private key is only passphrase-encrypted). Items 51, 56, 57 are all facets of that.

51. Shouldn't have to re-"unlock" storage after every refresh (UX / session)

• Symptom: after a page refresh the user must unlock storage again every time.
• Root cause: same as #36 — the nsec signer + unlocked storage master key live only in memory, so a reload drops them. Today the fix (#36) makes the error actionable (re-enter passphrase), but the user still has to do it every reload.
• DONE 2026-07-01 — opt-in "keep unlocked" cache. Decision (maintainer): opt-in tiers. On a successful nsec unlock the decrypted key is cached in a new js/nostr/unlockedKeyCache.js: - session tier (default, always): sessionStorage — survives refresh / navigation, auto-cleared on tab close. Roughly the same exposure as the in-memory signer, so no more PIN on every reload within a session. - persistent tier (opt-in checkbox): the unlock prompt now shows a "Keep me unlocked on this device" checkbox (with an inline unencrypted-at-rest warning); when checked the key is ALSO written to localStorage and survives until the user clears site data. client.restoreUnlockedSigner(pubkey) re-registers the signer from the cache WITHOUT a passphrase (verifies the key derives to that pubkey; a mismatch forgets it). It's called proactively from ensureActiveSignerForPubkey (the auto-login/refresh path) and lazily from ensureEncryptionCapableSigner before any prompt — so after a reload the signer is restored silently and every signing/encryption flow (storage, hashtags, DMs, reactions, blocks, subs) just works. Logout / remove-saved-profile forget the cached key (forgetUnlockedSigner). Tests: tests/unlocked-key-cache.test.mjs (8). Lint + build green.
• Storage + NWC inherit the kept-unlocked signer — DONE 2026-07-01. Storage and NWC don't have their own passphrase: the storage master key and the NWC settings are ENCRYPTED WITH THE SIGNER (nip44/nip04 self-encryption) and unlocked by it. So rather than caching a second secret, both now inherit the kept-unlocked nsec signer. _initAutoLogin calls nostrClient.restoreUnlockedSigner(pubkey) BEFORE the boot re-login, so the login flow (NWC hydrate, list decrypt) and the existing storage auto-unlock (ProfileStorageController / UploadModal call storageService.unlock when a signer is present) all succeed silently on refresh — no passphrase, no manual "Unlock storage". Tied to the signer cache: persists exactly as long as the kept-unlocked key does (session or until site-data clear). (NIP-07/46 profiles no-op — nothing is cached; their extension/remote signer already persists.)
• VERIFY on unstable: unlock once (box unchecked) → refresh → no PIN, and Storage shows Unlocked + the wallet/NWC connection is live without re-entry; close the tab + reopen → PIN again. Check the box → close/reopen the browser → still no PIN and storage/NWC still ready; Log out or clear site data → PIN again.
• "Lock this device" control — DONE 2026-07-01. A footer button in the profile modal (desktop + mobile), shown only when the active account has a cached "keep unlocked" key to forget (app.isSessionKeptUnlocked). Clicking it runs app.lockKeptUnlockedSession(pubkey), which re-locks everything the signer unlocks in one action: forgets the cached key (both tiers → future reloads re-prompt), drops the in-memory signer (logoutSigner → the current session re-locks now), storageService.lock(pubkey), and nwcSettingsService.clearCache(). Visibility refreshes on renderSavedProfiles + selectPane. Tests: 2 in tests/profile-modal-controller.test.mjs (visibility gate + click locks the active pubkey). Lint + build green.
• Follow-up (optional): surface whether the current session is persistently remembered (disk vs session tier) in the UI, and consider a "keep unlocked" toggle in the storage/wallet panes for users who set it up there rather than via a prompt.

52. After editing a video, the video grids don't refresh to show the update (BUG) — FIXED 2026-07-02

• FIXED 2026-07-02. The edit flow already re-ran loadVideos(), but the cache still held the PRE-edit version: unlike new publishes (#46), the edit never ingested its signed replaceable event locally, so grids re-rendered stale until relays echoed the update. nostrService.handleEditVideoSubmit now ingests the edited event via ingestLocalVideoEvent (newest-wins replace in the active store + videos:updated), so grids show the new title/thumbnail/etc. immediately. Test: tests/services/nostr-service.test.mjs (+1).

53. Channel-profile link in the video player modal doesn't work (BUG) — FIXED 2026-07-02

• FIXED 2026-07-02. Event-name mismatch: VideoModal.handleCreatorNavigation dispatched "navigate:profile", but ModalManager only listens for "creator:navigate" → the click went into the void (same class as the old action:embed bug). Renamed the dispatch to "creator:navigate" and threaded the modal's own creator pubkey through: the handler now passes event.detail.pubkey to app.openCreatorChannel(pubkey), and routerCoordinator.openCreatorChannel accepts an optional pubkey (falls back to the active video's creator). Tests: tests/video-modal-controllers.test.mjs (+2 — dispatches creator:navigate with the pubkey, never the dead event; no-op without a pubkey). Lint + build green.

54. Like / dislike buttons in the video player modal don't work (BUG) — FIXED 2026-07-02 (only live VERIFY remains)

• The reaction (like/dislike) buttons in the player modal are unresponsive / don't persist. Audit reactionController wiring into the video modal (event binding, active-signer availability, publish path). Note: reactions require signing — verify this isn't another "lost signer after refresh" (#57) surfacing as a dead button; if so, prompt to unlock rather than silently no-op.
• Lost-signer variant addressed 2026-07-01. ReactionController.handleReaction now runs the ensureEncryptionCapableSigner gate (need:"sign") before publishing, so a reloaded nsec session re-unlocks with one passphrase prompt instead of the reaction silently failing (rolled-back button + generic error). Tests: tests/reaction-signer-gate.test.mjs. Still VERIFY on unstable whether any residual dead-button behavior remains (event binding / pointer availability), which would be a separate wiring bug from the signer issue.
• The actual dead-button bug — FIXED 2026-07-02. VideoModal.handleReactionClick never derived the reaction or reached the publish path: it called this.reactionsController.handleReaction(event) — a method that does NOT exist on the video-modal reactions controller (which only binds buttons + does optimistic UI), passing the raw DOM click event as the "reaction". So the #54 signer gate was correct but unreachable. Now handleReactionClick derives +/- from the clicked button (#modalLikeBtn/#modalDislikeBtn) and dispatches video:reaction — the event ModalManager already routes to app.handleVideoReaction → reactionController.handleReaction (which signs/publishes + runs the signer gate). Tests: tests/video-modal-controllers.test.mjs (+2 — derives the reaction and dispatches; unrelated target is a no-op). Lint + build green.

55. Video-grid event caching — faster loads, cache-first + merge-new (PERF / UX)

• VERIFIED 2026-07-02: event caching already exists — no gap. Traced end to end: allEvents (incl. ingested NIP-71 videos via nip71IngestService.injectVideo) is persisted to IndexedDB (bitvid:eventsCache:v1, PersistenceManager + EventsCacheStore), restored on boot (restoreLocalData), and loadVideos + the channel grid render cache-first then merge-new (never blank+refetch). Bullets 1–2 were already built; the remaining slowness is only a genuinely-cold first visit, already bounded by the coalescing/timeout/parity fixes.
• Media caching part 1 — Cache-Control on uploads — DONE 2026-07-02. computeCacheControl (js/storage/s3-multipart.js) already stamped most media immutable; added the missing webp/avif/ico and .torrent (safe: buildR2Key namespaces by infohash → content-addressed). Playlists (m3u8/mpd) stay short-lived. Exported + tested (tests/storage-cache-control.test.mjs, 3).
• Media caching part 2 — SW image cache — DONE 2026-07-02. sw.min.js now serves cross-origin images (thumbnails/avatars/banners — the hosts bitvid doesn't control headers for) stale-while-revalidate from bitvid-images-v1 (Cache API): instant on revisit, background refresh self-heals changed images, LRU-capped at 300 entries, quota errors fail open (drop the cache, never break image loading), and every handler error falls back to plain fetch. The activate handler's wipe-all now preserves the current image cache (old versions + other caches still wiped). Same-origin assets are untouched (they ride the host HTTP cache + dist cache-purge pipeline). app._initServiceWorker now registers the SW at boot when none exists (same path/scope/options as webtorrent.js's setupServiceWorker, so playback's later register() is a no-op on the same registration). SW_VERSION bumped. Tests: tests/sw-image-cache.test.mjs (6 — runs the REAL sw.min.js in a VM sandbox: cold/warm/offline/opaque flows, non-interception, activate preservation).
• VERIFY on unstable: revisit a feed/channel — thumbnails + avatars should load instantly from the SW cache (DevTools → Network shows "(ServiceWorker)"); after an SW update the image cache survives. Optional follow-up: pull-to-refresh / manual refresh affordance for forced re-fetch (nice-to-have; background merge-new already keeps grids fresh).

56. Upload & edit modals: prompt to unlock storage (PIN popup), don't just error (UX)

• DONE 2026-07-03. All three locked-storage file-pick paths now unlock INLINE and continue with the same pick, via the shared signer gate (app.ensureEncryptionCapableSigner: silent kept-unlocked restore, else ONE passphrase prompt with the keep-unlocked checkbox): - Upload modal, video file: was showError("Please unlock storage…") → now ensureStorageUnlockedForUpload() (new js/ui/components/uploadModalStorageUnlock.js; UploadModal delegates — also absorbed promptStoredNsecUnlock for the file-size budget). - Upload modal, thumbnail: was a SILENT no-op → now the same inline unlock; a refused unlock resets the picker (placeholder + URL input). - Edit modal, "Replace file" (video + thumbnail): was "Unlock your storage in the profile modal, then try again" → ensureUploadable (js/ui/components/editModalUpload.js) now gates the signer, runs storageService.unlock, and re-resolves the connection in-gesture (extension signers still get the permission request first). Cancel / bad-passphrase abort quietly (the gate toasts a wrong passphrase itself); other failures fall through to the pre-existing messaging. ensureSigner is threaded through initUploadModal / initEditModal from app. Tests: tests/upload-edit-storage-unlock-gate.test.mjs (12). Lint + build green.
• Combine with 51: satisfied by the gate itself — it restores the cached keep-unlocked key first, so an unlocked-once session never re-prompts.
• VERIFY on unstable: locked nsec session → pick a video file in the upload modal (one PIN prompt, upload proceeds), pick a thumbnail (same), and use Edit → Replace file (same). Cancel each prompt once — no error spam, picker state restored.

57. nsec / NIP-46 accounts: encryption ops fail after refresh — re-prompt, don't blanket-error (BUG)

• Symptom: adding/editing a hashtag on an nsec-logged-in account errors with "Connect a Nostr signer that supports encryption before managing hashtag preferences." Same class blocks other NIP-44/encryption list ops (subscriptions, blocks, DMs) after a reload.
• Root cause (likely #36): the reload dropped the in-memory nsec signer, so nip44Encrypt/nip44Decrypt aren't available even though the user "looks" logged in. The guard then emits a blanket "connect a signer that supports encryption."
• Fix intent: ALL signing/encryption functions must work across ALL signer types (nsec / NIP-46 / NIP-07). When the op needs a locked nsec key, prompt to re-enter the PIN/passphrase to re-unlock the signer (reuse #36's unlock flow) instead of a dead-end error. Cross-ref #48 (fluent switching) and the account-switch refresh work (commit 87af650b). Audit every "signer that supports encryption" guard and route it to the unlock prompt when a saved nsec key exists for the active pubkey.
• Shared gate built + hashtags wired — DONE 2026-07-01. New reusable app.ensureEncryptionCapableSigner({ pubkey, need, promptMessage }) (js/app.js, pure branching in js/nostr/ensureSignerDecision.js): checks the active signer's capabilities; if it can't encrypt/sign AND a matching locked nsec key exists for the account, prompts once for the passphrase and re-unlocks the signer app-wide via unlockStoredSessionActor (one unlock re-enables every flow until the next reload). Never unlocks a different account's key (pubkey-mismatch guard). Exposed to the profile modal as services.ensureEncryptionCapableSigner. Hashtag add/edit now routes through it (ProfileHashtagController.persistHashtagPreferences): a cancelled prompt silently aborts, a bad passphrase shows its own toast, and publish never runs until the signer is confirmed. Tests: tests/ensure-signer-decision.test.mjs (9), + 2 wiring tests in tests/profile-modal-controller.test.mjs. Lint + build green.
• Fast-follows wired — DONE 2026-07-01. All remaining signing/encryption call sites now route through ensureEncryptionCapableSigner, short-circuiting only on the user-driven outcomes (cancel / bad-passphrase) so every other case still falls through to the flow's own error handling: - Reactions (#54): ReactionController.handleReaction gates before the optimistic update with need:"sign" (kind-7 reactions don't need encryption). Tests: tests/reaction-signer-gate.test.mjs (3). - Blocks: authSessionCoordinator.handleProfileBlocklistMutation (need:"encrypt", NIP-04 mute/block lists). - Subscriptions: the channel-profile Subscribe/Unsubscribe toggle (js/channelProfile.js, need:"encrypt", kind-30000). - DM send: both composers — handleSendProfileMessage and handleDmAppShellSendMessage (need:"encrypt", NIP-17/NIP-04). Lint + build + related suites (decision, reaction, DM, profile-modal, switch) green.
• VERIFY on unstable: with an nsec account, reload, then (a) add a hashtag, (b) like/dislike a video, (c) block/unblock a creator, (d) subscribe to a channel, (e) send a DM — each should show ONE passphrase prompt (not a blanket error), then work; the single unlock should cover the rest until the next reload.

58. Remove NIP-71 authoring UI from upload/edit modals (clean UI)

• DONE 2026-07-02. Decision (maintainer): bitvid authors kind-30078 and MIRRORS to NIP-71 — it does not author NIP-71 directly — so the NIP-71 form sections were confusing dead weight. Verified before removing: the My Videos mirror (buildNip71MirrorEvent) derives EVERYTHING from the bitvid note (title/url/magnet/thumbnail/description, duration+dims auto-captured at upload, contentWarning from the NSFW toggle, hashtags), and the only consumer of the form's NIP-71 metadata (publishNip71Video) is gated behind FEATURE_PUBLISH_NIP71: false. Removed: upload modal's "NIP-71 Technical" (content warning / duration / summary+Customize) + IMETA variant editor; edit modal's kind selector, published_at, alt, duration, content warning, summary, IMETA, text tracks, segments, participants, references. KEPT: hashtags in both modals (they feed hashtag feeds, the suggestion chips, and the mirror's t tags) and the web seeds / torrent (xs) inputs (bitvid-note fields, not NIP-71). Compatibility: existing videos' NIP-71 extras are PRESERVED on save — EditModal keeps the full stored metadata (storedNip71Metadata) and merges the edited hashtags into it instead of replacing it with the reduced form's empty output. Also fixed a latent bug this exposed: nip71Edited compared a normalized submit-side copy against an unnormalized original (publishedAt string vs timestamp), so every save looked "edited"; both sides now share normalizeCollectedNip71. Tests: +2 in tests/edit-modal-submit-state.test.mjs (extras survive a hashtag edit; untouched save → nip71Edited false).
• Post-launch cleanup (Option B, optional): delete the dormant FEATURE_PUBLISH_NIP71 auto-publish path, the unused Nip71FormManager sections (imeta/text-track/segment/p/r + scalar inputs), and the nip71 plumbing through videoNotePayload that only the removed forms fed. RevertModal keeps its READ-ONLY use of the manager (version-history display).

59. First-run onboarding experience (guided tour) — plan in docs/onboarding-plan.md

• Phase 1 BUILT 2026-07-02. Guided tour for fresh logins: spotlight scrim with a cutout over each step's anchor + a pulsing accent-glow ring (--color-accent/--color-accent-strong theme tokens), anchored popover with Back/Next/Skip + progress dots, keyboard nav (arrows/Esc). Hand-rolled engine (js/ui/onboarding/tourEngine.js, no deps) positioning via CSS custom properties; steps with missing anchors auto-skip (responsive-safe). Steps: welcome → feeds (#sidebar) → subscriptions → upload → profile → final card with "Set up storage" / "Connect wallet" deep-links into the profile panes. Offered once per pubkey per device (bitvid:onboarding:v1, settingsRestorePrompt-style flags), triggered 3.5s after first login, re-launchable via "Take the tour" in the profile modal footer. Tests: tests/onboarding-tour.test.mjs (5).
• VERIFY on unstable: log in with a pubkey that has never completed the tour → tour appears ~3.5s after the feed renders; spotlight glow follows each anchor; Skip/Esc dismisses and never re-offers; "Take the tour" replays it; the final card's buttons open the storage/wallet panes.
• Phase 2: "Getting started" checklist card (relays ✓, follow 3 channels ✓, storage ✓, wallet ✓, first upload ✓) — persistent + dismissible.
• Phase 3: empty-state upgrades (teach + CTA; suggested channels from trust seeds in empty For You / Subscriptions).
• Phase 4: fresh-npub bootstrap — "Create account" via the existing generate provider with a REQUIRED key-backup step, then inline kind-0 profile setup (name + avatar), then the tour.

60. Audio tab — podcasts / music / audio support (FUTURE) — full plan in docs/audio-integration-plan.md

Reported 2026-07-09. Today an audio note (e.g. a podcast published as a native kind-30078 with imeta … m audio/ogg + an .ogg URL) leaks into the video grid and can't play: convertEventToVideo accepts it (it has a url), VideoCard gives it a data-play-url, but the source is audio-only. bitvid maps .ogg → video/ogg and hands it to a <video> element → black frame + audio on Chrome/FF, or MEDIA_ERR_SRC_NOT_SUPPORTED on Safari/iOS. There is no <audio>/podcast player. The NIP-71 ingest guard (nip71IngestAdapter.js — "exclude audio/image/etc.") only covers ingested kinds 21/22/34235/34236, not the native 30078 path. Real example: event 95053d75… "Nostr Compass Podcast #20" (pubkey b7ed68b0…).

• Near-term (launch hygiene) — DONE 2026-07-09. convertEventToVideo (js/nostr/nip71.js) now marks audio-only notes invalid (reason "audio-only source (no video)") so every feed/grid ingestion path that already drops invalid filters them out: main feed buffer (videoEventBuffer.js:145), author/channel batch fetch (client.js:4192), local ingest (client.js:4500). Audio-only = no magnet AND no imeta m video/* AND (an imeta m audio/* variant OR an unambiguous audio URL .mp3/.m4a/.aac/.wav/.flac/.opus/.oga/.weba). .ogg is NOT filtered on extension alone (ambiguous → video/ogg) — only when an imeta m audio/* says so. A video imeta variant always wins. Tests: tests/video-schema-and-conversion.test.mjs (+5, 8/8). NOTE: the direct open-by-nevent path (client.js:4129) still resolves an audio event on purpose — an explicit link should still load; only feeds are filtered.
• The feature: a dedicated Audio sidebar tab (podcasts / music / audio) with its own player. Detect audio/* sources and render an <audio> UI (poster from the image/thumbnail tag + transport controls, duration, seek) instead of the <video> element. This event already carries the metadata a good audio UI wants: title, image, duration, summary, channel, show, plus podcast t tags — so cards can show cover art + show/episode.
• Discovery/schema — audio kinds & NIPs to support (surveyed 2026-07-09). bitvid supports NIP-71 video (21/22/34235/34236) + native 30078; nothing audio-specific yet. Standard audio surfaces bitvid does NOT support: - NIP-A0 Voice Messages — kind 1222 (root) + kind 1244 (reply). Native short audio notes: content = URL to an audio file (rec. audio/mp4/.m4a, ≤60s). The closest thing to a first-class "audio note." Best Audio-tab target. - NIP-73 External Content IDs — Podcast GUIDs. i/k tags: podcast:guid (feed), podcast:item:guid (episode), podcast:publisher:guid. THE bridge to Podcasting 2.0 / PodcastIndex / Fountain — lets bitvid reference real podcast feeds/episodes, not just bespoke re-uploads. Key for "podcast feeds." - NIP-53 live audio — kind 30311 + kind 30312 (audio rooms/spaces). Live audio overlaps #16 (which should own live video and audio). - NIP-71 audio variants — imeta m audio/* + waveform (audio-only) are already in the NIP-71 spec bitvid parses, so audio-as-a-variant is close. - De-facto today: the podcasts we currently filter (Nostr Compass, Nodesignal) are native kind-30078 with imeta m audio/* — a bespoke re-upload, NOT a standard audio kind. - Non-standard music (Wavlake / Stemstr) use app-specific custom kinds, not ratified NIPs → treat as opt-in integrations, not core. Decide the canonical audio signal (support 1222/1244 + native 30078 m audio/* to start; NIP-73 refs + NIP-53 live audio later); consider a t marker (audio/podcast/music) parallel to t:video for a clean feed filter, and gate the tab behind its own config flag (mirrors the streaming tab in #16). NOTE: earlier drafts said "NIP-54-style podcast events" — WRONG, NIP-54 is Wiki; the real refs are NIP-73 (podcast GUIDs) + NIP-A0 (voice messages).
• Channel-profile category tabs (requested 2026-07-09). The channel profile should carry the same media categories as a tab strip so a creator's page stays neat and self-explanatory instead of mixing everything into one grid: - Videos (current default — kind 30078 video / NIP-71 21+34235), - Audio (audio-only notes — podcasts / music; the #60 audio player), - Live / Streams (NIP-53 kind 30311 — see #16; show live now + past), - Shorts (NIP-71 kind 22 short-form vertical — see #16). Each tab is its own category playlist that only loads/renders when that tab is selected (lazy per-tab fetch, no cross-contamination — the audio guard keeps Audio out of Videos and vice-versa). Only show a tab when the creator actually has content of that type (hide empty categories). Mirror the same tab set on the main feed/sidebar so the sidebar category ↔ channel tab stay consistent.
• Profile modal: "My Videos" → "My Content" with tabs (requested 2026-07-09). The creator-side management view (js/ui/profileModal/MyVideosController.js) is the owner mirror of the channel-profile tabs: rename the pane/label to My Content and give it the same category tabs (Videos / Audio / Live / Shorts), each listing only that category's notes. Per-tab keeps the management rows (edit, delete/undelete, mirror-to-apps toggle, storage status) scoped and uncluttered. Reuse the shared category resolver below so an item shows under the same tab here as on the public channel. Keep the empty-category hiding, or show an empty-state CTA ("Publish your first audio note") per tab.
• Shared category model: define one media-category resolver (video | audio | live | short) derived from kind + imeta m + t markers, used by the sidebar feeds, the public channel tabs, AND the profile-modal "My Content" tabs, so a note lands in exactly one category everywhere. This is the natural home for the #17 unified media grid.
• Cross-refs: shares the "new media type behind a sidebar tab + config flag" shape with #16 (live streams / NIP-53, incl. kind-22 shorts) and the #17 unified media grid — plan the category resolver + per-tab loaders together so video / audio / live / shorts don't each grow a bespoke fetch, and so the channel-profile tabs and sidebar tabs share one source of truth.

61. Bitcoin Connect — smooth NWC wallet connect UX — full plan in docs/bitcoin-connect-plan.md

Requested 2026-07-09. Add Alby's Bitcoin Connect (getalby/bitcoin-connect, bitcoin-connect.com) as a polished "connect your wallet" modal for NWC, feeding bitvid's EXISTING NWC pipeline; keep manual URI entry as the backup/advanced path.

• Verified feasible: BC's NWC connector exposes the raw pairing URI via provider.client.nostrWalletConnectUrl (on onConnected), which flows straight into nwcSettingsService.validateWalletUri → the existing per-npub store. No change to how bitvid pays or stores — one new way to obtain the same string.
• Decisions D1–D6 in the plan (recommendations: vendor + lazy import; persistConnection:false + disconnect() after extract; NWC-only connector; least-privilege requestMethods incl. pay_invoice; Connect = primary CTA with manual under "Advanced"; FEATURE_BITCOIN_CONNECT flag, off = no trace).
• Security: NWC URI is a bearer SPENDING secret — never log it; pin+vendor the (Alpha) lib; re-validate the extracted string; payment invariants (PLATFORM_FEE_PERCENT=30, preimage verify, no pay_invoice auto-resend) untouched.
• Phased + flag-gated: Phase 0 flag+vendor, Phase 1 connect button, Phase 2 polish (balance/reconnect), Phase 3 optional WebLN path for Alby-extension/Hub.