aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* feat(packaging): bundle ffmpeg in the Windows installer by defaultChristophe Besson2026-09-059-40/+335
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | winget install ffmpeg was considered and rejected as the mechanism: it needs network access and winget/App Installer present at the exact moment setup runs, and its failure mode is silent -- video just does not stream, with nothing pointing back at ffmpeg. Not viable for a non-technical install. MeshBay transcodes browser-incompatible video to H.264 (-c:v libx264, webrtc_server.py) -- a real encode, not remux -- so this needs a genuine GPL ffmpeg build; no LGPL-only build includes an H.264 encoder, since libx264 itself is GPL. packaging/win/fetch-ffmpeg.ps1 (new) Downloads, checksum-verifies and stages ffmpeg for the build. Source: BtbN/FFmpeg-Builds' Windows x86_64 gpl-shared preset -- shared DLLs rather than two independent static binaries, which is what nearly tripled this: the "full" static build many devs already have via winget is ~220 MB *per executable*. Pinned to one dated release tag (immutable once published) and its own sha256, not the "latest" alias BtbN repoints on every auto-build -- verified by hand first (downloaded, hash matched, ran a real encode+probe with libx264) before pinning. ffplay.exe (an SDL2 player, ~17 MB) is dropped; MeshBay never invokes it. Cached after the first build. Runs its own smoke test (encode + probe a real clip) so a broken fetch fails at build time, not for the first user who tries to watch something. packaging/win/LICENSE-ffmpeg.txt (new) GPLv3 notice + where the corresponding source is, required because this redistributes a GPL binary even though it is unmodified and only ever invoked as a subprocess. Ships alongside ffmpeg.exe in the installer. build-node-runtime.ps1 / build-win.ps1 Bundling is now the DEFAULT, replacing the old opt-in -FfmpegDir (which copied from a local directory and left most builds without ffmpeg at all). -SkipFfmpeg opts out for a smaller, streaming-less local-iteration build. Also fixes a real bug the ffmpeg change exposed rather than caused: the final `--help` smoke test did `$help -notmatch "meshbay-node"` against $help captured as a PowerShell ARRAY (one element per line) -- -notmatch on a collection is a FILTER, not a boolean test, and returns the non-matching elements; any non-empty array is truthy in if() regardless of content. Once --help wrapped past one line (it now does, with autostart/service in the verb list) this threw unconditionally. Fixed by joining to one string before matching, and pinned by a new test so a future edit cannot silently reintroduce the collection-vs-scalar trap. Verified: downloaded and hashed the pinned release by hand (matches), ran a real libx264 encode + ffprobe against the extracted build, fetch-ffmpeg.ps1 end to end (161 MB staged), a full build-node-runtime.ps1 run (308 MB node-runtime/) and a full installer build (MeshBay-Setup- 1.0.0.exe, 210.8 MB with ffmpeg bundled). Node suite 850 pass / 25 skip. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* test(node): pin the fresh-install-before-provisioning safety propertyChristophe Besson2026-09-042-0/+61
| | | | | | | | | | | | | | | | | | | | | | | | | | | Two properties discussed but not yet pinned by a test, both load-bearing for service mode: 1. A bare `meshbay-node` with no config yet -- exactly what the W3 Startup .vbs and the service-mode Scheduled Task both run unattended, on the very first boot after a fresh install, quite possibly before the user has ever opened the client -- must fail closed, fast, and without a trace. Measured by hand first (under a second, zero bytes written against a real empty %LOCALAPPDATA%); this pins it as a test so it can't regress silently. load_config() already returns an empty Config on a missing path rather than raising, so main() reaches its own "hub.username not set" exit before ever touching NodeDaemon() or asyncio.run() -- nothing here has to mock the daemon startup. 2. node:start (main.js) must call provisionNode() before it ever checks for the service task or spawns -- reversed, the wizard's first Start on a fresh service-mode install would run/query the daemon before node.toml exists for it to read. Source-read, same technique as test_desktop_shell.py: the only evidence available without a live Electron run. Node suite 845 pass / 25 skip. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* feat: opt-in Windows service mode (boot-time, one elevation) + v1.0.0Christophe Besson2026-09-0414-86/+643
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The per-user Startup-folder launcher (W3) only ever runs after this user signs in. A real Windows Service would start earlier, but under LocalSystem/NetworkService -- accounts with no normal profile, so %LOCALAPPDATA%\meshbay\ (config, keystore, data) would not exist for it. Relocating storage to make that work is real surgery, deliberately not done here. Instead: a Scheduled Task, created once with admin rights, that runs AS THIS USER at boot without needing them to sign in first. `schtasks /create ... /ru <user> /rp ""` with no `/it` registers an S4U (Service For User) logon -- no password stored anywhere, and unlike LocalSystem it loads this account's own profile, so config_dir()/ data_dir() need zero changes. The cost: S4U carries no network credential, which the node never needed -- everything it touches is local disk plus outbound internet. Creating the task needs admin (a boot trigger touches system-wide scheduler state, the same reason /sc onlogon needed it); querying/starting/stopping an existing one does not -- Task Scheduler grants the owning user that much itself, which is what lets the Node page's Start/Stop/Restart drive it with no further UAC prompts. meshbay_node/platform.py service_install/_remove/_status/_run/_end -- mirrors autostart_* but for the Scheduled Task; TASK_NAME moved here (was decorative before) meshbay_node/daemon.py new `service install|remove|start|stop|status` verb; restart-daemon and reset now check for the service task too packaging/win/service.ps1 the installer-side equivalent (extraResource); status/run/end never self-elevate -- only install/remove do, exactly matching what Task Scheduler itself requires packaging/win/service-mode.ps1 ONE elevated helper running service.ps1 + firewall.ps1 together, so choosing service mode costs exactly one UAC prompt, not two build/installer.nsh the install-time choice: "run as a background service?" (one elevation, both jobs) vs the existing per-user + separate firewall question. Checked first, unelevated, so re-running setup with everything already configured asks nothing. Uninstall offers the matching one-elevation cleanup, default No. src/main.js winServiceTaskStatus/Run/End, wired into node:installed, node:service-status/-stop/-restart and node:start: when the Scheduled Task exists, drive it; otherwise fall back to the existing per-user spawn/kill path. This is the hard requirement -- Start/Stop/Restart from the Node page must work in either mode. node-page.js / locales a hint explaining why the per-user autostart toggle is absent when service mode is active (info.mode from the backend, no new field to gate on -- it just isn't sent in that case) package.json: 0.1.0 -> 1.0.0. Verified: electron-builder compiles the new NSIS choice logic and ships all three scripts; service.ps1's S4U install fails cleanly (Access denied) when run unelevated, and its status/run/end never touch "runas". Cannot verify the elevated success path myself (no admin in this session) -- that needs a real UAC click. Node suite 843 pass / 25 skip; test_packaging_win.py pins the one-elevation property, the S4U flags, and that main.js actually checks the service task in all three handlers. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* fix(client): Stop/Restart buttons and an autostart toggle on the Node pageChristophe Besson2026-09-045-2/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Root cause of both reports: node:service-status's `installed` field was winAutostartInstalled() -- whether the Startup-folder launcher exists -- not whether the daemon can be managed at all. The Node page gates Stop/Restart on `installed`, so with no autostart configured (the default -- nothing installs it automatically) those buttons silently never rendered, leaving only Start. A perfectly manageable daemon looked unmanageable because a different, unrelated setting was off. installed now reflects the actual daemon binary (findNodeBinary()), same definition node:installed already used; autostart moves to its own field carrying what installed used to mean. That field also fixes the other half: there was no way to turn autostart on except the CLI. NodeServicePanel now shows a toggle-switch next to Start/Stop/Restart, wired through a new platform.node.autostart (install/remove) that mirrors the existing service.* pattern -- the preload/main.js bridge (W3) was already there, just never called from the interface. English and French strings; other locales fall back to English per the project's own stated policy (test_locales.py's own docstring). Verified: node --check on every edited file; hub/node suites green (863 pass, 0 fail — pre-existing test_locales.py encoding failures on this Windows checkout are unrelated, reproduced identically on the clean tree). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* fix(client): a failed spawn() of the node no longer crashes the appChristophe Besson2026-09-041-0/+11
| | | | | | | | | | | | | | | | | spawnNodeDetached() and the Linux dev-mode fallback in node:start called spawn() with no 'error' listener. A spawn failure -- bad path, a stale PATH entry, antivirus interference -- is delivered on that event asynchronously; with nothing listening, Node rethrows it as an uncaught exception and takes the whole Electron main process down with it, instead of the caller's own waitForNode() timeout turning "never came up" into a clean message. Hit directly: ENOENT spawning a stale dev-venv meshbay-node.exe (not the installed one -- where.exe correctly resolves to the bundled exe now). Whatever the trigger, a daemon that fails to start must never be able to take the renderer down with it. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* fix(packaging): re-running setup no longer re-prompts for firewall accessChristophe Besson2026-09-044-19/+63
| | | | | | | | | | | | | | | | | | | Every run of customInstall showed the "Allow MeshBay through Windows Firewall?" question and, on Yes, a fresh UAC prompt -- an upgrade or repair install would ask again even with all four rules already in place. customInstall now checks first: firewall.ps1 check, unelevated (Get-NetFirewallRule needs no admin, only New/Remove do), exits 0 if every rule already exists. Only a nonzero result reaches the MessageBox and the elevated add. A second run of setup on an already-configured machine now asks nothing. Verified unelevated: check exits 1 and logs which rules are missing on a machine with none of them (the fresh-install case); electron-builder compiles the nsExec::Exec / Pop $0 / ${If} wiring. Node suite 837 pass / 25 skip. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* feat(packaging): cover LAN casting in the Windows firewall step, tooChristophe Besson2026-09-043-32/+95
| | | | | | | | | | | | | | | | | | | | | | | firewall.ps1 only handled WebRTC. The cast HTTP relay (src/cast-relay.js, fixed TCP 19550-19553) and Chromecast/Smart TV mDNS discovery (src/cast-chromecast.js, bonjour-service, UDP 5353) are a separate surface on the client and were still hitting Windows' own "Allow access" dialog. Now four named rules: MeshBay / MeshBay Node stay program-scoped with no port restriction (there is no fixed WebRTC port to name -- the Windows equivalent of the broad 1024-65535/udp range the Linux packaging needs, since netfilter has no program scoping); MeshBay Cast / MeshBay Cast Discovery add the program AND the fixed port, matching packaging/firewall/*/meshbay-cast.xml exactly. test_packaging_win.py cross-checks the port numbers against cast-relay.js's own constants and the Linux firewalld definition, so the three descriptions of one port range can't quietly drift apart. Verified: rebuilt MeshBay-Setup-0.1.0.exe; the deployed firewall.ps1 carries all four rules. Node suite 836 pass / 25 skip. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* feat(packaging): offer one elevated firewall step instead of two dialogsChristophe Besson2026-09-046-15/+190
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Installing used to mean clicking through two separate Windows "Allow access" prompts later — one for MeshBay.exe, one for meshbay-node.exe — each confusing on its own and worse before the exe carried a version resource. Adding a firewall rule needs admin, and the installer is deliberately per-user with no elevation, so this can only ever be opt-in. packaging/win/firewall.ps1 (new, shipped as an extraResource at resources\firewall.ps1): idempotent add/remove of the two inbound UDP rules ("MeshBay", "MeshBay Node"), grouped, logged to %TEMP%\meshbay-firewall.log. Locates both executables from its own path, no arguments needed beyond the action. build/installer.nsh: customInstall asks "Allow MeshBay through Windows Firewall now?" and runs firewall.ps1 via NSIS ExecShellWait "runas" — one UAC prompt — only when not ${Silent}; declining or dismissing UAC falls back to Windows' own per-process prompts, unchanged. customUnInstall offers the same in reverse, defaulted to No (a stale rule for a deleted exe is inert, so this should not nag on the way out) and skipped for a silent uninstall. Verified: rebuilt MeshBay-Setup-0.1.0.exe (electron-builder compiles the new LogicLib.nsh / ExecShellWait NSIS successfully); firewall.ps1 run unelevated fails cleanly into its log ("Access is denied") rather than silently doing nothing, confirming the fallback path. Node suite 835 pass / 25 skip. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* feat(packaging): stamp the frozen node exe, document Windows networkingChristophe Besson2026-09-043-0/+93
| | | | | | | | | | | | | | | | | meshbay-node.spec now builds a VSVersionInfo (ProductName "MeshBay Node", version read from the installed package so it tracks pyproject) and passes it to EXE(version=...). The Windows Firewall prompt, Task Manager and the file's Properties then show "MeshBay Node" instead of a bare exe name — the prompt the operator has to answer on first run. packaging/win/README.md gains a Networking section: the first-run firewall prompt (allow Private AND Public — a VM adapter is Public), that a flat LAN needs nothing else, what a routed/multi-subnet LAN additionally needs, the libvirt-NAT caveat, and a pointer to the packaged Linux firewall profiles. test_packaging_win.py covers the version resource. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* feat(node): log the host candidates the WebRTC answer offersChristophe Besson2026-09-041-2/+15
| | | | | | | | | | | "DataChannel closed" from a peer and a clean node log look identical: the answer-ready line reported only the srflx count, not the host addresses. On a NAT'd host or a VM the sole host candidate is an address no other machine can route to, and that is exactly the case you cannot see. The line now reads `... host: 192.168.200.173, 1 srflx`, so "did the node offer anything routable" is answerable from the journal. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* fix: drop the retired Mozilla STUN server from the defaultsChristophe Besson2026-09-044-7/+14
| | | | | | | | | | | stun.services.mozilla.com no longer resolves — Mozilla shut the service down — so every ICE gather waited out a DNS timeout on it. Removed from the node defaults (config.py), the browser defaults (transport.js) and the Node page's "reset to defaults" (node-page.js). Google (two endpoints) plus Cloudflare still give two-provider coverage against a single outage, which is the §2.12 resilience claim. draft-v6 §2.12 updated. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* fix(node): say so when MusicBrainz lookups are inertChristophe Besson2026-09-042-1/+30
| | | | | | | | | | | | | | Staying inert without a contact is the documented policy (module docstring, musicbay.md §3.1): the usage policy wants a contact in the User-Agent, so an unidentified client is never sent. Staying *silent* about it was not a decision — the operator sees Music tiles with no metadata or cover art and has nothing to search the logs for. Warns once per client rather than once per lookup, since the condition is constant for the client's lifetime. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DtfG7z6wHWj8RKHCvxQtY1
* fix(packaging): actually ship the TMDB token, on Linux and WindowsChristophe Besson2026-09-045-17/+263
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | default.env was empty in every build, for three independent reasons: 1. build-node.sh read QE/node.env, which does not exist. Even pointed at the real file it would have failed: its `grep MESHBAY_TMDB_DEFAULT_TOKEN=` cannot match QE/tmdb.txt, which is a free-form note, not KEY=VALUE. 2. Nothing consumed default.env. packaging/README.md and build-node.sh both claimed `meshbay-node init` copies it to <config>/node.env; grep found the name in exactly two places, the README and the script that writes it. No code implemented the copy, and `EnvironmentFile=-` hid the absence. 3. build-win.ps1 had no env handling at all, so Windows was empty for a different reason than Linux. Now: the build extracts the v4 read token -- tmdb.py sends `Authorization: Bearer`, so it is the JWT, not the 32-char v3 key beside it in the same file -- matching KEY=VALUE first and then by shape, from MESHBAY_TMDB_TOKEN, MESHBAY_TMDB_TOKEN_FILE, QE/node.env, QE/tmdb.txt. It writes default.env 0600 and *fails the build* if no token resolves; MESHBAY_ALLOW_NO_TMDB=1 opts out. An empty default.env is invisible until a user opens Videos and finds no metadata, which is how this shipped empty on two platforms at once. platform.py gains packaged_default_env()/install_node_env()/load_node_env(). init copies the packaged file once, never overwriting an existing node.env, and the daemon loads node.env itself at startup: systemd does this on Linux via EnvironmentFile, but Windows autostart is a Startup-folder .vbs with no equivalent. Already-set variables always win. Also fixes an UnboundLocalError in main(): `config_dir` was assigned at the top of the init branch, which made it function-local for all of main(), while the reset branch calls `config_dir()` as the imported function. init returns before that line, so `meshbay-node reset` could only ever raise. The local is now cfg_dir. Verified end to end on Linux: token baked (239 chars), init writes <config>/node.env 0600 with it. The PowerShell half is written but unrun -- no pwsh on this machine. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DtfG7z6wHWj8RKHCvxQtY1
* feat(packaging): ship a node firewall profile for inbound WebRTCChristophe Besson2026-09-045-4/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | The packages carried a profile for LAN casting and none for the node's own peer traffic, on the reasoning that the node exposes only a loopback admin API. That is true of its administration surface and false of its transport. WebRTC binds an ephemeral UDP port per connection, so there is no fixed port to open, and a connection succeeds only if one side can initiate. Browsers publish their host candidate as an mDNS `<uuid>.local` name, which aioice cannot resolve on any platform and discards — so the node can never call a browser back, and the browser must call the node. A node that refuses unsolicited inbound UDP is unreachable from every browser on its own LAN, leaving reflexive candidates, which fail whenever both peers share one public IP and the router will not hairpin. Hit twice in one session on two different hosts: a firewalld zone narrowed to mdns + 19550-19553/tcp, and a ufw host with default deny-incoming. Both presented as "the app cannot connect", neither as a firewall message. Passive like the cast profile: packaged, not activated. The guide says to scope it to a LAN zone or source, including the libvirt case, where traffic from a guest to its own hypervisor is not masqueraded and so must be scoped to the guest subnet rather than the LAN. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DtfG7z6wHWj8RKHCvxQtY1
* fix(node): make ice_interfaces match adapters on Windows (W9)Christophe Besson2026-09-044-20/+294
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `ice_interfaces` compared the operator's entry against ifaddr's `adapter.name` only -- the kernel name on Linux (`wlp3s0f0`), but the adapter GUID on Windows (`{846EE342-...}`). A setting written on Linux, or copied into a Windows node's node.toml, matched no adapter at all. The failure was silent and total rather than partial: aioice binds one socket per host address, so an empty list means no sockets, no host candidates, and an SDP offering only a reflexive address. The settings field is free text with no picker, and on Windows the operator sees neither the GUID nor the description -- `ipconfig` shows the connection name -- so an entry now matches the adapter name, the device description, or one of the adapter's own IPv4 addresses, case-insensitively. An address is the one identifier visible on every platform. A filter that matches nothing now falls back to the unfiltered list with a warning. Losing the 5 s timeout saving is a regression; being silently unconnectable is a defect. Also fixes IPv4/IPv6 discrimination in the same loop: the two were told apart by falling through to an `elif` that index-probed `ip.ip[0]` and `ip.ip[2]`, which on an IPv4 str yields characters that compared unequal by luck rather than by design. Now discriminated by isinstance. WINDOWS-PORT.md claimed Transport had "no platform dependency"; it does. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DtfG7z6wHWj8RKHCvxQtY1
* fix(client): publish the real local IP on every platform, not just win32Christophe Besson2026-09-041-10/+16
| | | | | | | | | | | | | | | | | | | | | | | | Chromium replaces host candidates with random `<uuid>.local` mDNS names. aioice has no mDNS resolver on any platform: it logs `Remote candidate "<uuid>.local" could not be resolved` and drops the candidate. Concealment therefore does not degrade for us, it deletes the only LAN-routable candidate and leaves reflexive pairs -- which fail whenever both peers are behind the same NAT, because that pair needs the router to hairpin. Measured with a Linux client and a node in a libvirt guest: exactly one pair formed, host -> srflx on a shared public address, five binding requests, zero responses, FAILED after 63 s. The same log shows a peer on the guest's own subnet succeeding in 24 ms with a real-IP host candidate. 5022f2b scoped this to win32 from a session where the guest ran the *client*, so the condition encoded "the machine being debugged" rather than "the peer is a node". The peer is always a node, on every platform. The trade is that our private address reaches the hub and the node in the SDP -- the user's own infrastructure, not an arbitrary page. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DtfG7z6wHWj8RKHCvxQtY1
* feat(packaging): put the bundled meshbay-node on the per-user PATHChristophe Besson2026-09-043-5/+61
| | | | | | | | | | | | | | | | The installer had no console entry point, so running the CLI meant cd-ing into resources\node-runtime\ every time. installer.nsh now adds that dir to HKCU\Environment\Path on install and removes it on uninstall, via stock WordFunc.nsh (electron-builder's NSIS bundle has no EnVar plugin). It points at the real meshbay-node.exe dir — not a shim — so `where meshbay-node`, findNodeBinary and the W3 autostart launcher all resolve to the same binary. A WM_SETTINGCHANGE broadcast nudges open shells; new ones just work. Rebuilt: electron-builder --win nsis compiles the WordFunc includes fine, MeshBay-Setup-0.1.0.exe (155 MB). test_packaging_win.py covers the add/remove symmetry. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* feat: Windows installer (W4) — one per-user NSIS package, client + nodeChristophe Besson2026-09-0414-43/+838
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `npm run dist:win` produces MeshBay-Setup-<version>.exe: the Electron client and, beside it under resources/node-runtime/, the frozen meshbay-node daemon (meshbay-common inside it). No hub. Per-user, no elevation — matches the W3 constraint that a logon-triggered scheduled task needs admin. electron-builder / package.json build.win nsis, build/icon.ico, extraResources -> node-runtime/ build.nsis oneClick:false perMachine:false allowElevation:false allowToChangeInstallationDirectory:true dist:win -> packaging/win/build-win.ps1 (mirrors dist -> build-client.sh) packaging/win/ meshbay-node.spec + node-entry.py PyInstaller freeze of meshbay_node.daemon:main. The awkward deps (aiortc, av, aioquic, pydantic_core, uvicorn, watchdog, guessit, blake3, tzdata) are pulled in whole with collect_all — that list is expected to grow when a frozen run raises ModuleNotFoundError. build-node-runtime.ps1 throwaway venv -> pip install -> PyInstaller -> packages/meshbay-client/node-runtime/ (gitignored) build-win.ps1 Node>=22 check, npm ci, Electron bump, sync-ui, node runtime, electron-builder --win nsis bump-electron.mjs the Chromium-CVE "build against latest Electron" policy, out of the PS script (5.1 here-string terminator rules) README.md PyInstaller, not the python-embed zip: the frozen meshbay-node.exe is a genuine relocatable single binary, which is what src/main.js:findNodeBinary spawns (process.resourcesPath/node-runtime/meshbay-node.exe when packaged) and what the W3 autostart launcher points at. The embeddable zip needs pip to make that wrapper and the wrapper bakes in an absolute interpreter path. build/installer.nsh: on uninstall, taskkill meshbay-node.exe and delete the W3 Startup .vbs (it would point wscript at a deleted binary every sign-in). %LOCALAPPDATA%\meshbay\ — node.toml, keystore.enc — is never touched. ffmpeg is not bundled by default (node finds it on PATH); build-win.ps1 -FfmpegDir copies ffmpeg.exe/ffprobe.exe in for a self-contained installer. Verified on the Windows guest: PyInstaller freeze builds first try (node-runtime 147 MB), frozen `meshbay-node status` talks to the live daemon's loopback API; electron-builder --win nsis produces MeshBay-Setup-0.1.0.exe (155 MB), oneClick/perMachine flags applied, node-runtime bundled at the path findNodeBinary expects. test_packaging_win.py (14) pins the config invariants and the NSIS <-> platform.py autostart seam. Node suite 798 pass / 34 skip. Open: Authenticode signing (13.9 — unsigned => SmartScreen), Windows CI (18.3), electron-updater. First clean-machine install + DPAPI + autostart round-trip is a manual check. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* feat: Windows daemon lifecycle (W3) — Startup-folder autostartChristophe Besson2026-09-046-17/+348
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Linux node runs under `systemctl --user`. Windows has no per-user equivalent that works without elevation: `schtasks /create /sc ONLOGON` (even `/rl LIMITED /it`) fails with "Access is denied" for a non-admin user, because a logon trigger touches machine-wide scheduler state. So autostart is a `.vbs` in the per-user Startup folder instead: CreateObject("WScript.Shell").Run Chr(34) & "<exe>" & Chr(34), 0, False wscript runs it at every sign-in, hidden (0) and non-blocking. No admin, no console window, no new dependency. Verified end to end: the launcher brings the daemon up with no window and it answers its loopback API. node/platform.py autostart_install/remove/status — write / delete / detect the launcher autostart_run/end — start now (DETACHED|NO_WINDOW) / taskkill _node_exe — PATH, then next to sys.executable, then argv[0] node/daemon.py new `autostart install|remove|start|stop|status` verb reload (win32) -> POST /api/reload on the loopback API restart-daemon (win32) -> autostart_end + autostart_run reset (win32) -> also removes the launcher client/main.js, preload.js node:autostart handler + winAutostart* helpers (kept in step with platform.py) node:service-status (win32) probes the daemon; stop/restart/start use taskkill + a detached, windowless spawn Tests: 8 autostart cases in test_platform.py (mocked sys.platform, APPDATA pointed at tmp); `autostart status` added to the CLI dispatch sweep. Full meshbay-node suite green on Windows (784 passed / 34 skipped). Still open: no CTRL_CLOSE_EVENT handler, so a bare taskkill / window close does not run _shutdown() (SetConsoleCtrlHandler, follow-up). Service mode (pywin32/NSSM) stays Phase 2. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* fix(node): run on the default Windows event loop (Proactor)Christophe Besson2026-09-043-20/+28
| | | | | | | | | | | | | | | | | | Verified end to end: a live browser peer on Windows connecting to a Windows node — handshake, index sync, file download and an ffmpeg-transcoded video stream all work on the ProactorEventLoop. aiortc only hangs on it in the same-process loopback the tests use, which the repo-root conftest already handles for the suite. So the daemon no longer forces the SelectorEventLoop: that fixed aiortc-in-one-process but broke ffmpeg (no subprocess support on a Windows SelectorEventLoop). `use_compatible_event_loop()` becomes `configure_event_loop()` — a no-op unless MESHBAY_NODE_EVENT_LOOP=selector is set explicitly, as an escape hatch that probably never needs pulling. This drops the planned "move ffmpeg off the asyncio loop" work. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* fix: tolerate clock skew when verifying JWTs (leeway 60s)Christophe Besson2026-09-044-3/+17
| | | | | | | | | | | | | | | A client whose clock is a little fast could not connect at all: the MNP handshake verified the hub-issued token with no leeway, so a token whose `iat` was a few seconds ahead of the node's clock failed with "the token is not yet valid (iat)". Seen against a freshly-resumed VM guest. `meshbay_common.handshake.JWT_LEEWAY_SECONDS = 60` is the shared value; applied to the handshake, the node's own hub-token decode, revocation-token verification, and the hub's access-token decode. 60s absorbs NTP-level skew without meaningfully widening the window on a stolen token (they already carry a jti and an exp). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* fix(node): MESHBAY_NODE_EVENT_LOOP=proactor to opt out of the selector loopChristophe Besson2026-09-041-5/+11
| | | | | | | | | Whether aiortc actually hangs on the ProactorEventLoop for a live peer (as opposed to the same-process loopback the tests use) is still open. This lets a Windows node keep the default loop for that comparison — and, if Proactor turns out fine, keep subprocess ffmpeg working without a code change. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* fix(node): make init, node.toml editing and CLI output work on WindowsChristophe Besson2026-09-044-7/+68
| | | | | | | | | | | | | | | | | | | | | Found by running the daemon on Windows for the first time: - `meshbay-node init` wrote `unlock_file = "C:\Users\..."`, and attach_group / add_root write `path = "C:\..."` — a raw Windows path in a TOML basic string is a parse error (`\U`, `\a`, ... are escape sequences), so the config would not load. All now write `Path(...).as_posix()`; pathlib reads the forward-slash form fine on Windows. - any `print()` carrying a `->` arrow or em dash (the CLI help and messages are full of them) raised UnicodeEncodeError on a cp1252 console and took the command down. New `platform.force_utf8_stdio()` reconfigures stdout/stderr to UTF-8, called at the top of `main()`. Verified on Windows: init writes parseable LF node.toml, the keystore Argon2-decrypts, the loopback control API binds 127.0.0.1, and `_update_node_toml` reads a CRLF file and rewrites it LF-only with its standalone comments intact. Two regression tests added in test_ops.py. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* test(node): make the suite pass on WindowsChristophe Besson2026-09-0415-29/+167
| | | | | | | | | | | | | | | | | | | - `.read_text()` on source files now `encoding="utf-8"` — cp1252 chokes on the em dashes / box-drawing chars those files contain. - test node.toml templates embed paths via `Path.as_posix()`: a raw Windows path in a basic TOML string is a parse error (`\U`, `\a`, ... are escapes). - new `test_platform.py` covers `meshbay_node.platform` by mocking `sys.platform` / `os.environ` — runs on both OSes. - `skipif(sys.platform == "win32")`, in `conftest.needs_subprocess` and inline, for the documented gaps: ffmpeg/ffprobe via asyncio subprocess (the win32 selector loop, forced for aiortc, cannot spawn one), the systemd `reload`/`restart-daemon` delegation (Windows path is W3), the keystore `st_mode == 600` assertion (NTFS ignores mode bits), and the symlink-escape test (needs Developer Mode). Windows: 781 passed, 25 skipped. No change on Linux. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* fix(node): pin utf-8 (and LF) on every text file the node reads or writesChristophe Besson2026-09-046-25/+25
| | | | | | | | | | | | | | | node.toml, the keystore envelope, the unlock key, the loopback UI token, pairing/invite code files and the denylist were all read and written with the platform default encoding and newline translation. On Windows that is cp1252 + CRLF: a node.toml or keystore holding any non-ASCII byte failed to load, and ops.py's line-based node.toml editor round-tripped CRLF in and LF out. Every read is now `encoding="utf-8"`; every write is `encoding="utf-8", newline="\n"` so the files stay LF whatever the OS. No-op where the locale was already UTF-8. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* fix(client): resolve STUN hostnames in the main processChristophe Besson2026-09-043-8/+65
| | | | | | | | | | | | | | | | | | | | | | | Chromium's P2P socket manager failed every STUN hostname with ERR_NAME_NOT_RESOLVED in a restricted-resolver environment (a Windows KVM guest), even though its own general network stack, the OS resolver and Node's resolver all resolved the same names -- and mapping the names to IPs with --host-resolver-rules changed nothing, so it is not ordinary resolution. WebRTC was left with no server-reflexive candidate. The desktop client now resolves the STUN hostnames in the main process (`ice:resolve-stun`, Node's dns.resolve4) and hands `transport.js` the IP form; a name that will not resolve (the decommissioned Mozilla host) is dropped. In a browser there is no `meshbay` bridge and the hostnames are used unchanged -- a browser resolves them fine, so that path is untouched. Falls back to the hostname form if the bridge call throws. Also, scoped to win32: disable WebRtcHideLocalIpsWithMdns, so the client publishes its real local IP instead of a `.local` name the node's ICE stack cannot resolve across the KVM bridge. Changes nothing on Linux/macOS. Test-env workaround, revisit before release. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* fix(node): select the Windows-compatible event loop before asyncio.runChristophe Besson2026-09-042-0/+22
| | | | | | | | | | | | | aiortc's ICE stack does not run on Windows' default ProactorEventLoop -- a DataChannel handshake never completes. `platform.use_compatible_event_loop()` switches to the SelectorEventLoop on win32, called at the top of `main()` before `asyncio.run()`. No-op off Windows. Known cost, for when the node runs on Windows: the SelectorEventLoop cannot spawn subprocesses, so ffmpeg streaming (asyncio.create_subprocess_exec in webrtc_server.py) needs a thread-based runner there. Tracked separately. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* test: add pytest-timeout and pin the Windows selector event loopChristophe Besson2026-09-045-3/+22
| | | | | | | | | | | | | | | A hung test could wedge the whole run: aiortc's ICE stack never completes a loopback DataChannel handshake on Windows' default ProactorEventLoop, and nothing capped it. Two changes, both no-ops off Windows: - `timeout = 60` in the root pytest config (+ pytest-timeout in the dev extras) so a stall fails the test instead of the suite. - a root conftest that selects WindowsSelectorEventLoopPolicy on win32 only, which is what aiortc needs there. Trade-off, documented: the selector loop cannot spawn subprocesses on Windows, so the ffmpeg streaming tests fail there rather than pass -- they need a per-module override or skipif(win32). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* refactor(node): platform abstraction for Windows portability (W1-W2-W5-W6-W7)Christophe Besson2026-09-0312-67/+183
| | | | | | | | | Platform directories, signal handling, chmod guards, ffmpeg discovery, and platform-conditional CLI messages — all testable on Linux. See docs/WINDOWS-PORT.md §5 for the plan these implement. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* feat!: MNP 1.0 — seal index and handshake_ack under the group keyChristophe Besson2026-09-0323-88/+1636
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `index_sync`, `index_delta` and the `handshake_ack` config payload now travel sealed under a GEK-derived subkey (`meshbay_common/groupbox.py`, mirrored by `sealGroup`/`openGroup` in `crypto.js`). Only `type`, `v`, `group_id` and the ack's `node_pk`/`proof`/`sig` stay in clear — a receiver must route and authenticate before it would trust a decryption. Verify, then decrypt. The ack line is integrity, not confidentiality: the signed handshake transcript names no ack field, so `is_node_admin`, `enabled_apps`, `video_root` and the rest were authenticated by the DTLS channel alone. The index line is defence in depth against a repeat of C1/C6 — a peer served before the handshake completes now gets ciphertext, not filenames. Nothing against an observer, the hub, or a member; that is the whole claim. `index_progress` stays clear (D3, counters only). Chat is out of scope. Failure is fatal: a payload that does not open ends the session naming the message type — never an empty index or an empty `enabled_apps`, both of which are legitimate states. Version negotiation ships here too (phase 15.6, brought forward): `v` + `v_min` on `handshake` and `handshake_challenge`, refused with `version_too_old` / `version_too_new` / `version_unreadable`. The flag day was already being paid for; the next breaking change now costs a refusal message. BREAKING CHANGE: breaks the WebRTC wire every deployed client speaks. Hub and every node must deploy together; the SPA is served by the hub, so a browser picks up the new client on reload. See MESHBAY_NODE_PROTOCOL.md §11.1a, §13.1. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01HkzbhmMmK8PqQBtGz5zCvY
* docs: Windows port audit and sender key distribution decisionChristophe Besson2026-09-033-36/+542
| | | | | | | | | | | | Add docs/WINDOWS-PORT.md with the full portability audit (what is already portable, what blocks, implementation plan W1-W7). Reverse structural decision 20: sender keys are distributed GEK-wrapped, not pairwise to identity keys. The GEK is the group secret; files and chat share the same access boundary. Per-device chains (15.0b) remain required for correctness. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* fix(node): reload the user manager before reload/restart-daemonChristophe Besson2026-09-032-1/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Reported live: after installing the .deb, systemd printed "Warning: The unit file, source configuration file or drop-ins of meshbay-node.service changed on disk. Run 'systemctl --user daemon-reload' to reload units." Both postinst scripts (deb and rpm) already run a daemon-reload, but only for the system manager — they run as root, and the unit that changed is the *user* unit (packaging/systemd/meshbay-node-user.service), owned by each signed-in person's own user manager, a different process root cannot reach. Iterating over logged-in users from postinst was considered and rejected: fragile (depends on machined and each user's session bus), and root has no business doing a user's job. `_systemctl_user` — the one place `reload` and `restart-daemon` already shell out to systemd — now reloads the user manager first, under the correct privilege, right before the verb that would otherwise act on a stale unit. Best-effort and unchecked, like the postinst's own daemon-reload: a reload the manager did not need must never block what the operator asked for, and systemd still reports a genuine failure from the verb itself. Does not touch the postinst scripts. On a package upgrade the warning can still appear once, before the next reload/restart-daemon (or a login, which starts a fresh user manager that reads the current file); this closes it from the CLI's own lifecycle commands rather than reaching into every session from root. test_lifecycle_commands_delegate_to_systemctl_user now expects the daemon-reload call ahead of the verb — checked failing against the previous code. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AbwJDbNTkiRUh7HTWEoyss
* refactor(hub): drop the base64 chunk fallback and the dead HTTP file clientChristophe Besson2026-09-032-78/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | With MNP 0.15 no node can emit a base64 `file_chunk`, so the browser's fallback for that shape is unreachable. Three things go with it: - `file-utils.js` kept a third branch below the fallback that base64-decoded `chunkMsg.ct_b64 || chunkMsg.data_b64` when neither was present, i.e. decoded `undefined` and wrote the result into the file the user was saving. A chunk we cannot decrypt now stops the download with an error naming the file and suggesting the node is older than the page. Deliberately not in `_isRetryableTransportError`: this is a version mismatch, not a bad moment on the link. - `crypto.js` `decryptChunk` (base64) was the real path until Phase 9.15 and has had no caller since. - `crypto.js` `decryptFile` was never called in any commit. It fetched `${nodeUrl}/file/${id}/${chunk}?token=` in a loop — the node's unauthenticated HTTP file API, which is finding C1 and was deleted in Phase 11.5. A client for an endpoint that no longer exists, kept alive by being exported. `decryptChunkBin` — every file download and every video segment — is untouched. `packages/meshbay-client/ui/` was resynchronised with `npm run sync-ui`. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AsoWC3GmhNdwVFomW3QjH3
* refactor!: one file_chunk and index_sync encoder for every transportChristophe Besson2026-09-0311-201/+379
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `file_chunk` and `index_sync` were each built twice, once per transport, and the two copies did not agree. WebRTC sent binary, unsigned chunks carrying a `file_id`; QUIC sent base64 fields, two BLAKE3 hashes, a per-chunk Ed25519 signature and no `file_id`. `index_sync` was plain entries on one transport and a `GroupIndex.serialize()` envelope on the other. One message type, two shapes, one consumer each, and nothing that failed when they drifted — finding C6 one size down, in the two places the handshake unification did not reach. Phase 9.15 moved WebRTC to the binary format and dropped the per-chunk signature; the QUIC encoder was never brought along. It is dropped here rather than reintroduced: the AES-GCM tag authenticates the ciphertext under a GEK-derived key, and since C3 the node authenticates itself once in the handshake instead of once per megabyte. `meshbay_common.protocol` now owns the chunk codec (`chunk_ciphertext`, `file_chunk_wire`, `file_chunk_plaintext`) and `meshbay_node/transport/wire.py` the index builder, which also absorbs the delta the daemon used to hand-build. `test_transport_wire_parity.py` fails if either server grows its own copy back. `ChunkRequest`/`ChunkResponse` are deleted. `ChunkResponse` described the QUIC half while reading like the contract for both, which is what made the fork hard to see at all. BREAKING CHANGE: MNP 0.15 changes the encoding of `file_chunk` and `index_sync` on the QUIC transport. The WebRTC shapes are byte for byte unchanged and no QUIC client ships, which is why this is a MINOR bump; a deployed QUIC peer would have made it MAJOR. Also fixes a test fixture that put a `Path` where the daemon puts a `RootSet`. Nothing caught it: the old QUIC index handler never touched `roots`, and `entry_abs_path` fell through `Path.resolve(strict=...)`, reading the virtual path as a truthy flag and returning the right file by accident. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AsoWC3GmhNdwVFomW3QjH3
* fix(hub): route the chat ack to the request that asked for itChristophe Besson2026-09-034-0/+336
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Typing a message froze the Chat tab: the composer stopped taking clicks and keystrokes, the message never appeared, and it was there all along on the next visit to the tab. The node answers a chat message with a bare {"type": "ack"} -- no request id, no type of its own -- so _dispatch had nothing to match it on and left it to the arrival-order guess at the end of the function. That guess is wrong the moment anything else this browser asked for is still waiting: the ack went to *that* request, and the chat send waited out _sendAndWait's own 30s timeout. Since the composer is disabled while a send is in flight, that reads as a frozen tab; the node had stored the message and answered, into somebody else's promise. An outstanding request is the ordinary case, not a rare one. The node refuses an unknown file_id with a bare `error`, which names no request either and so reaches none, leaving the Videos tab's media_meta_req in _pending for the full 30s. That is the one that was live when this was found. - `ack` is now matched by request type: chat_msg, or the keypair-bundle store and delete, which name themselves in `detail`. A node naming neither still has its reply placed rather than dropped. Every line of chat-app.js is correct and every routed message in transport.js is routed correctly -- the defect is in the seam, so tests/harness/ chat_send_probe.py drives the two together: the real ChatPanel over the real MeshBayTransport, with only the DataChannel replaced by a stand-in answering what the node answers. test_chat_send.py asserts against it, and with the fix reverted all three of its tests fail on the three visible halves of the defect -- the composer still disabled, the message absent, and the ack resolving the unrelated request. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GFF4BL8VSKrghkSLzCrTVs
* test(node): check where the systemd units are staged, not what the spec saysChristophe Besson2026-09-031-10/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | test_each_unit_is_installed_where_it_can_run read meshbay-node.spec's %install for `install -D` lines and their destination on the following line. The packaging overhaul (2026-08-31) replaced that section with `cp -a %{_staging_root}/* %{buildroot}/`: the spec no longer places individual files, build-node.sh does, and the spec only declares them in %files. So the test failed against packaging that was correct all along — it was checking a mechanism that no longer existed while the property it defends still held. Both units do land where they can run: build-node.sh:71-76 copies meshbay-node.service to /usr/lib/systemd/system/meshbay-node@.service and meshbay-node-user.service to /usr/lib/systemd/user/meshbay-node.service. It now reads that script. Same guarantee, aimed at the thing that does the work: the template — the one carrying User=%i — into the system directory, and the user unit, which cannot carry User=, into the user one. Checked against three reintroductions of the original defect: swapped destinations, the user unit dropped from staging, and the template renamed. Not verified here: %{_unitdir} and %{_userunitdir} really expanding to those paths. There is no rpm on this machine, so that comes from the RPM convention rather than from `rpm --eval`. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AbwJDbNTkiRUh7HTWEoyss
* fix(node): an invitation the hub never registered is a code nobody can useChristophe Besson2026-09-033-8/+96
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `create_invite` wrote the invite to the roster and *then* asked for the hub. An unreachable hub therefore raised "Hub not connected" after the code was already stored: the operator saw an error and no code, and a valid invitation sat in the roster that nobody had been given. Every retry left another. Registering first means a failure costs nothing — no code exists to be orphaned. A membership row without an invite is harmless: without the code there is still no group key. The endpoint is idempotent (`if not mem: db.add(...)`, no 409), so the SPA registering the same membership again right after createInvite costs nothing either. The registration is now fatal rather than swallowed, which is the part that matters. `/v1/groups/mine` joins GroupMember, so someone who was never registered does not see the group at all and can never redeem the code. Tolerating that failure handed the operator a code that cannot work and said nothing — a worse outcome than the error, because it is silent. Skipped only when there is no username to register with: the MNP path allows an empty one and there the SPA is the one that registers. Found by test_invite_then_join_delivers_the_gek, whose fixture had no hub and which passed only because the failure was swallowed. It has one now. And 0443cf8 added this registration to the CLI path without any test asserting it happened, which is how it came to be skipped whenever the hub was merely absent — test_cli_invite_asks_the_hub_for_an_account_ never_a_key checks it now, and test_an_unreachable_hub_leaves_no_invite_behind covers the orphan (verified failing against the previous ordering). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AbwJDbNTkiRUh7HTWEoyss
* chore(client): build against the latest Electron, and stop defining the ↵Christophe Besson2026-09-034-26/+95
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | package twice Chromium CVEs are fixed in Electron releases, and a client built against an old one ships those holes to every user. That is a certain harm; a build that breaks on a new Electron is a repairable one. build-client.sh now bumps to the latest on every build, prints the comparison, and lets the build fail if it cannot cope — the failure is the signal to fix, not a reason to stay behind. It writes package.json and the lockfile on purpose: the new pin is meant to be committed. A registry it cannot reach is a warning, not a failure. Exercised by pinning back to 42.9.2 and building: "==> Electron 42.9.2 -> 44.1.1", exit 0, electron=44.1.1 in the packaged output. Note npm audit would have said nothing about any of this — Chromium CVEs fixed in Electron do not reliably reach the npm advisory database. Separately, package.json declared linux.target [deb, rpm] with its own deb/rpm depends, so `npm run dist` built a second package under the same name. The two had drifted: /opt/MeshBay/meshbay-client against /opt/meshbay-client/meshbay, and Depends: python3-meshbay-common naming none of the Electron runtime libraries the real DEBIAN/control lists — it would have installed cleanly and then refused to start. Nothing in the tree referenced `npm run dist`, which is why the drift was free to happen. That config is gone, "dist" delegates to build-client.sh, and test_desktop_shell.py refuses its return. `--dir` was re-run with no linux block at all: exit 0, same binary build-client.sh consumes. It needs appId, productName and files, nothing else. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AbwJDbNTkiRUh7HTWEoyss
* chore(client): declare author and homepage in the client package.jsonChristophe Besson2026-09-031-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | electron-builder warned `author is missed in the package.json` on every build, including the `--dir` one build-client.sh runs, and refused the deb/rpm targets outright over it and over a missing homepage. Both were pre-existing — builder 25 emitted the identical warning — and had simply never been hit, because those targets had never been built. The values are copied verbatim from packaging/deb/meshbay-client/DEBIAN/ control, which already declared them, so the two cannot disagree. Not added: `desktopName`, despite the warning that asks for it. The path this project actually ships (build-client.sh + packaging/desktop/ meshbay.desktop) already sets StartupWMClass=MeshBay, and src/main.js sets --class to match for dev runs. The warning concerns the .desktop electron-builder generates for its own deb/rpm targets, which is not what gets installed. That is the larger thing found here and left open: `npm run dist` defines a second, incompatible layout for a package of the same name — /opt/MeshBay/meshbay-client against /opt/meshbay-client/meshbay. See ~/next/npm-audit.md §9. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AbwJDbNTkiRUh7HTWEoyss
* chore(client): clear 12 npm advisories — electron-builder 26, electron 42.11.1Christophe Besson2026-09-032-1946/+1022
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | npm audit reported 12 findings (11 high, 1 critical), every one transitive and every one reached through electron-builder. The critical was tar (<=7.5.20), a family of path-traversal and symlink-poisoning advisories. electron-builder is a devDependency and build.files is src/** and ui/**, so none of it ships: the exposure was to whoever builds a release, not to users. Real, since a build machine producing signed artefacts is worth attacking, but it should not have been read as "the client has a critical vulnerability". electron-builder ^26.15.3 takes the audit to 0 on its own. It is a major, so it was measured rather than assumed: a --dir Linux build passed before and after, and the config used here (appId, files, linux.target, deb/rpm.depends) is nowhere near where 26's breaking changes are. The produced app.asar is not byte-identical to 25's, which matters only for 18.7's hash-and-compare story and is a release note, not a defect. electron ^42.11.1 is a patch bump inside the range already declared, where Electron ships its security backports. The built binary was launched under xvfb: two processes alive after 25s, empty log. That is the part that counts — test_desktop_shell.py pins the security contract by reading source, so it would stay green through any runtime regression. protobufjs's override floor goes ^7.5.5 -> ^7.6.5. The override itself is load-bearing and must stay: removing it drops castv2-client's protobufjs to 6.11.6, which carries a critical RCE advisory — and unlike everything above, protobufjs ships inside the application. But ^7.5.5 permitted 7.5.5, which is inside a high advisory's range (<=7.6.4); npm happened to resolve 7.6.6, so the protection was incidental rather than structural. Electron 44 is deliberately not taken here: two majors and a different Chromium, and nothing in the suite would notice a regression. It needs its own launch session. Audit and evidence: ~/next/npm-audit.md (not in the repo). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AbwJDbNTkiRUh7HTWEoyss
* fix(hub): stop the maintenance loop racing the tests, and pin _ASSETSChristophe Besson2026-09-028-5/+200
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Two defects found while closing out the Search merge, neither of them in that feature. The maintenance loop. create_app's lifespan starts cleanup_loop as an asyncio task, so every test — each entering that lifespan — ran a purge pass concurrently with its own requests. On SQLite :memory: that is not merely noisy: the engine uses a StaticPool, one connection for the whole process, so the request's session and the cleanup task's session interleave transactions on the same connection. A registration could commit and then be invisible to the login three lines later, surfacing as 401 Invalid credentials for an account created moments before, in roughly one run of test_node_ws_auth.py in four. The purge itself is not at fault and this is not a production condition. A passive SQL listener caught the DELETE removing 0 rows, and the INSERT carrying status='active' — so neither the pending-account mechanism nor the purge filter is involved, and PostgreSQL gives every session its own connection. What the fixture removes is the second user of the shared one. 60 runs of the previously flaky file, 0 failures; reproductions before the fix landed on attempts 4, 6, 13 and 29 of separate loops, so a clean run of 60 has about a 1% chance of being luck. _ASSETS. source-merge.js shipped missing from webapp._ASSETS, the cache-busting hash's input list — exactly the silent failure docs/apps.md §4 step 5 warns about: the file changes, the asset URL does not, and a browser holding the old page keeps the old copy. Harmless this time only because search-page.js changed in the same commit and is listed, which is the worst way for it to go unnoticed. Found by re-reading that checklist for the doc pass, not by any test — so there is a test now, holding _ASSETS to every .js in static/ (sw.js excepted, unversioned on purpose). It was the only one missing. Phase 9 of docs/refactoring-search.md also lands here: mediacenter.md §10.6, musicbay.md §9b, photos.md §10b, apps.md §2b and step 5. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AbwJDbNTkiRUh7HTWEoyss
* fix(hub): merge duplicate sources in Search's Music and Photos tooChristophe Besson2026-09-0221-246/+670
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Phases 5-8 of docs/refactoring-search.md, extending the Videos merge outward. A library shared by two groups now lists each track once inside an album and each photo once inside a photo album, and a card served by several groups says "N sources" instead of naming one of them. Units come from each application's own grouping, never a copy of its keys. For Music that meant exporting foldKey: groupMusicEntries folds case to group but keeps the first-seen spelling to display, and which group is seen first is whichever index arrived first — so keying a unit on the display strings would let the chosen source change between page loads. A group whose connection fails is marked down and stops being chosen, so a unit fails over to another group that has the file. Eviction is not a failure. Every source being down still yields an entry: a tile that fails to load beats a film that vanished from the grid. sourceLabel now takes the whole unit rather than one entry. A show's poster entry is picked for its thumbnail, so a show in two groups whose cover episode sits in only one of them would have claimed a single source. SourceTag lives in group-name.js — source-merge.js must keep importing nothing (its test executes it standalone), and a copy in each of the three apps is three chances to disagree. test_search_files_unmerged.py holds the one thing that must not change: the Files explorer is not merged, because there each group is a folder and merging would remove a file from one of them. It also asserts the other three lists are merged, or deleting the merge outright would leave it passing and saying nothing. One plan item was dropped as wrong rather than built: the Music queue in onPreview needed no change. It filters by groupId and is reachable only from FilesPanel, which is not merged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AbwJDbNTkiRUh7HTWEoyss
* fix(hub): one entry per file in the Search view's Videos gridChristophe Besson2026-09-026-12/+762
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A library shared by two groups arrived in the cross-group Search view as two entries per file: every film was two poster cards, every episode was listed twice in the season list under the synopsis. Inside one group this cannot happen — GroupIndex is keyed by blake3 — so the duplication was the Search page's own, from concatenating N independently keyed indexes. source-merge.js folds entries on the content hash and resolves one source per *unit* (a film, a whole show), so a season does not scatter across two nodes. A group hosted by the reader's own node wins; failing that the pick is a hash of the unit key and the reader's id, stable across renders and reloads — a source that changed mid-stream would tear down the connection under a film that is playing — and spread across readers and units. The units come from video-app.js's own groupVideoEntries rather than a second copy of its keys here. Only the Videos view is wired up so far; Music, Photos, failover and the "N sources" badge are phases 5-8 of docs/refactoring-search.md. Every test was checked against the fix removed. That is how the first version of "a unit's files share its source" turned out to prove nothing: with every episode in every group, per-file and per-unit picking give the same answer, so it passed against a per-file implementation. It now uses a unit whose files have unequal sources. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AbwJDbNTkiRUh7HTWEoyss
* docs: plan for merging duplicate sources in the Search viewChristophe Besson2026-09-021-0/+376
| | | | | | | | | | | | | | | | | A file shared by two groups is two entries in the cross-group Search view: one film shows as two poster cards, one episode twice in a show's list, one track twice in an album. Within a group this cannot happen — GroupIndex is keyed by blake3 — so the duplication is created by the Search page concatenating N independently keyed indexes. The plan: merge on the content hash, choose one source per logical unit (film, show, album), prefer a group hosted by the local node, otherwise pick deterministically per user, and fail over when the chosen source is unreachable. The Files explorer stays navigable per group and is not merged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AbwJDbNTkiRUh7HTWEoyss
* fix(hub): dismissing a notification deletes itChristophe Besson2026-09-025-31/+109
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The previous commit filtered the list to unread, which corrected what the reader saw and left every dismissed row in the table, invisible for ever. That is a place to hide the disagreement rather than a resolution, and the operator said so: "elles s'accumulent pour rien." So dismissing drops the row. It is the reasoning `purge_notifications` has carried all along — "these are signals, not a record: the group is still there, the message is still in the chat, the invitation is still an invitation" — applied one at a time instead of only in bulk. - `DELETE /v1/notifications/{id}` is the honest name and what the SPA calls. - `POST /{id}/read` reaches the same handler and now deletes too. It has to keep working: the interface ships inside the desktop package, so a hub is always answering some client older than itself, and giving the old path the new behaviour means those clients stop hoarding as well rather than only the updated ones. - `read-all` deletes rather than marking, which makes it `DELETE ""` under an older name. Marking would have made it the one route still filling the table. Nothing in this repo calls it, but a reachable endpoint is one that can be called. `Notification.read` is now vestigial — nothing stored can be read, because reading it deletes it. It stays because dropping a column is a migration for no gain, and `unread_only` stays because a SPA newer than its hub still needs it to be right. Both are said in the module docstring rather than left to be worked out. Two existing tests encoded the old semantics and now assert the opposite; test_notification_dismissal.py gains one for the old `/read` path, because version skew is the normal case here and not the exception. 617 hub tests pass. docs/USERGUIDE.md's endpoint table updated in both places it lists them. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014UtzVrzM7e2tG9fSpkR9ML
* fix(hub): a dismissed notification stays dismissed across a restartChristophe Besson2026-09-022-2/+152
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Clicking a notification navigated to the group and the entry disappeared — the intended behaviour — and it was back on the next launch. Neither half was wrong on its own, which is why it survived. `markRead` drops the entry locally *and* marks it read on the hub, deliberately: "Reading it is the point of clicking it: it goes, here and in the count, rather than sitting there greyed out." The hub honoured that and persisted it. But the startup fetch asked for `/v1/notifications?limit=20` with no filter, and the endpoint returns read and unread alike, so every dismissed notification came straight back. It asks for `unread_only=true` now — a parameter the endpoint already had and already tested. The feed still carried the fossil of the older intent: `class="notif-item ${n.read ? '' : 'notif-unread'}"`, styling for a read entry rendered greyed out, from before clicking meant dismissing. Nothing read reaches the feed any more, so that branch was dead code describing behaviour the application had abandoned — and noticing it is what made the two halves' disagreement visible. Removed. `unread_count` is computed server-side over the whole table and is unaffected by the filter, so the bell is unchanged. test_notification_dismissal.py holds both halves: the API round trip that is the reported bug (list, read, list again), its mirror showing the unfiltered endpoint still returns it — so the fix cannot read as a coincidence — and a static check that the SPA asks for the filter, which is the only one of the three that catches the defect that actually happened. Verified by dropping the parameter again: that one fails, the API tests do not. Read notifications now accumulate unread in the table rather than being deleted. Purge removes them; the volume is small. Making dismissal a delete would suit `purge_notifications`' own docstring — "these are signals, not a record" — but it would leave `/read` a misnomer and `read-all` inconsistent, so it is a separate decision. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014UtzVrzM7e2tG9fSpkR9ML
* fix(hub): a desktop solve reports no hostname at all, not "meshbay"Christophe Besson2026-09-027-33/+168
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Registering from the native client failed with `captcha_failed` while the checkbox was green — a worse symptom than the one being fixed, because the widget now looked fine and only the hub's own log said otherwise: captcha solved on an unexpected host ''; allowed: ['localhost', 'meshbay', 'meshbay.org'] The previous commit assumed Google would report the host component of the origin, so `app://meshbay` would come back as `meshbay` and could sit in `allowed_hosts`. It does not. A solve Google cannot attribute to a domain reports an **empty** hostname, and no allowlist entry can match that. An empty entry is not the answer either: a blank in a TOML list is a typo far more often than an intention, and `load_config` drops blanks for that reason — `captcha.allow_unattributed_host` is a named flag instead, so the trade is stated where it is made. What it admits, plainly: every non-web client, not only ours. A file:// page or somebody else's Electron application look identical from here. That is the same bar the client's own origin would have been — main.js already records that `app://meshbay` is not a credential — and it is a bar: the captcha still has to be solved, per token, in something that can render it. What is given up is the origin restriction for non-web clients, not the captcha. Off by default, and a hub without the desktop client should leave it off. The refusal now names which of the two it is, since they need different answers: an unexpected host names the host, an unattributed one says to set the flag. docs/captcha.md §6 said `meshbay` was the value and told operators to add it; it now records what was measured and why the guess was wrong. The packaged example config carries the flag with the same warning. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014UtzVrzM7e2tG9fSpkR9ML
* build(client): say when a build has reset the local chrome-sandboxChristophe Besson2026-09-021-0/+20
| | | | | | | | | | | | | | | | | | | | | | | | `build-client.sh` runs `npm ci`, which deletes node_modules wholesale, then re-extracts Electron's dist. A chrome-sandbox that had been made root-owned 4755 for local development comes back 755 and owned by whoever ran the build. Running the app straight from node_modules then aborts outright: FATAL: The SUID sandbox helper binary was found, but is not configured correctly. Rather than run without sandboxing I'm aborting now. Chromium refusing to start beats it quietly dropping the sandbox, and that refusal is baffling if the crash is not connected to a package build run minutes earlier — the two look unrelated, and the file's own mtime is 1980 either way, so nothing on it points at what happened. The build now says so, with the command to put it back. Said and not done: a build script has no business setting a setuid bit behind someone's back, and this one uses no sudo. The packaged app was never affected — packaging/deb/meshbay-client/DEBIAN/postinst does the chown+chmod at install time, which is where it belongs. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014UtzVrzM7e2tG9fSpkR9ML
* fix(packaging): ship the example hub config, and stop leaving /etc/meshbay openChristophe Besson2026-09-024-12/+112
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Three defects, found while answering whether installing the .deb would land where the production server was just moved to by hand. - **The example config was never packaged.** `build-hub.sh` copied `packaging/conf/hub.toml.example` under `if [ -f ]`, and that path does not exist in this repo — so every package ever built shipped no example at all and said nothing about it. The postinst places no config either, on purpose (a shipped hub.toml is overwritten on upgrade; a shipped secret gets run in production), which left an installed hub with nothing to copy from. The file now exists, documents every key `config.py` reads including the captcha `allowed_hosts` the desktop client needs, and the copy is a hard failure rather than a silent skip. - **`/etc/meshbay` was created 0755.** It holds the hub's Ed25519 private key and its database password. The file modes protect the contents, but a world-listable config directory tells anyone with a shell what a hub keeps and where. Now 0750 root:meshbay, in both the deb postinst and the rpm scriptlet; the service reads it by group. - **The rpm would have failed to build on the new file.** `%files` claimed nothing under /etc, and rpmbuild refuses an installed file no line claims. It now declares the directory and the example, with explicit `%attr` and `%config` so an operator's edits become .rpmsave rather than vanishing. Package modes no longer follow the builder's umask either — the same source tree produced 775/664 on a machine with umask 002 and 755/644 with 022. `install -m` sets them. Verified by building: the deb now carries ./etc/meshbay/ at drwxr-x--- with hub.toml.example at 0644, and the embedded postinst tightens the directory as belt and braces rather than as the only thing making it right. The rpm path is unverified — no rpmbuild on this machine. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014UtzVrzM7e2tG9fSpkR9ML
* fix(hub): check the captcha's origin here, so the desktop client can pass oneChristophe Besson2026-09-026-42/+314
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Reported from the native client: the reCAPTCHA box renders "ERROR for site owner: Invalid domain for site key". The web browser is fine. It is not a client restriction, and the CSP was never what refused — the script loads, which is why the widget appears at all to say so. reCAPTCHA validates the hostname of the page the widget is rendered in against the domain list on the site key, and the desktop client's interface ships inside the package and is served from `app://meshbay` (main.js: `win.loadURL`). Not a preference: file:// breaks ES modules and IndexedDB, and the hub must never become the document origin. So the hostname Google sees is `meshbay`, it is not on the key's list, and it never can be — the check runs on Google's servers and nothing client-side reaches it. The fix turns that check off on the key and does it on the hub instead: [captcha] allowed_hosts = ["meshbay.org", "localhost", "meshbay"] `verify_captcha` refuses a solve whose hostname is not in the list. The hostname comes from `siteverify` — what Google observed, not what the caller asserts — so it is a real check against what turning the console setting off opens, which is a bot rendering the public site key on a page of its own. Empty (the default) skips it, so an existing hub upgrades unchanged with reCAPTCHA still doing the origin check. The two settings go together, and docs/captcha.md §6 says so. The `meshbay` entry is the weak one and the doc says that too: any Electron application can claim the same scheme and host, as main.js already records. What it still costs is a captcha solve per token inside a real Chromium instead of a token farmed from any web page. docs/captcha.md §6 replaced. It documented a design that was superseded twice — an `auth_key`-keyed carve-out that turned out to disable the gate for everyone, and "works in the Electron client too, both run Chromium", which is the assumption this bug is made of: reCAPTCHA validates the domain, not the rendering engine. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014UtzVrzM7e2tG9fSpkR9ML
generated by cgit v1.2.3 (git 2.51.0) at 2026-09-25 21:30:43 +0000