Root cause of "a known video never shows on the channel": the video was a
whitelisted creator's NIP-71 note that lives ONLY on nos.lol, but the channel
fetch queried nostrClient.relays — the user's CAPPED NIP-65 read set — which
dropped nos.lol, so we never queried the one relay that had it. Confirmed by
per-relay probe: snort/damus/primal returned 0, nos.lol returned the 2 videos.
loadUserVideos now unions the user's relays with DEFAULT_RELAY_URLS (nos.lol,
damus, primal, snort) for the scoped channel fetch, so a creator's videos on
any bundled default relay are found regardless of the read cap. Channel pages
are a deliberate request for one creator, so the slightly wider fan-out is fine.
Co-Authored-By: Claude Opus 4.8 <[email protected]>
Temporary dev-mode logging to pinpoint why a known video (e.g. a whitelisted
creator's NIP-71 video) never renders on their channel wall:
- loadUserVideos logs the relay set size, relay event count + kind breakdown,
and the cache event count.
- buildRenderableChannelVideos logs per-stage counts: input → converted →
uniqueById → byRoot → afterDeleted, plus drop counts for blacklist/canAccess
and the final render count.
devLogger.info → visible in dev mode only (localhost), no prod noise.
Co-Authored-By: Claude Opus 4.8 <[email protected]>
The channel video grid felt slow and often flashed "No videos" because, when
the warm cache was cold (direct URL, a new tab, or an author not in your feed),
it fell back to a bespoke one-shot pool.list per relay with an 8s timeout,
AWAITED ALL relays before rendering once, and showed "No videos" whenever that
came back empty (which a timed-out/flaky relay does). "My Videos" is fast
because it reads the warm shared cache and only refetches on demand.
Rework loadUserVideos:
- Progressive render: paint the grid as each relay/source returns (deduped,
coalesced, serialized re-render) instead of blocking on the slowest relay.
- Reliable fetch: also route through nostrService.fetchVideosByAuthors — the
same proven path My Videos uses — which streams into the shared cache, so
this grid, its revisits, and every other grid benefit.
- No premature empty: mid-flight renders never pass allowEmptyMessage; the
"No videos" message is shown only on the final render, after every source
has genuinely settled. The cache-first paint is preserved.
- check-file-size: bump channelProfile grandfather for the growth.
Co-Authored-By: Claude Opus 4.8 <[email protected]>
- adminBadge.js: add applyAdminRing(el, id) for surfaces that already place the
star on a specific element and just need the ring.
- comments: ring + star on admin authors' avatars; round the comment avatar box
so the ring reads as a circle.
- channel page: ring the inner rounded avatar box (star already on the wrap).
- Notification dots: red dot on the profile modal's Admin nav tab and on the
Submissions subtab button when there are pending submissions, so admins know
where to look. profileModalController.setSubmissionsUnreadIndicator toggles
both (Admin nav dot gated on the tab being visible); driven from
applyProfileNotificationDot off app._submissionsPending.
Co-Authored-By: Claude Opus 4.8 <[email protected]>
Show a small gold "verified admin" star in the corner opposite the red
notification dot whenever a rendered profile belongs to a bitvid admin
(the super admin or a current list editor).
- adminBadge.js (new): isAdminActor(hex|npub) sync check against
accessControl, and applyAdminStar(container, id) which adds/removes a
single `.admin-star` in a non-clipped, positioned container. Idempotent.
- CSS: `.admin-star` (top-left gold disc, mirrors the top-right dot),
`.dm-avatar-wrap`, and position:relative on the comment avatar wrapper.
- Profile button: app.refreshAdminStar() lights the logged-in user's star;
re-runs on login/logout and on accessControl.onEditorsChange (so a
late-loading editor list still resolves).
- Comments: star on comment-author avatars (commentNodeFactory).
- Channel page: wrap the clipped avatar and star the channel owner.
- DMs: Avatar gains an opt-in adminId — only admin avatars get wrapped so
non-admin rows are byte-identical; ContactRow passes the peer pubkey.
- tests: admin-badge unit coverage (recognition, idempotency, removal).
Co-Authored-By: Claude Opus 4.8 <[email protected]>
- constants.js: FEATURE_PLAYLISTS (default OFF) so nothing is user-visible until
the whole playlist UI ships; flip to preview on unstable.
- js/channelPlaylists.js: wireChannelPlaylists(pubkey) fetches the creator's
playlists (facade) and renders a responsive row of cards (thumbnail + video
count + title) linking to `#view=playlist&pubkey=…&id=…`. Hidden when the flag
is off, no playlists, or the container is missing; a nav-token guards against a
stale fetch resolving after a channel switch. DOM built with textContent (no
innerHTML). Kept out of the 5729-line-capped channelProfile.js.
- channelProfile.js: one-line wireChannelPlaylists(currentChannelHex) hook next
to wireChannelZapTotal (no-op while the flag is off).
- views/channel-profile.html: #channelPlaylistsSection above the video grid.
- tailwind.source.css: .playlist-grid / .playlist-card* (token-only; responsive
via @apply like .bv-grid-video).
Lint + build clean. The playlist view the cards link to lands next.
Co-Authored-By: Claude Opus 4.8 <[email protected]>
The store now supports p: (profile/channel) pointers — every zap tagged to a
creator pubkey (direct profile zaps AND zaps to their videos, both carry a `p`
tag), from 9735 receipts + verified tallies:
- pointerKey accepts "p"; new profilePointer(pubkey) helper.
- runBatch batches p: pointers into a #p filter; both folds count #p-tagged
events (deduped by payment_hash like a:/e:).
- Channel page: a "⚡ N sats zapped" total under the lightning address, wired
to the store via js/channelZapTotal.js (own module for channelProfile.js's
size budget), hidden until nonzero.
Completes the D2 video + profile scope; the bitvid-native zap tally feature is
now feature-complete (publish + count + chart + video + profile). Tests:
profilePointer/pointerKey + #p counting in tests/zap-totals.test.mjs. Lint
(size cap ok) + build green.
Co-Authored-By: Claude Opus 4.8 <[email protected]>
Channel-profile video cards rendered blank view counts. The main feed subscribes
each card's [data-view-count] element to the shared view counter
(VideoListView.ensureViewCountSubscription / registerVideoViewCountElement), but the
channel-profile grid renders its own VideoCards and never did — so nothing ever
populated the element.
Add js/channelViewCounts.js (subscribeChannelCardViewCount /
clearChannelCardViewCounts) and call it from channelProfile.js after each card's
getRoot(); teardown runs in clearChannelVideoCardRegistry (already invoked on grid
re-render / channel close). Logic lives in a new module so channelProfile.js stays
under its size cap.
On "are they counted correctly?": yes — this subscribes to the SAME batched
kind-30079 view-count transport the feed uses (one shared subscription + the deduped
cache), so the channel now shows the exact same counts the feed does. The counting
itself was never the issue; the channel grid just wasn't displaying it.
Tests: tests/channel-view-counts.test.mjs (3 — non-blank label, safe no-ops,
idempotent teardown). Lint + build green.
Co-Authored-By: Claude Opus 4.8 <[email protected]>
Fast-follows to the ensureEncryptionCapableSigner gate: every remaining
signing/encryption flow now re-unlocks a reloaded nsec signer with one passphrase
prompt instead of dead-ending. Each call site short-circuits ONLY on the
user-driven outcomes (cancel / bad-passphrase); every other case falls through to
the flow's own existing error handling, so non-nsec signers (e.g. an unresponsive
NIP-07 extension) behave exactly as before.
- Reactions (#54): ReactionController.handleReaction gates before the optimistic
update with need:"sign" (kind-7 reactions don't need encryption) — fixes the
"like/dislike does nothing" that was a rolled-back publish on a lost signer.
- Blocks: handleProfileBlocklistMutation (need:"encrypt", NIP-04 mute/block lists).
- Subscriptions: the channel Subscribe/Unsubscribe toggle (need:"encrypt", kind 30000).
- DM send: both composers — handleSendProfileMessage and handleDmAppShellSendMessage
(need:"encrypt", NIP-17/NIP-04).
Reactions get the gate via a new ensureSigner callback on ReactionController; the
modal flows use the services.ensureEncryptionCapableSigner already exposed.
Tests: tests/reaction-signer-gate.test.mjs (3 — cancelled/bad-passphrase block
publish, ok proceeds, asserts need:"sign"). Related suites (decision, DM, profile
modal, switch delegators) green. Lint + build green.
Co-Authored-By: Claude Opus 4.8 <[email protected]>
Three fixes for "the channel grid loads slowly and not all videos come in even
when they show on other grids":
1. Race condition (primary "won't load" cause). loadUserVideos() bumps a shared
currentVideoLoadToken and only renders if its token is still current. A burst
of refresh triggers — e.g. the NIP-71 ingest flushing repeatedly right after
a channel opens (RELAY STORM in the logs) — supersedes every in-flight load
before it paints, so the grid stays on "Loading videos…". Add
requestChannelVideoLoad(): while a load for the same channel is in flight, a
refresh flags a single trailing rerun instead of starting a competing load;
navigation still starts immediately. All three call sites routed through it.
2. Slowness from hung relays. The per-relay pool.list() fan-out had no timeout,
so one relay that never sends EOSE stalled the merged render. Add
raceListWithTimeout() (exported, pure) bounding each list() to 8s, resolving
to [] on timeout/rejection.
3. Completeness/parity. The channel grid sourced only nostrClient.allEvents + a
scoped relay fetch, which can diverge from the shared feed cache the other
grids render from. getCachedChannelVideoEvents() now also unions the author's
videos from nostrService.getActiveVideosByAuthors() (same videosMap-backed
author index), so a video shown on another grid is present here by construction.
Tests: tests/channel-relay-timeout.test.mjs (5).
Co-Authored-By: Claude Opus 4.8 <[email protected]>
loadUserVideos rendered only the live relay fetch, and the render REPLACES the
grid container. So when a relay holding a creator's video transiently failed or
EOSE'd late, that video disappeared from the wall even though it was already
known in memory/cache — the "channel doesn't pull in all of a creator's videos"
bug (#20, symptom 1).
Union the live events with the already-known author events
(mergeChannelVideoSources, live wins on id collision) before building the
renderable list, so the rendered set is a superset and can't shrink on a
transient relay gap. Existing dedupe-by-root + access/delete filtering still
decide precedence downstream, so newer versions and deletions still win.
Helper + tests live in channelProfileVideos.js (channelProfile.js is at its
size cap); the call site stays net-zero. Streaming/first-relay-wins render is
still the separate 17d UX follow-up.
Regression: tests/channel-video-merge.test.mjs.
Co-Authored-By: Claude Opus 4.8 <[email protected]>
A cold hard-refresh on a profile previously sat on "Loading videos…" for
~5s — the optimistic in-memory cache is empty on cold start (ingest hasn't
injected yet) and the grid waited on relay connection.
Now channelProfileVideos.js persists the last-rendered wall per author
(localStorage bitvid:channel-videos:v1) and loadUserVideos paints it
immediately on cold load, before relays connect; the live fetch then
replaces it. Bounded (60 videos/channel, 20 channels LRU-evicted) and
strips the heavy raw `tags` array. Same proven pattern as the main feed's
optimistic cache.
Closes TODO 17d per-channel cache. Tests + mutation-verified (round-trip,
tag-strip, per-channel + channel-count caps). 1267/1268 unit (known flake).
Co-Authored-By: Claude Opus 4.8 <[email protected]>
getCachedChannelVideoEvents early-returned kind-30078-only rawEvents and
skipped allEvents, so a creator's ingested NIP-71 videos didn't show in the
optimistic (pre-fetch) render. Now it merges raw 30078 (first, so they win
the downstream id-dedupe) with processed allEvents (which holds ingested
foreign videos) → the wall paints instantly on revisit / when the feed
already loaded that author. Cross-ecosystem dedupe collapses any overlap.
Also records TODO 17d (unified grid loading follow-ups): streaming
channel/search fetch, per-channel persisted cache, My Videos NIP-71
inclusion, and consolidating bespoke loaders behind one shared streaming
grid source.
1262/1263 unit (known UploadModal flake).
Co-Authored-By: Claude Opus 4.8 <[email protected]>
Phase 1 of the on-boarding plan, and the shared layer for unified grid
loading. A video that exists as both a bitvid kind-30078 note and a NIP-71
mirror/original previously could appear twice (e.g. independent dual-posts).
js/utils/videoDeduper.js: collapseCrossEcosystem() groups events by a
per-author identity (fileSha256 / originalFileSha256 / infoHash, plus an
`eid` namespace that links an on-boarded note's `importedFrom` to the
original foreign event) via union-find, and keeps the bitvid-native version
(else newest). dedupeVideos() = root-dedup THEN cross-ecosystem collapse.
Routed through the shared chokepoint app.dedupeVideosByRoot (playback
coordinator), so the feed stage, channel profile, and search all collapse
duplicates identically — "show one, prefer bitvid" everywhere. Channel
fallback path updated too.
Limitation (documented): hash-less independent dual-posts can't be matched
until the bitvid side carries on-board provenance (Phase 2).
Tests + mutation-verified (prefer-bitvid, per-author identity, infohash,
provenance link, root+cross composition). 1262/1263 unit (known flake).
Co-Authored-By: Claude Opus 4.8 <[email protected]>
The channel-profile grid fetched only kind-30078, so a creator's NIP-71
videos (incl. their Nostube cross-posts) appeared in the main feed via
ingest but were absent from their profile wall.
New js/channelProfileVideos.js:
- buildChannelVideoFilters(pubkey): native (kind 30078, #t=video) + NIP-71
(kinds 21/22/34235/34236) filters for the author.
- convertChannelEvent(entry): routes NIP-71 kinds through
buildVideoFromNip71Event (which rejects bitvid's own outbound mirrors so
they don't duplicate the canonical note); kind-30078 uses the standard
converter.
channelProfile.js now uses these (net fewer lines, stays under size cap).
Existing buildRenderableChannelVideos dedupe-by-root + canAccess handle
precedence and whitelist/blacklist gating, so foreign videos inherit the
same gating as native ones.
Closes pre-launch TODO 17b. Tests + mutation-verified (NIP-71 routing,
mirror skip, dual-filter build). 1253/1254 unit (known UploadModal flake).
Co-Authored-By: Claude Opus 4.8 <[email protected]>
- Refactored `js/channelProfile.js` to use `pMapSettled` from `js/utils/asyncUtils.js`, fixing both the concurrency issue (P1) and the file size lint failure.
- `pMapSettled` replaces a bulky inline `pMap` wrapper, reducing code volume.
- Ensures `js/channelProfile.js` stays within its grandfathered line count limit (5579 lines).
Co-authored-by: PR0M3TH3AN <[email protected]>
- Introduce `js/constants.js` with semantic time constants (e.g., `ONE_MINUTE_MS`, `STANDARD_TIMEOUT_MS`) and feature-specific TTLs.
- Export `KIND_MUTE_LIST` from `js/nostrEventSchemas.js` to standardize NIP-51 mute list kind usage.
- Refactor `js/state/cache.js`, `js/nostr/cachePolicies.js`, `js/channelProfile.js`, and various services to use centralized constants instead of hardcoded magic numbers.
- Update `js/nostr/relayConstants.js` to derive values from the shared time constants.
- Replace duplicate definitions of timeouts and retry delays across the codebase.
Co-authored-by: PR0M3TH3AN <[email protected]>
- Replaced `NostrClient.rawEvents` standard Map with `EventsMap`
- Implemented `EventsMap` to maintain an author-based index
- Updated `js/channelProfile.js` to use `getEventsByAuthor` for efficient lookup
- Added unit tests for `EventsMap`
- Added benchmark script verifying ~15x performance improvement (637ms -> 41ms for 1M events)
Co-authored-by: PR0M3TH3AN <[email protected]>
Removes the call to `app.persistWatchHistoryMetadataForVideo` in `renderChannelVideosFromList` within `js/channelProfile.js`. This function was identified as a no-op (delegating to a deprecated empty method), adding unnecessary overhead to the rendering loop.
Benchmark results (100M iterations):
- With call: ~1278ms
- Without call: ~88ms
- Improvement: ~14x speedup in the tight loop simulation.
Co-authored-by: PR0M3TH3AN <[email protected]>
- Implemented optimistic UI updates for the channel subscribe button to improve responsiveness.
- Fixed a race condition in `js/subscriptions.js` and `js/services/hashtagPreferencesService.js` where lists were wiped on refresh due to `profileCache.activePubkey` not being initialized in time. Now using `profileCache.getProfileData(pubkey, ...)` to ensure the correct cache entry is loaded.
- Validated with targeted unit tests.
Co-authored-by: PR0M3TH3AN <[email protected]>
- Added info buttons to Most Recent, Subscriptions, History, Channel Profile, Search, and Explore views
- Attached popovers with descriptions of feed filtration methods
- Used `attachFeedInfoPopover` helper for consistent implementation
- Verified with Playwright script (verified popover visibility and text content)
I modified `js/channelProfile.js` to implement the logic that toggles the "Send" button to "Done" and closes the dialog when clicked. Additionally, I updated `js/ui/zapController.js` to prevent the form from resetting entirely on success, which preserves receipts; instead, it now manually clears the comment and sets the completed state.
These changes ensure consistent "Done" button behavior across both the Channel Profile and Video Modal zap interfaces. I also included minor `package.json` updates for linting dependencies.
