feat(cli): meshbay-cli, a command-line client for members

Signs in to the hub, lists the account's groups and their folders, and
downloads and uploads files directly with each group's node, end-to-end
encrypted. With no argument it opens a two-pane interactive mode (Textual).
Session and device keys are kept encrypted under the system's key storage,
or a 0600 key file where there is none; node keys are pinned at first
contact; a new machine links as a device.

Packaged on its own on Linux (deb and rpm, on meshbay-common's venv, with a
man page generated from the parser) and frozen next to meshbay-node in the
full Windows installer, not the light one, with a self-test the build runs.
client/keys.py ports keyderive.js and is LGPL like it.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

1 files changed, 15 insertions, 5 deletions

diff --git a/packaging/win/README.md b/packaging/win/README.md
index 4ce1459..89185fe 100644
--- a/packaging/win/README.md
+++ b/packaging/win/README.md
@@ -11,13 +11,15 @@ Linux). `meshbay-common` rides along inside the node runtime.
 ├─ MeshBay.exe                     Electron client
 ├─ resources\
 │  ├─ app.asar                     src/ + ui/ (the interface ships in the package)
-│  ├─ firewall.ps1                 adds/removes the four inbound rules (see below)
+│  ├─ firewall.ps1                 adds/removes the five inbound rules (see below)
 │  ├─ service.ps1                  install/remove/status/run/end the boot-time task
 │  ├─ service-mode.ps1             elevated helper: service.ps1 + firewall.ps1 in one UAC prompt
 │  └─ node-runtime\
 │     ├─ meshbay-node.exe          frozen daemon and CLI (PyInstaller onedir)
 │     ├─ meshbay-nodew.exe         the same daemon without a console (the Store
 │     │                            package's startup task runs it)
+│     ├─ meshbay-cli.exe           the command-line client, a member's files from
+│     │                            a terminal (Full and Store, not Light)
 │     ├─ _internal\ …              its Python + deps (aiortc, av, aioquic, …)
 │     ├─ ffmpeg.exe, ffprobe.exe   bundled by default, see Video (ffmpeg) below
 │     ├─ av*.dll, swscale/swresample*.dll   what those two link against
@@ -33,8 +35,9 @@ as this same signed-in user (S4U, see below), so it is the same profile either
 way — not LocalSystem/NetworkService, which would have none of this.
 
 `build/installer.nsh` also adds `…\resources\node-runtime` to the **per-user**
-`Path` (`HKCU\Environment`) so `meshbay-node` works in a terminal, and takes it
-back out on uninstall. New shells only — a `WM_SETTINGCHANGE` broadcast nudges
+`Path` (`HKCU\Environment`) so `meshbay-node` and `meshbay-cli` work in a
+terminal, and takes it back out on uninstall. The Store package declares an
+execution alias for each instead (`build/appx-extensions.xml`). New shells only — a `WM_SETTINGCHANGE` broadcast nudges
 open ones. It uses stock `WordFunc.nsh` (the `EnVar` plugin is not in
 electron-builder's NSIS bundle).
 
@@ -151,7 +154,7 @@ That runs [`build-win.ps1`](build-win.ps1):
 | 2 | `npm ci` + download Electron's Chromium |
 | 3 | bump Electron to the latest release (Chromium CVE policy; `-NoElectronBump` to skip) |
 | 4 | `npm run sync-ui` — copy the interface from `meshbay-hub/.../static` |
-| 5 | [`build-node-runtime.ps1`](build-node-runtime.ps1) — PyInstaller freeze → `packages/meshbay-client/node-runtime/`, then [`smoke-node-runtime.ps1`](smoke-node-runtime.ps1) starts the frozen daemon in a throwaway profile and checks it answers with the right version and writes its log, and [`smoke-connection-process.py`](smoke-connection-process.py) starts both executables as connection processes (`connection_processes` above 1) and carries a connection through each |
+| 5 | [`build-node-runtime.ps1`](build-node-runtime.ps1) — PyInstaller freeze → `packages/meshbay-client/node-runtime/`, then [`smoke-node-runtime.ps1`](smoke-node-runtime.ps1) starts the frozen daemon in a throwaway profile and checks it answers with the right version and writes its log, and [`smoke-connection-process.py`](smoke-connection-process.py) starts both executables as connection processes (`connection_processes` above 1) and carries a connection through each; `meshbay-cli.exe` is run too — `--version`, `groups --help`, and its self-test (`MESHBAY_CLI_SELFTEST=1 meshbay-cli`), which loads what a frozen build can miss without failing until run: the interactive mode drawn off-screen, keyring's backends, the WebRTC stack |
 | 6 | `electron-builder --win nsis` → `packages/meshbay-client/dist/MeshBay-Setup-<version>.exe` |
 
 ### Video (ffmpeg)
@@ -215,7 +218,7 @@ publish their host candidate as an unresolvable `<uuid>.local` mDNS name that
 `aioice` discards — the browser always dials the node, never the reverse. So the
 node has to accept unsolicited inbound UDP from its peers.
 
-**Windows Defender Firewall.** The setup wizard offers to add four inbound
+**Windows Defender Firewall.** The setup wizard offers to add five inbound
 rules in one step — it needs one admin confirmation (`build/installer.nsh`
 runs `firewall.ps1` via NSIS `ExecShellWait "runas"`; the per-user install
 itself never elevates):
@@ -224,6 +227,7 @@ itself never elevates):
 |---|---|---|---|
 | `MeshBay` | `MeshBay.exe` | UDP, any port | WebRTC (ICE checks touch the client too) |
 | `MeshBay Node` | `meshbay-node.exe` | UDP, any port | WebRTC (the node — unsolicited inbound, see above) |
+| `MeshBay CLI` | `meshbay-cli.exe` | UDP, any port | WebRTC (the command-line client during a transfer; ICE checks touch it as they do the app) |
 | `MeshBay Cast` | `MeshBay.exe` | TCP 19550–19553 | LAN cast HTTP relay (`src/cast-relay.js`) |
 | `MeshBay Cast Discovery` | `MeshBay.exe` | UDP 5353 | Chromecast/Smart TV mDNS discovery (`bonjour-service`) |
 
@@ -284,6 +288,12 @@ FFmpeg DLLs), `aioquic`, `pydantic_core`, `uvicorn`, `watchdog`, `guessit`,
 add the package to `COLLECT_ALL` / `HIDDEN` / `COPY_META` in the spec — that is
 the expected way the list grows.
 
+The command-line client has its own analysis in the same spec
+(`CLI_COLLECT_ALL`, `CLI_COPY_META`): Textual loads its widgets lazily, Rich its
+Unicode tables by version, keyring its backends through entry points, which
+is why keyring's metadata is copied. The build's self-test run catches what
+those lists miss.
+
 ## Not done
 
 - **Authenticode signing** — Phase 13.9. Unsigned installer triggers SmartScreen.