diff options
| author | Christophe Besson <cbesson@gmail.com> | 2026-09-18 22:30:15 +0200 |
|---|---|---|
| committer | Christophe Besson <cbesson@gmail.com> | 2026-09-18 22:30:15 +0200 |
| commit | af55e6bc052187855420c1d549659879e35d4a41 (patch) | |
| tree | fcd33c0ac960d919b6d09ea804f96e5d8ed5d65e | |
| parent | 20b906057d1c1df810cd0c2cfe235c27df9f3e5f (diff) | |
| download | meshbay-af55e6bc052187855420c1d549659879e35d4a41.tar.gz | |
docs: the desktop stages D5 and D6 are built, elsewhere
Both described panels the desktop client would grow of its own. §8.3 settled
that differently: one UI source means anything written for the client is
something the browser then lacks, so both were built in `static/` instead and
the client ships them.
D5 is `node-page.js` over the operator ops — status, groups, roots with eject,
plug and add, roster, peers, pairing, audit export. D6 is `create-group-page.js`,
which detects the node, provisions it, takes the group's name and roots,
initialises the key and pairs. The service unit is the one genuinely native
part, and the desktop main process already runs it: `systemctl --user` on Linux,
Task Scheduler on Windows.
Left standing in §15.2 they read as work outstanding, which is how a plan
outlives the decision that replaced it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
| -rw-r--r-- | docs/MESHBAY_DESIGN.md | 12 |
1 files changed, 10 insertions, 2 deletions
diff --git a/docs/MESHBAY_DESIGN.md b/docs/MESHBAY_DESIGN.md index f1055a7..92c3021 100644 --- a/docs/MESHBAY_DESIGN.md +++ b/docs/MESHBAY_DESIGN.md @@ -3008,12 +3008,20 @@ running hub and node on **Ubuntu 26.04 (`.deb`), Fedora 44 (`.rpm`) and Windows 11 (`.exe`)**. What is not done is signing them (Stage D11, D12), which is a different question from whether they install. +**Managing a node and setting one up are built, and not where the desktop stages +put them.** §8.3 is why: one UI source means a panel written for the desktop +client is a panel the browser does not have, so both live in `static/` and the +client ships them. `node-page.js` is the management surface over the operator +ops — status, groups, roots with eject, plug and add, roster, peers, pairing, +audit export. `create-group-page.js` is the first-run path: it detects the node, +provisions it, takes the group's name and roots, initialises the key and pairs. +The one part that is genuinely native is the service unit, and the desktop main +process runs it — `systemctl --user` on Linux, Task Scheduler on Windows. + ### 15.2 Not built | | | |---|---| -| **Stage D5** | Node management panel over the operator ops, root selection included | -| **Stage D6** | First-run wizard — detect, enable the unit, link, group, initialise, pair | | **Stage D9** | Python sidecar — `group://` over QUIC | | **Stage D11** | Windows code signing — the installer runs on Windows 11; the binary is unsigned | | **Stage D12** | Release key, signed repositories, updates through the OS | |