diff options
Diffstat (limited to 'docs/apps.md')
| -rw-r--r-- | docs/apps.md | 32 |
1 files changed, 19 insertions, 13 deletions
diff --git a/docs/apps.md b/docs/apps.md index 94116c6..931114d 100644 --- a/docs/apps.md +++ b/docs/apps.md @@ -6,7 +6,7 @@ > document is the how-to. A group has "applications" — Chat and Files today, Videos/Music/Photos planned -(Netflix-style browsing, Spotify-style playback, an album viewer). None of the +(a poster-grid browser, a music player, an album viewer). None of the planned ones need an MNP protocol change: video/audio/image files are already classified by the node's indexer (`meshbay_node/indexer/indexer.py`, `type: video|audio|image`) and flow through the same `index_sync`/`file_req`/ @@ -172,18 +172,24 @@ the only node-side touches, and both are allow-lists, not new wire messages. ## 5. What does not exist yet -- **Thumbnails/posters.** No generation mechanism, client or node side. A - Netflix-style grid or a photo album needs *something* here; the pragmatic - v1 (decided but not built) is lazy, client-side: decrypt the image, or a - video's first segment, only for tiles actually visible, with an in-memory - cache — no new MNP message, no node-side store. This is real per-tile cost - (a full chunk-pipelined decrypt per thumbnail), acceptable for a browsing - grid, not for hundreds of tiles rendered at once — a virtualized grid is - part of building Videos/Photos, not optional. -- **Videos, Music, Photos themselves.** Deliberately out of scope for the - refactor that built this — see `meshbay-draft-v6.md` §2.7. The - infrastructure above is proven end-to-end with the two apps that already - existed (Chat, Files); a new one is additive. +- **Thumbnails/posters — built for Videos, 2026-08-23, see `docs/mediacenter.md`.** + The plan below (lazy, client-side, no node-side store) turned out to be + wrong once a real design pass ran the numbers: `docs/mediacenter.md` §2 + revises `desktop-client-v1.md`'s O12 and has the node generate thumbnails + (an `ffmpeg` frame grab, its own bounded worker pool) and cache them + durably in its own `data_dir`, delivered over the existing `file_req`/ + chunk path addressed by their own blake3 hash. TMDB posters/metadata are + fetched and cached by the node the same way — no client ever talks to + TMDB directly. A virtualized grid (`IntersectionObserver`-based lazy + mount) is built in `video-app.js`, per the note below. A future Photos + app can reuse the same node-side machinery (thumbnail cache, chunk-path + delivery) without re-deciding any of this. +- **Videos, Music, Photos themselves.** Videos is now built (`video-app.js`, + `docs/mediacenter.md`). Music and Photos remain deliberately out of scope + — see `meshbay-draft-v6.md` §2.7. The infrastructure in this document was + proven end-to-end first with Chat/Files, then with Videos; Music/Photos + are additive from here, and can reuse Videos' thumbnail/chunk-delivery + machinery rather than re-deciding it. - **The offline/loopback settings path.** `member_upload` can be toggled two ways: over a live MNP connection, or (Electron only) via the node's local HTTP API when MNP isn't connected (`platform.node.call('PUT', .../member- |