diff options
Diffstat (limited to 'docs/apps.md')
| -rw-r--r-- | docs/apps.md | 49 |
1 files changed, 30 insertions, 19 deletions
diff --git a/docs/apps.md b/docs/apps.md index 94116c6..a032f56 100644 --- a/docs/apps.md +++ b/docs/apps.md @@ -5,13 +5,18 @@ > `meshbay-draft-v6.md` §2.7 for why this exists and what it changes; this > 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 -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`/ -`stream_req` messages Files and `VideoPlayer` already use. Adding one is a new -file plus one registry entry — nothing about the group shell changes. +A group has "applications" — Chat, Files, and Videos today (a poster-grid +browser; see `docs/mediacenter.md`), Music/Photos planned (a music player, an +album viewer). 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`/`stream_req` messages Files and +`VideoPlayer` already use — Music/Photos need no MNP change beyond that. +Videos itself did need one: TMDB metadata (`media_meta_req`/`resp`), per-season +overview (`season_meta_req`/`resp`), and operator match correction +(`tmdb_search_req`/`resp`, `tmdb_override`/`_ack`) are all additive message +pairs on top of the same index/chunk plumbing, not a replacement for it. +Adding a new app is still a new file plus one registry entry — nothing about +the group shell changes. --- @@ -172,18 +177,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- |