View events are always signed by the anonymous session actor (privacy for the
public view counter). publishView read the watched-actor from that view event's
pubkey, so a logged-in user's new watches were enqueued — and republished via
updateWatchHistoryList — under the SESSION actor. The read path queries
authors:[loggedIn] only, so those session-authored months were never
discovered: newly watched videos never appeared in the synced watch history
(e.g. a 2026-06 month that never showed up despite watching June videos).
Fix:
- publishView now resolves the watch-history actor to the logged-in pubkey
first, falling back to the view event / session actor only when logged out.
- A watch is flagged session/local-only only when nobody is logged in
(previously it was flagged whenever the view actor differed from the
logged-in user, which was always true given anonymized views).
Adds tests/watch-history-records-under-login.test.mjs (mutation-verified: both
the actor-resolution and the session-flag fixes are independently load-bearing).
Co-Authored-By: Claude Opus 4.8 <[email protected]>
The other half of the synced-vs-local design: for logged-out / session
(local-only) actors, watch history lives in a localStorage queue (loadLatest ->
collectQueueItems), but snapshot no-op'd for local-only actors — so a removal
never touched the queue and the item reappeared on reload (same symptom as the
logged-in bug, different layer).
Now a REPLACE snapshot for a local-only actor rewrites the local queue to exactly
the provided items (new replaceLocalQueue helper): removals prune it, an empty
replace clears it. Normal watch-tracking adds still flow through the queue via
recordVideoView, unchanged.
Tests + mutation-verified: local replace seeds then prunes the queue; empty
replace clears it. Reverting to the no-op fails both.
Build + full lint green (watchHistoryService under file-size budget).
Co-Authored-By: Claude Opus 4.8 <[email protected]>
Root cause of "watch history delete does not work at all": the removal paths
call watchHistoryService.snapshot(remaining, …), but snapshot published via
updateWatchHistoryList WITHOUT replace:true. The default merges incoming items
with the existing cached list, so the just-removed item was merged straight back
and the deletion silently had no effect. Removing the LAST item was worse: an
empty list fell through to republishing the pending queue instead of clearing.
- snapshot now honors options.replace: forwards it to updateWatchHistoryList,
treats an explicit empty replace as a clear (publishes empty instead of
short-circuiting or falling back to the queue), and skips the cached-items
merge when replacing. Adds (the default) keep merge semantics.
- Both removal call sites (watchHistoryController.handleWatchHistoryRemoval and
historyView.defaultRemoveHandler) now pass replace:true.
Tests (snapshot at the updateWatchHistoryList boundary): removing an item
publishes the remaining list with replace:true; removing the last item publishes
an empty replace (not a queue republish / no-op); a normal watch-tracking
snapshot still merges (replace not forced). Mutation-verified — dropping the
replace forwarding fails 2 cases and reverting the empty-clear handling fails the
clear case.
Build + full lint green.
Co-Authored-By: Claude Opus 4.8 <[email protected]>
File-size decomposition (no behavior change). Move getLoggedInActorKey,
getSessionActorKey, and ensureWatchHistoryExtensionPermissions (which depend only
on imported singletons, not module state) into js/watchHistoryActorHelpers.js, and
drop the now-unused getActiveSigner/requestDefaultExtensionPermissions/getApplication
imports from the service.
watchHistoryService.js: 1491 -> 1388 lines (below its original 1395 baseline;
re-recorded to 1386 to lock the reduction).
Build + full unit suite green.
Co-Authored-By: Claude Opus 4.8 <[email protected]>
Slice B part 2 (final). On a cold watch-history load (nothing cached to
show yet) the service now decrypts only the newest chunks first
(chunkDecryptLimit = 3) so the UI renders recent history immediately
instead of freezing behind a deep, monthly-chunked history — the original
NIP-46 symptom. If older chunks were deferred, a single background pass
then backfills them (no chunk cap; already-decrypted chunks are served
from cache, so only the deferred older chunks cost signer RPCs) and emits
"fingerprint", which the history view already re-renders on. The serial
NIP-46 request queue paces the backfill, so there is no rate-limit flood.
Scoped to cold loads only: a warm refresh (items already on screen)
resolves the full history directly, avoiding a transient "history shrank
then grew" flicker. No view / feed-engine changes and no change to the
shared For You / explore paths beyond a fast first render then a fill-in.
Chosen over strict scroll-triggered lazy loading, which would have
required risky surgery on the history view's feed-engine + cursor
pagination and the shared loadLatest path pre-launch.
Tests: cold load passes a finite chunk limit on the first resolve, then an
unbounded background backfill runs and emits recent-only -> full; warm
refresh is unbounded. Both mutation-verified (removing the bound and
no-op'ing the backfill each fail).
Co-Authored-By: Claude Opus 4.8 <[email protected]>
updateFingerprintCache (and the fingerprint getter) emitted "fingerprint"
unconditionally on every load. The For You feed subscribes to that event and
re-runs refreshFeed -> loadLatest -> updateFingerprintCache -> emit, so once the
For You feed was active the app entered an infinite loop: a full feed rebuild
plus a watch-history reload (with extension decrypts) every ~400ms. That pegged
the CPU (fans maxing) and starved every other load — videos, hashtags, subs,
DMs and watch history all failed to appear.
Emit "fingerprint" only when the fingerprint actually changes. The first real
resolution emits once (triggering a single refresh); the follow-up load produces
the same fingerprint and emits nothing, so the loop settles immediately.
Co-Authored-By: Claude Opus 4.8 <[email protected]>
Root cause of the ~20s watch-history load: history is bucketed by month (one
encrypted snapshot event per month) and the fetch decrypted EVERY month via the
serialized nip-07 extension — ~1 slow call per month, so accounts with years of
history paid dozens of back-to-back extension decrypts on every load.
Cap the load to the most recent RECENT_MONTHS_DECRYPT_LIMIT (6) months by default
— enough for the feed's watched-video suppression and the initial view. Callers
that need the full history (the explicit History view) pass recentMonthsLimit: 0,
threaded loadLatest -> scheduleWatchHistoryRefresh -> resolveWatchHistory ->
resolve -> fetch.
Harness (fresh-context wh-repro): 600 items / 18 months goes from 18 nip-07
decrypt calls to 6. Watch-history tests green. Bumps the watchHistory.js
file-size baseline for the added logic.
Co-Authored-By: Claude Opus 4.8 <[email protected]>
After a page reload the in-memory caches (service fingerprintCache and the
client watch-history cache) are empty, so loadLatest's non-blocking path returned
[] and the For You feed suppressed nothing until the slow background network
refresh (~150 encrypted chunk events over 2 sequential relay round-trips) landed.
Return the best available items immediately via getCachedSnapshotItems, which
falls back to the persisted localStorage snapshot. Reloads now suppress watched
videos right away using the last-known history, while the background refresh
still runs and corrects it (firing "fingerprint" to re-run the feed). Persisted
items were previously valid, so there is no correctness risk.
Co-Authored-By: Claude Opus 4.8 <[email protected]>
The For You feed awaited watchHistoryService.loadLatest() before rendering, and
loadLatest blocked on the full ~1500-item watch-history fetch on a cold load even
with allowStale:true (the `!allowStale || !hasCachedItems` guard awaited whenever
there was no cache). So the main feed froze behind the entire watch-history
resolution, and nothing re-ran the feed once history finished loading — watched
videos were never suppressed and watch-history tags never applied until a manual
refresh.
- watchHistoryService.loadLatest: allowStale callers now NEVER block. On a cold
load the refresh is kicked off in the background and the call returns
immediately with whatever is available (cached items, else the local queue).
- feedCoordinator.subscribeWatchHistoryFeedRefresh: subscribes to the
"fingerprint" event and, when the For You feed is active, debounced-re-runs it
so newly-resolved watched videos are suppressed and tags applied. Wired in at
bootstrap alongside feed registration.
The re-run reads the now-fresh cache (no further refresh scheduled), so there is
no loop. Adds feedCoordinatorWatchHistoryRefresh.test.mjs (debounced single
refresh while active; no refresh when inactive; idempotent subscription).
Co-Authored-By: Claude Opus 4.8 <[email protected]>
The NIP-07 adapter uses type "nip07" but all permission pre-granting
checks only matched type "extension", causing NIP-07 browser extension
users to fail decryption for block/mute lists, subscriptions, DMs, and
watch history. Hashtag preferences appeared to work because their read
path had a separate fix, masking the systemic issue.
Changes:
- shouldRequestExtensionPermissions() now matches both "extension" and
"nip07" signer types (central fix affecting DM signals, comments,
publish helpers, and watch history fetch)
- buildDmDecryptContext() pre-grants extension permissions for NIP-07
- userBlocks.js: remove capabilities-gated decryptor check that failed
with lazy NIP-07 module injection (same fix already in subscriptions.js);
always resolve signer regardless of allowPermissionPrompt; increase
fast-path relay timeout from 6s to 10s
- watchHistoryService: recognize NIP-07 type and always resolve signer
- All publish paths (blocks, subscriptions, hashtags, relays, uploads,
sharing, moderation) now pre-grant permissions for NIP-07 signers
https://claude.ai/code/session_01PipsdaTQmw7wBTJ1LmJjkk
- 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]>
- Reduced view threshold from 12s to 5s in watchHistoryTelemetry.js
- Enabled immediate watch history republishing (0ms delay) for the first attempt in watchHistory.js
- Updated watchHistoryService.js to recursively schedule queue flushes if items accumulate during an inflight sync
This commit addresses issues with the watch history not updating dynamically and adds a manual refresh mechanism.
Changes:
- Added a "Refresh" button to the watch history view in `views/history.html` and `js/historyView.js`.
- Updated `watchHistoryService.js` to accept a `forceRefresh` option in `loadLatest`, which bypasses the cache freshness check and triggers a relay fetch.
- Updated `js/feedEngine/watchHistoryFeed.js` to propagate the `forceRefresh` flag from the runtime context to the service.
- Added user feedback (toast messages and logs) for "Clear Local History" and "Republish Now" actions.
- Updated `tests/watch-history.test.mjs` to align with the new `fetchHistory` signature.
Replace sessionStorage with localStorage to ensure pending watch history updates persist across tab closures and sessions. Update `loadLatest` to always restore queue state on initialization to catch any pending uploads.
Updates `shouldUseExtensionForHistory` in `js/watchHistoryService.js` to check for `signEvent` instead of `nip04.decrypt`. This ensures that logged-in users can sync their watch history (which is now plaintext) even if they haven't granted the legacy encryption permission.
- Rename "Clear local cache" button to "Clear local history"
- Update info text to remove references to hydrating from session/caches
- Simplify copy to remove "encrypted" references in favor of "syncing" or "history"
- Update success/error messages to match new terminology
Removes the metadata argument from `WatchHistoryService.publishView` and cleans up the associated caching and resolution logic in `watchHistory.js` and `watchHistoryFeed.js`. Deletes `js/watchHistoryMetadata.js` as it is no longer used.
This simplification ensures watch history strictly manages pointers and timestamps, leaving metadata resolution to higher-level consumers. It also reduces the payload size and complexity of persisted history records.
Tests have been updated to reflect the API changes.
Removes legacy snapshot/chunk retry scheduling in favor of a monthly upsert approach.
Updates state persistence to remove `pendingSnapshotId`.
Fixes race condition in `scheduleRepublishForQueue` by using selective queue pruning.
Ensures data is not lost on publish failure in `snapshot`.
Updates tests to align with new architecture.
- Update `js/nostrEventSchemas.js` to remove encryption tagging and update schema for `WATCH_HISTORY`.
- Update `js/nostr/watchHistory.js` to:
- Bump storage version to 4.
- Bucket items by `YYYY-MM`.
- Publish plaintext JSON payloads with only event IDs and timestamps.
- Remove encryption logic from publishing.
- Update fetching to handle plaintext and fallback to legacy parsing.
- Update `js/watchHistoryService.js` to strip metadata from queued items and handle new snapshot response.
- Update `tests/watch-history.test.mjs` to reflect new plaintext behavior and disabled obsolete tests.
