diff options
Diffstat (limited to 'docs/playlists.md')
| -rw-r--r-- | docs/playlists.md | 21 |
1 files changed, 11 insertions, 10 deletions
diff --git a/docs/playlists.md b/docs/playlists.md index aef2366..8e57546 100644 --- a/docs/playlists.md +++ b/docs/playlists.md @@ -1,13 +1,14 @@ # MeshBay — Playlists (design) -> Status: **proposal**, not implemented. This is M4 in `docs/musicbay.md` §9, +> Status: **proposal**, not implemented. This was deferred out of the Music +> application's design, > which deferred it for the right reason: *"a genuinely new category of > per-account node state, not covered by anything E9 already enumerates — > needs its own design pass (ownership, sync across devices, whether it's > node-local or something else)"*. This document is that pass. > -> Read `docs/musicbay.md` first — Music is built, and this adds nothing to -> its playback path. Read `docs/refactoring-search.md` second: the +> Read `MESHBAY_DESIGN.md` §9.8 first — Music is built, and this adds nothing +> to its playback path. Read §9.11 second: the > cross-group consolidation this feature needs already exists there, and > most of the work is recognising that. > @@ -33,16 +34,16 @@ this must not corrupt anything. ## 1. What this design does not reopen -- **Views over the index, never a catalogue** (`desktop-client-v1.md` §6.10, +- **Views over the index, never a catalogue** (`MESHBAY_DESIGN.md` §6.5, §9.1, draft-v6 §2.7). A playlist is a list of *references*; it creates no second identity for a file and no server-side database of content. - **Nothing about content reaches the hub** (H7, draft-v6 §2.5). §3.1. -- **No new streaming path.** `musicbay.md` §2.2 stands untouched: a track is +- **No new streaming path.** `MESHBAY_DESIGN.md` §9.8 stands untouched: a track is fetched through `pipelinedDownload` and handed to `<audio>`. Playlists add no node-side playback code whatsoever. - **Node-side derived data lives in the node's own `data_dir`**, never beside - a shared file (`mediacenter.md` §2). The blob in §3.3 goes in `bundles.db`. -- **Identity keys are per node** (`per-node-identity-v1.md`). §3.4 exists + a shared file (`MESHBAY_DESIGN.md` §6.5). The blob in §3.3 goes in `bundles.db`. +- **Identity keys are per node** (`MESHBAY_DESIGN.md` §3.2). §3.4 exists entirely because of this, and getting it wrong is the fastest way to ship a playlist that cannot be read from the second device it was invented for. @@ -101,7 +102,7 @@ that has nothing to do with this. Beyond the protocol that would have to be invented, it leaks the thing this architecture is most careful about: node A would learn that this account also uses node B — that two unrelated operators host the same person. Per-node identity exists precisely so that -this correlation is unavailable (`per-node-identity-v1.md`). +this correlation is unavailable (`MESHBAY_DESIGN.md` §3.2). ### 3.3 The node, as an opaque per-account blob — a shape already built @@ -424,7 +425,7 @@ Playlists cross groups, so they do not belong to a group's Music tab: already resolves a connection per track from `entry.groupId`, and already crosses groups within one queue. This is worth stating loudly, because the cross-group requirement reads like the hard part and is in fact already - built (`musicbay.md` §9b: *"The player needed no change"*). + built (the cross-group merge already covers it — `MESHBAY_DESIGN.md` §9.11). ### 8.3 The IndexedDB detail that will otherwise be missed @@ -434,7 +435,7 @@ handling it in the existing `onupgradeneeded`, which currently creates one store and would otherwise never run again. A store that is never created throws on first access, at a point far from the version constant. -### 8.4 Checklist, per `apps.md` +### 8.4 Checklist, per `MESHBAY_DESIGN.md` §9.4 1. `playlists.js` (data) and `playlists-page.js` (UI). 2. Route + sidebar entry in `app.js`. |