meshbay.git/packages/meshbay-client, branch 0.13

feat(packaging): one radio page for Windows autostart, firewall every mode

2026-09-10T23:33:05Z

Operator feedback on the 0.13.0 installer: - The all-users / current-user page (electron-builder's PAGE_INSTALL_MODE) only ever showed "anyone who uses this computer" disabled -- MeshBay is per-user only (account-bound keystore/DPAPI, MESHBAY_DESIGN.md 11.2) and build.nsis forbids elevation. customInstallMode forces $isForceCurrentInstall so the page is skipped. - The two nested Yes/No MessageBoxes are one nsDialogs radio page (customPageAfterChangeDir): only-while-open / at-sign-in / background service, default background service. customInit seeds MB_AutoMode "2" for silent installs where the page never runs. "At sign-in" now writes the Startup .vbs from the installer (meshbay-node autostart install, unelevated); the old per-user branch set up nothing. - The firewall rules go in for every mode, not behind a second opt-in -- a node that accepts no connections is the failure mode MESHBAY_DESIGN.md 7.5 names. Folded into the service elevation for mode 2; their own single elevation for 0/1. Unelevated short-circuit kept but narrower: firewall.ps1 check AND service.ps1 status must both pass to skip mode 2's UAC. Var MB_AutoMode lives inside customPageAfterChangeDir, not at file scope: the uninstaller compile pass inserts none of the macros that read it and makensis -WX turns "unused Var" (6001) into a hard error. Not yet exercised on a real machine -- the NSIS UI cannot be driven from the build env. test_packaging_win.py pins the script shape. Co-Authored-By: Claude Sonnet 5

feat(hub): pin the app controls while a library scrolls

2026-09-10T08:29:12Z

Files, Videos, Music and Photos are read by scrolling, and everything that steers that reading left with the first screenful. Three bands now pin under the navigation bar, in a group and on the Search page alike: the tab bar (the search field, on Search), the application's own toolbar, and the file table's column heads. The group's name and description still scroll — they say nothing a reader needs while walking a directory, and the height they would cost is height the list does not get. A band's offset is the heights of the bands above it, and those are not constants: the toolbar wraps to three rows on a phone, grows a field while a folder is being named, and loses its filter on Search. So each band measures itself and publishes `--chrome-h` / `--toolbar-h` (static/sticky.js) and the stylesheet does the arithmetic in calc(), rather than a number written down twice — the fault CLAUDE.md already records against this layout twice over. A band publishes height *plus its own bottom margin*, and paints that margin as a ring of page colour, so the pinned layout is pixel-identical to the flow layout and nothing shifts at the moment a band pins. Three overflow faults came out of it, all of the same class and all of them what "the header does not stay" actually meant on Android — a document wider than the screen leaves everything pinned attached to a viewport the reader can no longer see, the navigation bar included: - a directory's name cell was a bare , so an unbreakable folder name (`Rage_Against_The_Machine_Discography_1992-2000_FLAC`) set the column's minimum: a 527px table in a 390px window - Search's group column did the same at 442px with an underscored group name. It also goes entirely below 768px, where there is no room for it and the breadcrumb already names the group - the shared-directories table has four columns of controls with a combined minimum near 440px, none of it compressible. On a phone the row stops being a row: the name and its eject/remove pair on one line, the two switches — each carrying the column head's own string as a label — on the next - and, found by measuring at 360px, the tab bar itself was 19px too wide `.file-table` moves to separated borders: a collapsed border belongs to the table rather than to the cell, so the column heads lost their rule the moment they pinned. Measured, not read. tests/harness/sticky_header_probe.py drives the shipped GroupPage and SearchPage against a stub node, walks to each application, scrolls to the end and reports every rectangle — 11 views x 4 widths x 2 engines. Its fixture says what real data says: the first version used `note-007.txt` and `un groupe`, which fit any screen, and found none of the above. A fixture narrower than real data tests the fixture. Also: `test_desktop_shell` no longer looks for the CSP after the first `-->`, which made it fail on correct markup as soon as a comment was added above it, and `search-page.js` joins test_hook_ordering's file list. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01Tx16FhyD2BUdpooGb5jcyN

fix: the PDF preview needs object-src and frame-src, in both policies

2026-09-09T13:48:53Z

A PDF preview showed the "this browser will not display the PDF inline" fallback everywhere — in the desktop client since its first launch, and in the browser since the hub started sending a CSP on 2026-09-01. It read as a missing native feature because before that commit the hub sent no policy at all, so Chrome had once worked and the application never had. Two directives govern one feature. `files-app.js` decrypts the file in the page and hands it to `` from a Blob; Chromium loads that as plugin data (`object-src`, absent and therefore falling back to `default-src 'none'`) and then renders it in an internal frame (`frame-src`). Opening either alone changes nothing visible — the second refusal produces the same fallback. `'self'` covers neither: a same-origin `blob:` URL is not matched by it in either directive, measured in Chrome 152 against the deployed page and in Electron 44 against the client's own policy. `plugins` stays at its default `false`: the built-in viewer is not behind that flag on Electron 44, verified by rendering one. Widening `object-src` from `'none'` to `blob:` admits only what page script minted itself, at a type this code sets — PDFium parsing bytes that came from a node, which is what any browser does with the same file once downloaded. Tests: each policy is pinned to carry `blob:` in both directives (each fails if either token is removed), and the two policies are now held identical directive by directive apart from the two deliberate differences — the comment claiming they were the same had already drifted and nothing checked it. The CSP source parser in test_desktop_shell.py read `//` comment lines as directives, which is the "parse directives, not text" mistake this file already records; it skips them now. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01XauykfBvRrpy6RYbF6F7Wu

feat: MNP 3.0 — a transfer needs a lease

2026-09-09T12:00:22Z

Stage 4 of ~/next/improve-downloads.md, the flag day. Leases become compulsory and a 2.x peer is refused at the handshake. **The bound on leaseless reads (§3.4.1) did not exist, and it is what makes the rest mean anything.** Browsing a group is never subject to a transfer slot — that is an operator decision and a requirement: a member must be able to browse a group at capacity exactly as they browse an idle one. But "not leased" cannot mean "unbounded", or a client that simply omits `tr` transfers outside every cap and the caps are decoration. A session may now read two distinct files at once without a lease: one because a viewer looks at one file, two so that prefetching the next photo stays possible. A count of files and not a byte budget, because a RAW photo is 60-80 MB and is browsing while a 40 MB archive is a download, and no size threshold separates them. Thumbnails, posters and cover art never reach this check at all — they resolve out of the node's own cache. It is a fairness control among cooperating clients, in the company of `max_concurrent_streams`, and is not a defence against a member determined to saturate a node's disk. That member is a member, and the answer to them is `member revoke`. **MNP_VERSION and MNP_MIN_SUPPORTED both move to 3.0**, on both sides. The messages are additive; the requirement is not. An opt-in switch would leave a leaseless branch reachable on every node, which is finding C6's lesson — a transport that accepted a bare JWT — one feature later. **The desktop client now checks before it connects.** The SPA is served by the hub and picks up a new client on reload; the application ships its own interface, so an un-updated one would sign in, list groups, and fail every connection with `version_too_old` — a refusal in a protocol vocabulary with nothing anyone can act on. It asks `/v1/hub/version` for `client.minimum` and says so plainly instead. An unreachable hub is deliberately *not* "too old": a captive portal or a closed laptop must not make starting the application impossible. **Every package is aligned on 0.13.0.** `meshbay-client/package.json` had drifted to 1.0.0 while the Python packages were on 0.12.0 — invisible until something compared those numbers, and then load-bearing: an installed client announcing 1.0.0 sorts above a 0.13.0 minimum and walks through the gate meant to stop it. That is stated in the code rather than left to be rediscovered; it is acceptable exactly once, because the operator is updating every client, node and hub by hand for this flag day. A new test fails if two packages ever disagree again, and another fails if the hub would refuse the client the tree builds. Node suite 1209 passed, hub suite 861 passed. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01HCGdheDLxGReuKHga3BtST

fix(client): write a download to .part and rename it when it completes

2026-09-08T11:21:02Z

`save:abort` deleted a cancelled download, but nothing covered the application being quit, killed or crashing mid-transfer: the write stream was abandoned and a truncated file kept the final name — the exact thing save:abort's own comment calls worse than no file at all, because it looks complete to whoever opens it next. Downloads go to `.part` and are renamed after the stream has flushed, which is the convention the node already uses for uploads (`_do_file_upload`). A crash now leaves a self-evidently unfinished file. `before-quit` also clears any `.part` still open, synchronously — it does not wait for promises — so a deliberate quit leaves nothing at all. Verified by hand: .part during the transfer, survives SIGKILL, renamed on completion, and gone after a cancel or a clean quit. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01HCGdheDLxGReuKHga3BtST

feat(client): create the system tray at launch, not on first minimise

2026-09-08T01:14:34Z

ensureTray() was reachable only from the window:minimize-to-tray handler, so the indicator did not exist until you had already hidden the window into it. That is backwards on both desktops — most of what a tray is for is finding an application that is not in front of you — and on Windows it read as the app having no tray presence at all. Created during app.whenReady(), after registerBridge() and before createWindow(). The order matters: buildTrayMenu reads the nodeService that registerBridge assigns, so the other way round puts the Start/Stop entry on the menu one five-second poll late. The menu's labels were the one thing that came *from* the minimise call, since the main process has no i18n. A new tray:labels IPC (platform.setTrayLabels) carries them instead, sent from the renderer's boot once initLocale() has a catalogue; a language change reloads the page, so the same call covers it. The window between launch and that first message shows TRAY_FALLBACK, in English. §5.10's two platform gates become one — trayOS() in main.js, which every tray path calls. test_desktop_shell.py's existing test is rewritten against it and two are added: the launch ordering, and that no tray path tests process.platform inline instead of calling the gate. Windows still files a new tray icon under hidden icons until the person drags it onto the taskbar. No API promotes it; documented in WINDOWS-PORT.md §5.11 rather than worked around. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01V8EDjk6pkYZrCbo63m2x87

fix(client): break the Wayland ready-to-show deadlock

2026-09-07T13:01:12Z

Some Wayland compositors never schedule a first paint for an unmapped surface, but the window stays unmapped until show() runs, which was gated entirely on that paint's ready-to-show event — a cycle with no way out on its own. Observed under GNOME/Mutter on a VM whose virtio-gpu device fails command-buffer creation. Add a bounded fallback show(), guarded on isVisible() so it's a no-op once the event has already fired normally and doesn't steal focus back from whatever the person switched to. Co-Authored-By: Claude Sonnet 5 Claude-Session: https://claude.ai/code/session_01CHKaCz2gq3ya8t13CvQ7Hp

chore(client): bump electron 44.1.1 → 44.2.0 in package.json

2026-09-06T01:43:51Z

Co-Authored-By: Claude Opus 4.6

chore(client): update lock file (electron 44.2.0, version 1.0.0)

2026-09-05T23:54:31Z

Co-Authored-By: Claude Opus 4.6

fix(win): finish the desktop setup flow — node-key link + service task

2026-09-05T17:48:10Z

Two independent breaks in the Windows first-run path: - node:start's win32 branch never linked the node's Ed25519 key to the hub account, so the daemon sat at waiting_for_account and the Create Group wizard span on "Detecting local node…" for ever — the only way through was pasting the key by hand on the Profile page. The Linux branch has always done this inline; factor it into linkNodeKeyAndAwaitRunning() and call it from win32 too. PUT /v1/users/me/node_key overwrites, so this also recovers an account still carrying a previous machine's node key. - service.ps1's install branch did `$action = New-ScheduledTaskAction`, shadowing its own [ValidateSet(...)][string]$Action parameter (PowerShell variable names are case-insensitive). The CimInstance was coerced to the string "MSFT_TaskExecAction", Register-ScheduledTask -Action rejected it, and "background service" mode never created the task — reproduced live. Rename the locals to $taskAction / $bootTrigger / $taskPrincipal. Co-Authored-By: Claude Sonnet 5