From e833fe1bfc8eb6f66cc5dc53997cc4158bab583f Mon Sep 17 00:00:00 2001 From: Christophe Besson Date: Wed, 7 Oct 2026 21:25:47 +0200 Subject: fix: set the Windows node up at sign-in, and stop it for real Found by the first Windows beta tester, then reproduced on a clean install. After a service-mode install nothing set the node up for the account that signed in: the boot task started a node that quit ("hub.username not set"), and the sidebar showed Node / Create group only once the hub held a node key. The only way to the wizard that provisions was the home page's welcome card, which an account already in a group never sees. The way out was `meshbay-node init` and the key pasted on the profile page -- which is also what PACKAGING-GUIDE.md told people to do. - main.js `node:ensure`, called by app.js at sign-in: provisions, starts and links the node this build ships (Windows, bundled node only). A node set up for another account, or an account linked to another node, is left alone. node:start waits for it, so the two never race. - The sidebar shows the Node section when a node exists on this machine. - The Node page's status is the node's: its control API and the process list, not the service task's state (a node started from a terminal ran while the page said Stopped). Stop says Stopped only once no meshbay-node.exe is left, and stays offered for a process that answers nothing. - CLI stop kills the pid that answered when a graceful stop does not finish, and fails with the reason when a node process is still there. - The daemon ends its process 3s after _shutdown(): Python's exit waited for a busy indexer thread, with the control API already closed. Armed by main() only, never by a daemon run inside a test. - node.toml is read as utf-8-sig (PowerShell 5.1 writes a BOM), and a config that cannot be read is logged instead of dying silently in service mode. - "Pair this browser" queues the code for the next group of this node to open instead of saying "Paired successfully"; no banner before a group. - test_e2e_windows_app.py (opt-in, MESHBAY_WIN_E2E=1) drives the installed app against a throwaway hub: fresh account to linked node, Stop, Start, Restart, checked against the real processes. Co-Authored-By: Claude Opus 5.5 --- docs/PACKAGING-GUIDE.md | 64 ++++++++++++++++++++++++++++--------------------- 1 file changed, 37 insertions(+), 27 deletions(-) (limited to 'docs/PACKAGING-GUIDE.md') diff --git a/docs/PACKAGING-GUIDE.md b/docs/PACKAGING-GUIDE.md index 9649826..fdc0a57 100644 --- a/docs/PACKAGING-GUIDE.md +++ b/docs/PACKAGING-GUIDE.md @@ -71,20 +71,21 @@ Run the installer. It is **per-user** and lands in node daemon ships beside the app at `resources\node-runtime\meshbay-node.exe`; the client finds it automatically. -It asks two things, both skippable: - -- **"Run MeshBay Node as a background service?"** — Yes starts the node **at - boot, before you even sign in**, and needs one administrator confirmation - (which also sets up the firewall rules, in the same step — see below). No - keeps the normal per-user mode: the node starts when you sign in, with no - admin needed, and you can turn autostart on later from the Node page. -- **(per-user mode only) "Allow MeshBay through Windows Firewall now?"** — one - administrator confirmation adds the inbound rules the client and the node - need for WebRTC and casting. Declining is fine — Windows shows its own - "Allow access" dialog instead, the first time each is actually used. - -Running setup again (an upgrade, a repair install) asks neither question if -the firewall rules are already there. +It asks one thing — **when the node runs**: + +- **As a background service** (the default) — the node starts **at boot, + before you even sign in**. +- **Automatically when I sign in to Windows** — a launcher in your Startup + folder, no service. +- **Only while MeshBay is open** — the app starts the node and stops it when + you quit. + +Every choice also adds the Windows Firewall rules the app and the node need +(WebRTC, casting), so setup asks for **one administrator confirmation**: for the +service and the rules together, or for the rules alone. Running setup again (an +upgrade, a repair) keeps the choice it finds and asks nothing when the rules and +the service are already in place. The choice can be changed later on the +**Node** page (**Start automatically**). **ffmpeg** — required for video streaming, **bundled in the installer by default** (verified, checksummed, GPLv3-licensed; `LICENSE-ffmpeg.txt` ships @@ -92,29 +93,38 @@ alongside it). Nothing to install separately. ### First run -Open MeshBay and sign in. Use the **Node** page (or a terminal) to provision: +Open MeshBay, choose the hub and sign in. **That is all**: the app sets the node +up for the account you signed in with, starts it the way you chose at install, +and links it to your account. **Node** and **Create group** appear in the +sidebar; nothing has to be typed in a terminal and no key has to be copied. -``` -meshbay-node init -meshbay-node autostart install # per-user mode: run at every sign-in (no admin) -meshbay-node service install # service mode: run at boot (needs an elevated prompt) -``` +Two cases where the app does not do it on its own, because it would undo +something: + +- the node was already set up for **another account or another hub** — the + **Start** button on the Node page asks before switching it; +- your account is already linked to a node on **another machine** — linking + this one would disconnect that one. The Node page shows this node's key; + **Profile → Link Node** moves the link here if that is what you want. + +The Node page's **Start / Stop / Restart** work in every mode, and its status +is the node's own: **Running** when it answers, **Stopped** only once no +`meshbay-node.exe` is left. If a node will not stop, the page says so and why. -The Node page's Start/Stop/Restart buttons work the same either way — they -drive the Scheduled Task when service mode is active, or the daemon process -directly otherwise. +The node logs to `%LOCALAPPDATA%\meshbay\state\node.log` — in service mode +that file is the only place it can tell you why it would not start. Runtime data — `node.toml`, `keystore.enc`, `unlock.key`, `data\` — lives in -`%LOCALAPPDATA%\meshbay\` and **survives uninstall/reinstall**, in either mode +`%LOCALAPPDATA%\meshbay\` and **survives uninstall/reinstall**, in every mode (service mode runs as your own account too — never LocalSystem — so nothing about where your data lives changes). ### Uninstall *Apps & features → MeshBay → Uninstall*, or the Start-menu *Uninstall MeshBay* -entry. It stops a running daemon and removes the sign-in launcher; it offers -(opt-in, one admin confirmation) to also remove the firewall rules and the -boot-time service task, if you set one up. None of this touches +entry. It stops a running node, removes the sign-in launcher, and removes the +firewall rules and the boot-time service task with one administrator +confirmation (none if neither is there). None of this touches `%LOCALAPPDATA%\meshbay\` (the keystore). ### Build from source -- cgit v1.2.3