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, 7 insertions, 3 deletions

diff --git a/packaging/win/firewall.ps1 b/packaging/win/firewall.ps1
index 939a58e..827daf5 100644
--- a/packaging/win/firewall.ps1
+++ b/packaging/win/firewall.ps1
@@ -6,7 +6,9 @@
     Two independent things need an inbound allow, and Windows prompts
     "Allow access" for each the first time it happens if there is no rule:
 
-    1. WebRTC (MeshBay.exe and meshbay-node.exe). It binds an ephemeral UDP
+    1. WebRTC (MeshBay.exe, meshbay-node.exe and meshbay-cli.exe, the
+       command-line client, which carries files over WebRTC as the app does).
+       It binds an ephemeral UDP
        port per connection, and the browser always dials the node -- aioice
        cannot resolve the peer's mDNS `.local` candidate to call back -- so the
        node (and, during ICE connectivity checks, the client) must accept
@@ -23,12 +25,12 @@
        are fixed and known. Matches packaging/firewall/*/meshbay-cast.xml.
 
     The installer runs this once, elevated, so the user answers one UAC prompt
-    instead of up to four dialogs spread across first use of chat, downloads
+    instead of up to five dialogs spread across first use of chat, downloads
     and casting. Declining the installer's offer is fine -- the dialogs are
     the fallback, one per program/port combination as each is first used.
 
     Shipped as an extraResource at <install>\resources\firewall.ps1, so it
-    locates the two executables from its own path and takes no arguments
+    locates the executables from its own path and takes no arguments
     beyond the action. add/remove run elevated and windowless, leaving a
     trace at %TEMP%\meshbay-firewall.log; check is a plain read (no admin
     needed -- Get-NetFirewallRule does not require it, only New/Remove do)
@@ -59,12 +61,14 @@ $GROUP     = "MeshBay"
 
 $client = Join-Path $install   "MeshBay.exe"
 $node   = Join-Path $resources "node-runtime\meshbay-node.exe"
+$cli    = Join-Path $resources "node-runtime\meshbay-cli.exe"
 
 # Program-scoped, any port: the ephemeral-UDP-port problem WebRTC always has.
 # Port-scoped as well: the two fixed, known ports LAN casting actually uses.
 $rules = @(
     @{ Name = "MeshBay";                Path = $client; Protocol = "UDP"; LocalPort = "Any" }
     @{ Name = "MeshBay Node";           Path = $node;   Protocol = "UDP"; LocalPort = "Any" }
+    @{ Name = "MeshBay CLI";            Path = $cli;    Protocol = "UDP"; LocalPort = "Any" }
     @{ Name = "MeshBay Cast";           Path = $client; Protocol = "TCP"; LocalPort = "19550-19553" }
     @{ Name = "MeshBay Cast Discovery"; Path = $client; Protocol = "UDP"; LocalPort = "5353" }
 )