diff options
Diffstat (limited to 'docs/meshbay-draft-v6.md')
| -rw-r--r-- | docs/meshbay-draft-v6.md | 42 |
1 files changed, 42 insertions, 0 deletions
diff --git a/docs/meshbay-draft-v6.md b/docs/meshbay-draft-v6.md index 2ea73c4..72cfdbf 100644 --- a/docs/meshbay-draft-v6.md +++ b/docs/meshbay-draft-v6.md @@ -26,6 +26,7 @@ | `docs/invite-pairing-v1.md` | invitations, pairing codes, the node roster — **as built** | | `docs/per-node-identity-v1.md` | identity keys are per node; the hub stores none | | `docs/desktop-client-v1.md` | the desktop client in full — shell, device linking, roots, packaging, execution order | +| `docs/apps.md` | the group UI's plug-in architecture — as built, and how to add an application | | `devel-phases-next.md` | the roadmap | --- @@ -43,6 +44,7 @@ | 7 | Accounts | Native registration is **hybrid**: passphrase-derived `auth_key` (the recovery path) plus a device Ed25519 key for day-to-day authentication | E3 / decision 4 | | 8 | Authorship | Chat senders are **cryptographically authenticated to each other**; an upload has a **provable owner** who may delete it, as the operator may. v5's node-asserted attribution is replaced | operator decision, §2.4b | | 9 | Node authority | The operator may **close uploading to everyone but themselves**, per group. Signed MNP op, stored on the node, enforced by the node — the hidden button is a courtesy, the refusal is the control | §2.1b | +| 10 | Client | A group's UI is a **set of pluggable applications** (Chat, Files today), not one monolithic page. Which are shown is a per-group, operator-signed setting on the same pattern as change 9 | §2.7 | --- @@ -222,6 +224,43 @@ No parameter changes. `keyderive.py` now has a third consumer: the desktop clien it, and the standing warning is unchanged — **never change those parameters in one place**; a mismatch does not look like an error, it looks like an account nobody can open. +### 2.7 The group UI becomes a set of applications + +New (2026-08-23). A group had two fixed tabs, Chat and Files, both defined inside one +monolithic `static/app.js`. Two things motivated splitting it before adding to it: the file +had become the thing every unrelated change touched, and the roadmap wants three more +group-level surfaces — a Netflix-style video browser, a Spotify-style music player, a photo +album viewer. None of the three need a protocol change: the node's indexer already +classifies files as `video`/`audio`/`image`, and they would read the same `index_sync` / +`file_req` / `stream_req` messages Files and the video player already use. What they need is +somewhere to live that is not one file, and a way for an operator to turn one off. + +**The shape.** `group-page.js` is now the shell: the WebRTC connection, the file index, the +tab bar, and the video/preview modals, none of which are Files- or Chat-specific. `apps.js` +holds the registry — `[{ key, icon, labelKey, Component }]` — and every registered +component receives the same props object from the shell, spread rather than hand-listed, so +adding an app changes no code in the shell itself. Chat and Files each moved to their own +file (`chat-app.js`, `files-app.js`) to prove the mechanism; nothing else exists yet. + +**Enablement is the same pattern as change 9, on purpose.** `apps_enabled` is a per-group +setting: lives on the node (`roster.db`, not the hub, not `node.toml`, for the identical +reason `member_upload` does — a hub or a config file that decided this would have authority +over the node), changed by a signed operator instruction (`OP_APPS_ENABLED`), enforced by +the node refusing to store an unrecognised or empty set rather than by the client's +honesty. **Settings itself is not an app** and cannot be disabled — the one way back if +everything else were turned off. + +**What this does not change.** No new server state on the hub (change 5 stands unmoved: the +enabled-apps set is group-related state, and it lives on the node like everything else in +that category). No new adversary or trust boundary — this is a display policy, not a key or +a permission over content; a member whose client shows a hidden tab's data anyway would +still be a member the node already serves that data to. + +Full detail — the props contract, the file layout, and a checklist for adding a new +application — is `docs/apps.md`, on the same basis `docs/desktop-client-v1.md` holds the +desktop client's detail: this document states what changed and what holds, not how to build +on it. + --- ## 3. Filesystem portability as a security property @@ -302,3 +341,6 @@ design, which is long and belongs in one place: **`docs/desktop-client-v1.md`** — shell requirements, device-linking protocol and schema, account creation, node management over signed MNP ops, several roots per group, filesystem portability, packaging and first run, the web tier, and the execution order for all of it. + +**`docs/apps.md`** — the group UI's plug-in architecture (§2.7): the props every +application receives, the enablement mechanism end to end, and a checklist for adding one. |