aboutsummaryrefslogtreecommitdiffstats
path: root/packages
Commit message (Collapse)AuthorAgeFilesLines
* fix(node): make ice_interfaces match adapters on Windows (W9)Christophe Besson2026-09-043-19/+267
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `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-042-5/+55
| | | | | | | | | | | | | | | | 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-045-3/+211
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `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-043-3/+3
| | | | | | | | | | | | | | | 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-0321-85/+1604
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `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
* 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-033-0/+315
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-033-26/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-023-1/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-0220-223/+627
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-025-6/+742
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* fix(hub): dismissing a notification deletes itChristophe Besson2026-09-024-27/+103
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-025-12/+114
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* fix(hub): check the captcha's origin here, so the desktop client can pass oneChristophe Besson2026-09-025-3/+243
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* fix(hub): the Node page takes the width of a settings pageChristophe Besson2026-09-022-1/+181
| | | | | | | | | | | | | | | | | | | | | | | | `.node-page` carried `max-width: 700px` of its own while Settings, Profile and the create-group wizard take `.main`'s. The audit tab is a six-column table — timestamp, event, user, IP, group, detail — with every fixed-shape column set `white-space: nowrap` so an IP is never clipped, so at 700px it scrolled sideways inside `.node-table-scroll` with a couple of hundred pixels of `.main` empty beside it. Measured at 1024: 596px of table box where the page had 856px to give. The rule goes; the class stays as the anchor for the assertions. `.node-group` and `.settings-section` are already the same rule twice over (same background, border, radius, padding), so the two pages now line up card for card. test_node_page_width_measured.py: the Node page and a Settings page are the same width at every width from 320 up, their cards the same rectangle, the audit table no longer wider than its scroller at 1024, and — the narrow case being the design rather than a regression — the table still scrolling inside its own box on a phone without pushing the document sideways. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014UtzVrzM7e2tG9fSpkR9ML
* fix(hub): a show opens on its first season, not its first thumbnailChristophe Besson2026-09-022-10/+133
| | | | | | | | | | | | | | | | | | | | | | | | | | | Reported live: a show with a dozen seasons opened on season 6. Every season was in the picker and none was missing — the default was wrong. VideoDetailModal took it from `repEntry.season`. `repEntry` is the show's "representative entry", which the poster grid picks as `episodes.find((e) => e.thumb_hash) || episodes[0]`: the first episode that has a thumbnail, so the card has a fallback frame when TMDB has no poster. That is from the original Videos commit; the season tabs came later and read the same entry as "the episode the reader is looking at", which it never was on that path. Episodes are sorted by (season, episode), so a show whose first five seasons had no thumbnail yet — a partial enrichment pass, or ffmpeg failing on those files — hands back a season-6 episode. `defaultSeason(show)` reads the season list and nothing else: the lowest season present, specials only when there is nothing else, and the lowest *number* rather than the first entry so it does not quietly depend on buildSeasons keeping its sort. The effect's dependency on repEntry goes with it — nothing in it reads that any more. test_video_default_season.py runs the function in node. No input it takes can carry a thumbnail, which is the point. docs/mediacenter.md §10.5. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014UtzVrzM7e2tG9fSpkR9ML
* fix(hub): the show detail modal must not move when the season doesChristophe Besson2026-09-024-117/+449
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The previous pass fixed the synopsis and the cast, and the dialog still jumped: the episode count moves things a fixed-height synopsis cannot reach. - The body scrolled as a whole, so a thirteen-episode season pushed the modal to its max-height where a six-episode one had not. `.video-overlay` centres its child, so the taller modal also *started higher up the screen* — title bar, close button and all. `.video-detail-steady` (a multi-season show only) gives the modal a height rather than a max-height, makes the body a flex column, and hands the leftover to the episode list as the one scrolling part. A constant-height box is centred in the same place every time, so both halves settle at once. - A scrolling season draws a scrollbar where a non-scrolling one draws none, which is a scrollbar's width of content and re-wrapped the file path above it, shifting everything below by a line. `scrollbar-gutter: stable`. - The season panel was clipped by the modal's own `overflow: hidden` whenever the seasons outran the room under the picker — at a 740px viewport it wanted 320px and had 288, and the rest sat where no scroll could reach it. It is `position: fixed` now, placed by `placeSeasonPanel()`, which takes the trigger's rect and the window height, picks whichever side has more room, and caps the panel to it. Scoped to multi-season shows throughout: a movie has no season to switch to and a fixed height would buy it nothing but empty space. test_video_detail_measured.py now builds each block inside a real `.video-overlay`, since the centring is half the defect, and asserts the modal top and height as well as the picker's offset — for a long and a short synopsis and for a six- and a twenty-four-episode season. test_season_panel_placement.py runs placeSeasonPanel() in node over a rect and a window height. Two guards are declarations rather than rectangles and say so in their docstrings: headless Chrome gives the probe zero-width overlay scrollbars, so the gutter cannot be measured there. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014UtzVrzM7e2tG9fSpkR9ML
* fix(hub): steady the show detail modal, and give a series its directorChristophe Besson2026-09-0215-31/+667
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Opening a different season of the same show moved everything under the synopsis, which is where the season control and the episode list are, so the thing just clicked was no longer under the pointer. - The synopsis is exactly three lines for a multi-season show, with a "read more" link floated into the third line box (-webkit-line-clamp only ever puts its ellipsis at the end of the last line and leaves no room after it). Clamped from above and pinned from below to the same number: a constant, not a range — a season summary runs two lines and the next one twelve, and a band still reads as a jump. Whether three lines is all of it depends on the modal's width, so it is measured in the browser and re-measured on a resize. - The cast is clamped to two lines. - SeasonMenu replaces SeasonTabs: the tab row scrolled sideways once a show had more seasons than fit, which is close to unusable on a phone. One trigger reading "Season 5 · 1997" and a menu of every season with its episode count, one row high whatever the season count. - media_meta_resp.director was filled from the credits crew's job == "Director", a movie shape. TMDB's aggregate tv_credits crew is routinely empty and never carries that job, so every show answered null and the modal dropped the line. It now comes from created_by on the show details. Cached show metadata keeps its null until TMDB_META_TTL_SECS expires or an operator re-matches. The facts line is joined rather than concatenated (a title with no rating used to open with " · ") and carries the show's own year next to the director; the selected season's air year moved onto the picker. test_video_detail_measured.py asserts rectangles through layout_probe.py, not declarations: the picker's offset inside its own modal body is the same pixel either way, the synopsis and cast heights, where the read-more link lands, and the open menu at 320 px. Each measured block sits in a whole-pixel-height container, or two identical layouts an eighth of a pixel apart round to tops one pixel apart. test_tmdb_show_director.py covers the credit. docs/mediacenter.md §10.4. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014UtzVrzM7e2tG9fSpkR9ML
* fix(hub): fall back to the group's first app when the landing tab is absentChristophe Besson2026-09-023-1/+284
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A group could open on a tab that rendered nothing: no panel, no tab shown active, and nothing on screen to explain it. The landing tab is chosen at mount from a preference -- default_tab for the group, else the account-wide one, else 'chat'. Which applications the group runs comes from the node, in the handshake ack, several awaits later. A preference is a preference, not a promise that the app exists here, so the two disagree in two ordinary cases: the group has Chat disabled while 'chat' is everyone's default, or the reader prefers an app this group does not run. `apps.map(a => tab === a.key && ...)` then matches nothing. The first app the group does offer answers both. Two more cases come free: a preference naming an app that no longer exists, and an operator disabling the app someone is currently looking at -- enabledApps changes live over apps_enabled, and being moved to a working tab beats staring at an empty panel. Settings is exempt: it is not an application, and the create-group wizard lands on it deliberately. `const apps` moves above the effect that reads it; a const further down would be in its temporal dead zone, which is the hook-ordering trap already recorded in CLAUDE.md. tests/harness/group_tab_probe.py renders the real GroupPage against a stub node answering a chosen enabled_apps and reads the tab bar back, over five cases. With the fix reverted the three fallback cases report no active tab at all and four of the six tests fail; the two that pass either way are the ones that must not change -- a group running everything, and a preference the group does honour (Videos stays selected, so the fallback has not become "always the first app"). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01W8oRqEHhnKUr1NfmTVdcyL
* fix(hub): let the reader scroll up in the chat againChristophe Besson2026-09-014-22/+416
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The chat could not be read back: any wheel gesture was undone in the frame it happened in, and the "jump to latest" button never appeared. None of the pins in ChatPanel are at fault -- every one of them is guarded by "only if the reader is at the bottom". The reader never got to stop being at the bottom. fit() set the panel's height, read documentElement.scrollHeight back and subtracted the overflow, so the document alternately did and did not overflow the window. The page scrollbar appeared and vanished with it and visualViewport fired resize at every pass -- the event fit() is bound to. It therefore re-entered itself for the life of the panel: measured at 240 firings in two seconds on a page nobody was touching, against 2 for a bare document. Each pass ran fitAndPin, which re-pinned the list to the bottom before the scroll event that would have recorded the gesture was delivered a frame later, so atBottomRef never went false. - fit() learns the space below the panel once and remembers it on the element instead of re-deriving it by writing and measuring back. At the steady state it writes nothing, so it produces no resize. A real window resize or an orientation change forgets the learnt value and measures again (the page under the panel may have reflowed); visualViewport deliberately does not, since a phone fires it constantly. - The scroll-to-bottom is now scoped to *arrival*, which is all it was ever for: opening the group, or coming back to the Chat tab, including the thumbnails and link-preview cards that keep growing the list for a second afterwards. It ends when the reader takes hold of the scroll, and the ResizeObserver disconnects there. - That release is recorded from the gesture (wheel/touchmove/pointerdown/ keydown), not from the scroll event, which arrives too late to protect anything. Unchanged: landing on the newest message, following new messages while already at the bottom, the "load older" anchor and the unread marker. tests/harness/chat_scroll_probe.py mounts the real ChatPanel in a browser and reads a conversation back; test_chat_scroll_up.py asserts against it. With the fix reverted, five of its six tests fail and the sixth -- landing on the newest message -- still passes, which is the property that must not have been traded away. A structural test cannot see any of this, which is why it is measured. test_layout_responsive.py pinned the listener's name and follows the rename. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01W8oRqEHhnKUr1NfmTVdcyL
* revert(hub): M6 — add_group_member must keep accepting node tokensChristophe Besson2026-09-012-12/+25
| | | | | | | | | | | | | | | | | | | | | | | | | M6 in the third review was a misread. `add_group_member` accepting a node-scoped token is deliberate (commit 0443cf8): the node calls POST /v1/groups/{id}/members/{username} after a CLI `member invite` so the group shows up in the invitee's SPA, authenticating with a node-scoped token. `group.admin_id == caller` is the real guard. An older test (`test_node_scope_blocks_add_member`) asserted the opposite and had been left red on main; the M6 "fix" (commit 6b38704) satisfied that test by switching the dependency to `require_user_scope` — which made `ops.create_invite`'s hub-membership call 403. That exception is swallowed with a log.warning, so an invited user silently never lands in group_members and the group is invisible to them. Reported from live testing (CLI `member invite grenet`, grenet saw nothing). Dependency back to `get_current_user`. The stale test now asserts the intended behaviour: a node token may add a member to its own operator's group (201) but not to a group it does not own (403). Third-review M6 marked WITHDRAWN. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011pG75yGK3NthNfyjH74omG
* fix(hub): send a CSP and protective headers on every responseChristophe Besson2026-09-013-3/+110
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The SPA shell and its assets went out with no Content-Security-Policy and no X-Content-Type-Options / Referrer-Policy / X-Frame-Options — so an injection that reached the SPA (rendered third-party OpenGraph data, a federated group name, chat content) had nothing stopping it from loading more code or exfiltrating to any host, and the page could be framed by any site. A middleware in `create_app` now adds all four to every response. `webapp.CSP` is deliberately the *same* policy the desktop client's protocol handler already enforces on these exact UI files, plus the two reCAPTCHA hosts the sign-up widget needs: `default-src 'none'`, `script-src 'self' 'wasm-unsafe-eval' <recaptcha>` (the hub's own origin is not a script source — T3), `style-src 'self' 'unsafe-inline'` (htm/preact inline `style=` only, nothing executes), `connect-src 'self' https: wss:`, `frame-ancestors 'none'`, `base-uri 'none'`, `form-action 'none'`. The shell's dead `<script>window.__MB_ASSET_V = ...</script>` is removed (nothing has ever read it) so `script-src` needs no inline allowance. Needs verification against the running SPA — a mis-tuned CSP shows as a blank page — but it matches a policy already proven with these files under Electron. Second-review L5 / third-review M5. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011pG75yGK3NthNfyjH74omG
* fix(hub): constrain what a federated peer hub can do (MHP)Christophe Besson2026-09-012-26/+277
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A registered peer was trusted with more than "advertise your own public groups": - `receive_directory` set `source_hub` from `body.hub_id`, so a peer could relay or spoof a third hub's groups into our directory. It is now bound to the token's verified `iss`. The push is also capped (500 groups/request, 2000/peer), rows are type- and length-checked, and a federated id that collides with a local group is refused so it cannot shadow one. - `receive_revocation` forwarded the peer's token to local nodes, which reject a token signed by another hub's key — a silent no-op, and there is no local node hosting a federated group anyway. It now verifies the inner token against the sending peer's key and, for `target == "group"`, prunes our copy of the peer's directory entry when `source_hub` matches. A peer cannot revoke our users or a group it did not advertise. - The state-changing endpoints (`POST /mhp/directory`, `/mhp/revoke`) now reject a replayed `jti` within the token's TTL. Audience binding is unavailable — the sending side that would set `aud` is unbuilt — and this covers the replay concern in its place; the idempotent `GET /mhp/directory` is not affected. Third security review, finding M4. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011pG75yGK3NthNfyjH74omG
* fix(node): bound and tighten the chat link-preview SSRF surfaceChristophe Besson2026-09-014-8/+173
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The link-preview fetch is an outbound request to an address a member chose. safe_url() already blocked non-public addresses and re-checked each redirect hop; this adds the parts that were missing: - Rate limit. `_do_link_preview_request` was reachable by any member with no ceiling, so a member — or a hub minting tokens for many accounts — could drive unbounded outbound HTTP from the operator's machine (amplification / DoS / on-demand IP disclosure to arbitrary hosts). Now bounded per connection (15) and node-wide (60) over a 60 s window; only a real fetch counts, a cache hit is free, and over the ceiling the reply is a plain `ok: false` (bare link), not cached. - Port allowlist. safe_url() passed `parts.port` straight through, so a member could aim the node at `http://<public-host>:<any-port>`. Restricted to {80, 443, 8080, 8443} — every real OpenGraph page, none of SSH / mail / DB / cache / search / admin ports. - DNS rebinding. The connection's actual peer address is now re-checked against the public-address rule (`_reject_if_rebound`), so a name that resolves clean and then to something internal does not get its body read. Best-effort (no `network_stream` extension, no check); a full literal-pin is noted as remaining hardening. - Decompression bomb. `_downscale` now refuses an image whose header dimensions exceed ~40 MP before convert()/thumbnail() decode it. Third security review, finding M3. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011pG75yGK3NthNfyjH74omG
* fix(node): bring the QUIC chat and stream handlers to WebRTC parityChristophe Besson2026-09-011-49/+95
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The unified handshake reached QUIC in Phase 11.5, but the chat and stream handlers did not get the authorization rules the WebRTC path gained at the same time: - _do_chat_message_sync took `sender_id` from the wire, so an authenticated peer could post as anyone (NS6 / M2a). It is now the authenticated session's id, always. - chat used a connection-global peer registry and read chat_store from the top-level context, so on a multi-group node a message from one group fanned out to peers of the others (M2b / H1). Both are now resolved per group via _peer_registry() / _group_ctx(), mirroring the WebRTC path. The QUIC peer set is kept separate from the WebRTC one in the same group context — the two session types have different _send signatures and no cross-transport fan-out is wired. - _do_stream_segment_sync ran `subprocess.run(timeout=30)` on the event loop with no concurrency cap, so one request stalled the whole node and any member could fork-bomb it with ffmpeg (M2c). Extraction now runs in a thread behind a small semaphore, spawned as a tracked task (cancelled on connection_lost). Also corrects the stale docstring claiming C6 is still open here — the GEK proof has been enforced on this transport since 11.5. No behaviour change for shipping clients: none speak QUIC, and the listener is off by default (previous commit). Third security review, finding M2. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011pG75yGK3NthNfyjH74omG
* feat(node): [node] quic_enabled flag, off by defaultChristophe Besson2026-09-014-2/+76
| | | | | | | | | | | | | | | | | | | | | | | The QUIC MNP listener was started unconditionally whenever aioquic was importable — but nothing speaks QUIC: the browser and desktop clients use WebRTC, QuicChunkClient has no production caller, and the hub-less `group://` sidecar (D9) is unbuilt. So on every node it was an open UDP port with no client and no working NAT traversal (`punch_nat()` is a direct-connection helper, not a traversal stack). daemon startup now gates QuicChunkServer on `self._config.node.quic_enabled` (default False; `MESHBAY_QUIC_ENABLED` overrides). The generated node.toml templates (config.py, the CLI, the desktop client) carry the line, commented for what it is. Removes the exposure the third review's M2 lives on until a QUIC client exists; the parity fix for the handlers themselves is the next commit. Third security review, finding M2 (mitigation). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011pG75yGK3NthNfyjH74omG
* fix(client): allow reCAPTCHA in the Electron CSPChristophe Besson2026-09-012-6/+54
| | | | | | | | | | | | | | | | | | | | | | | | | Needed for the paired meshbay-hub commit that makes the registration captcha unconditional (M1): the desktop client renders the same RegisterPage widget the browser does, which needs its script, its challenge iframe and its assets to load. script-src, the new frame-src, and img-src now allow exactly https://www.google.com and https://www.gstatic.com, and nothing else external — the hub's own origin is still absent from script-src, so T3 (nothing the hub returns is executed) is unaffected. This is a one-time source change: it ships identical in every build via `files: ["src/**"]` in electron-builder's config, with no build step, packaging step, or installer action for anyone to perform, and no setting for an end user to touch. test_desktop_shell.py updated to pin the exception precisely: the reCAPTCHA hosts are the *only* external origins allowed anywhere in the policy, and a bare `https:` scheme is still refused in script-src. Third security review, finding M1 (Option A, desktop half). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011pG75yGK3NthNfyjH74omG
* fix(hub): require user scope to add group membersChristophe Besson2026-09-011-1/+6
| | | | | | | | | | | | | | | | Every mutating group endpoint depends on require_user_scope except POST /v1/groups/{group_id}/members/{username}, which depended on get_current_user — so a node-scoped daemon token (or a stolen one) whose subject owns the group could add any existing user to it, contradicting NS7 ("operator manages groups from the browser only"). test_node_auth.py::test_node_scope_blocks_add_member already existed and was red on main; it passes now. Third security review, finding M6. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011pG75yGK3NthNfyjH74omG
* fix(hub): enforce registration captcha for every clientChristophe Besson2026-09-014-4/+78
| | | | | | | | | | | | | | | | | | | | | | The server only checked the captcha when auth_key was absent — but every real client (browser included, via the password split) sends auth_key, so the check was off for everyone, and a bot skipped it by including the field. The Register form still made humans solve a widget whose token was never transmitted. Gate is now unconditional on captcha.enabled. The web client (registerUser in keyderive.js) forwards captcha.token; RegisterPage resets the (single-use) token on a failed attempt. The desktop client shares this UI source and is Chromium, so it renders the same widget (see the paired meshbay-client commit for the CSP change that allows it). Tests: test_register_captcha.py. Third security review, finding M1 (Option A). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011pG75yGK3NthNfyjH74omG
* fix(hub): require auth and distinct reporters for content reportsChristophe Besson2026-09-012-71/+147
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | POST /v1/reports had no authentication and no rate limit, and counted every raw report row toward AUTO_BLOCK_THRESHOLD regardless of who sent it or from where — two anonymous requests naming any blake3 hash added it to the hub-wide content blocklist. A network-wide censorship and DoS primitive for anyone who learns a public file's hash. - require a signed-in account (get_current_user) - rate-limited (10/hour) - threshold now counts DISTINCT reporting accounts (reporter_id), one vote per account per hash; raised 2 -> 3 - refused outright (403) when the hub has public groups switched off: a private-only hub brokers no public content and nothing syncs the blocklist, so the endpoint would be pure abuse surface - admin blocklist management (/v1/admin/blocklist*) is untouched, so a manual block still works regardless of the public-groups setting Noted while fixing: no node currently consumes ContentBlocklist (swarm_register checks the separate CSAM list), so the network-wide block effect was latent — the abuse surface (DB fill, poisoned moderation signal) was live today. Tests rewritten in test_moderation.py. Third security review, finding H2. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011pG75yGK3NthNfyjH74omG
* fix(hub): moderator can no longer grant admin or hard-revoke accountsChristophe Besson2026-09-013-6/+71
| | | | | | | | | | | | | | | | | | | | | admin_patch_user was gated by require_moderator but wrote `role` and `status` with no further check. A moderator could promote any account (an accomplice) to admin, demote an existing admin, or set status="revoked" — a straight path from the moderation role to full instance control. Split authorization by field: status between active/suspended stays at require_moderator (reversible content moderation); role changes, status="revoked", and touching an admin's account at all now require user_is_admin(current_user) (new helper in deps.py, alongside the existing require_admin/require_moderator). Regression test: test_moderator_cannot_change_roles_or_revoke. Third security review, finding H1. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011pG75yGK3NthNfyjH74omG
* chore: release 0.10.00.10Christophe Besson2026-09-016-8/+8
| | | | | | | | | | | | All three packages (common, hub, node) bump 0.9.0 -> 0.10.0 together. Highlights since v0.9.0: email verification for registration, email change and invitations; passphrase change and account recovery; reCAPTCHA v2 on Register and Password Reset; node JSON-only control API with the Node page absorbing the admin dashboard; WebRTC STUN fallback fix; assorted hub UI fixes. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QNPfgH6VWcRzJDZGuzy1jJ
generated by cgit v1.2.3 (git 2.51.0) at 2026-09-25 22:32:34 +0000