meshbay.git/tmp-decisions.md, branch 0.8

docs: settle the desktop client, and draft v6

2026-08-18T00:14:39Z

A design discussion on 2026-08-17 settled Phase 13 and, in doing so, changed four things the spec states. v6 restates only those; v5 stays authoritative for everything it does not touch, per the convention v5 itself used with v4. What changed: * The native shell is **Electron**, not pywebview — structural decision 18 reversed. The SPA depends on Chromium-class APIs (WebRTC, WebCrypto X25519/Ed25519, MSE, Service Workers), so keeping Chromium keeps transport.js, crypto.js, keyderive.js, downloads.js and sw.js *as the client*. A system webview meant reimplementing ~2500-3000 lines. The old "69 % reused" figure was measured against an app.js of ~2600 lines; it is 4586. * A group's content is **several named roots**, not one directory, because the planned video and audio libraries will not live in one folder on one disk. * **Device linking**: one person may hold several devices on a node, admitted by a key the node already pinned and bound by a one-time code the new device generates. Without it a native client is refused where a browser is not, and an account created natively could never be opened in a browser. * **Authorship is authenticated, not asserted** — chat senders sign, uploads have a provable owner, and delete authorization moves from the uploading key to the account. And one rule v5 assumed without writing down: **group-related server state lives on the node.** Verified for multi-root — SwarmSource carries hashes and endpoints, no paths. Also here: the Caddy configuration, which was a snippet in the roadmap that would have broken the SPA (it predates /a// asset versioning and would have 404ed /sw.js, silently killing streamed downloads on Firefox and Safari); and downloads.html, which becomes a security page once a release key exists. Phase 15 was re-read against device linking and is wrong as written: a sender key must be per **device**, never per person, or two devices sharing a chain produce key and nonce reuse — C1 again, one level down. senderkeys.py already fails this silently. Co-Authored-By: Claude Opus 5

docs: rework Phase 12 — hub minimization deferred by operator decision

2026-08-13T10:01:47Z

Operator decisions (tmp-decisions.md D1/D2/D4): - the hub keeps serving the web UI (zero-install path stays) - a native desktop client is offered ALONGSIDE it, not as a replacement - hub minimization is off the critical path and may be dropped Phase 12 was "Hub minimization: registrar and nothing more". Most of it is dropped: route-inventory blindness test, opaque private-group metadata, chat_notify metadata minimization, residual schema cleanup. The swarm item already shipped in 11.5.18. Two items are kept, because the decision makes them more relevant rather than less — the hub stays in the trusted path by choice, so what it can substitute and what code it serves both still matter: 12.1 key transparency + safety numbers [H3]. This is the last open High finding and nothing else fixes it: the hub is the public key directory, so substituting a key during an invite hands it the group key silently, with no JWT forgery and no code injection. Dropping Phase 12 wholesale would have left it open indefinitely. 12.2 served-SPA integrity: CSP, SRI, and a hub-published signed digest of the bundle so a native client can verify what the browser was given. 12.3 honest labelling of /app/ as the hub-served path. 12.4 written threat model — the thing that stops the overclaiming pattern. Recorded consequence: T3 is now accepted permanently for browser users. A hub that serves the code can exfiltrate keys from the page whatever the protocol does. The claim that still holds, and that the docs should make, is "the hub cannot read your content unless it actively attacks you" — not "unreadable by other parties, even the hub". Co-Authored-By: Claude Opus 5

docs: second security review + roadmap rewrite

2026-08-13T01:56:30Z

Second architecture and security review (second-review.md): 6 critical and 7 high findings against the Phase 12 implementation, plus an assessment of whether the system meets its end-to-end confidentiality claim. Roadmap rewritten against those findings (devel-phases-next.md): new blocking Phase 11.5 (security remediation), Phase 12 (hub minimization), Phase 13 (native desktop client). Old phases 12-17 renumbered to 14-19. tmp-decisions.md records two open decisions: whether the hub keeps serving the web UI, and browser extension vs native desktop client vs both. CLAUDE.md and devel-phases-next.md also carry pre-existing Phase 12 edits from the working tree that could not be cleanly separated from the review changes. Co-Authored-By: Claude Opus 5