Adom Bridge

⋯ 1 unchanged line ⋯

@@ -1,6 +1,6 @@ {
   "slug": "adom-bridge",
-  "version": "2.1.173",
+  "version": "2.1.174",
   "type": "app",
   "brief": "Adom Bridge unleashes your AI onto your full PC: full power, full safety. The AI breaks out of the container it runs in and onto your real machine, managing and running your entire laptop as you: launch apps, move files, drive any window, control KiCad, Fusion 360 or your real signed-in browser. Works with any AI, cloud or local (Claude Desktop, Claude Code, Codex), no Hydrogen required. Bridge and its bridges are an operating system for AI, with managed Node and Python runtimes, and a human-only permission system keeps you in charge of every side-effecting command.",
   "description": "Install this package in a cloud or Hydrogen Desktop container, not on the PC. It delivers two things: the Linux adom-bridge-cli (linked onto PATH) and the Claude skill set that teaches an AI every desktop verb (shell, files, screenshots, windows, notifications, KiCad, Fusion 360, browser automation). The CLI drives the Adom Bridge app running on your Windows PC over the relay; the Windows app itself is the separate installer in the Download box, not part of this package. Run adom-wiki pkg update to keep the CLI and skills current.",

@@ -1,6 +1,6 @@ {   "slug": "adom-bridge",-  "version": "2.1.173",+  "version": "2.1.174",   "type": "app",   "description": "Install this package in a cloud or Hydrogen Desktop container, not on the PC. It delivers two things: the Linux adom-bridge-cli (linked onto PATH) and the Claude skill set that teaches an AI every desktop verb (shell, files, screenshots, windows, notifications, KiCad, Fusion 360, browser automation). The CLI drives the Adom Bridge app running on your Windows PC over the relay; the Windows app itself is the separate installer in the Download box, not part of this package. Run adom-wiki pkg update to keep the CLI and skills current.",   "keywords": [

@@ -39,7 +39,8 @@ Open it by verb with `desktop_ui_panel {"panel":"mesh","action":"show"}` (then ` - Reaches peers on the **same LAN** directly (mDNS + the directory's IP endpoints). **P1 (2.1.49):** every node also registers with the Adom-hosted relay (`mesh_relay_url`; since 2.1.54 the default is the relay on its own Adom service-container, `https://meshrelay-o6vza2ooz7ou.adom.cloud/`, a clean `port-add` hostname; the my-container proxy relay stays as a fallback; `scripts/iroh-relay/README.md` in the repo), so two boxes behind different NATs reach each other THROUGH the relay: the QUIC stream stays end-to-end encrypted and the relay never sees a verb, a file or a decision. `desktop_mesh_status` reports `relay`, `relayConnected` and `relayStatus`; a relayed answer still carries `route.via:"mesh"`. Hole punching (direct cross-NAT paths) is not on yet: it needs QUIC address discovery on a public UDP port, which neither the container nor a roaming laptop has; until a UDP-capable host exists, cross-network traffic is relayed. `settings_set {mesh_relay_url:""}` returns to same-LAN only; a change applies on the next mesh start.
 - Trust: an inbound connection is accepted only when its node id is in the account directory (same account). A mesh caller is a relay-class origin, so every human gate (shell approval, web consent, credential import, input) applies unchanged, and `blocked_peers` sees the peer's name.
 - Containers (WSL2/Lima) and other accounts are later phases (see docs/adom-mesh.md in the ab repo).
-- **Three modes; relay-only by default (2.1.61).** `settings_set {"settings":{"mesh_mode":"relay"|"direct"|"off"}}` (Settings > Adom Mesh; ah can render it via settings_get/set). **relay** (the default) binds nothing on the network: iroh's IP transports sit on loopback only, no mDNS, and every peer connection is carried through the Adom iroh relay as QUIC inside a WebSocket, still end-to-end encrypted on the two machines' ed25519 keys (the relay forwards ciphertext it cannot read) and still same-account node auth, so Windows never shows a firewall dialog and `--target <name>` still answers `route.via:"mesh"`. **direct** adds the 2.1.41 LAN socket + mDNS for direct QUIC on the same network (faster for big files); it is the ONE moment Windows asks, once, and ab explains it on screen (#158). **off** = no iroh; your other machines are reached through the cloud command relay only (encrypted to the relay, which routes your commands). `desktop_mesh_status` reports `mode`; the Mesh view names the mode and shows a padlock on every link. `mesh_enabled` remains as the derived alias (`true` = direct, `false` = off) for older callers.
+- **Three modes; relay-only by default (2.1.61).** `settings_set {"settings":{"mesh_mode":"relay"|"direct"|"off"}}` (Settings > Adom Mesh; ah can render it via settings_get/set). **relay** (the default) binds nothing on the network: iroh's IP transports sit on loopback only, no mDNS, and every peer connection is carried through the Adom iroh relay as QUIC inside a WebSocket, still end-to-end encrypted on the two machines' ed25519 keys (the relay forwards ciphertext it cannot read) and still same-account node auth, so Windows never shows a firewall dialog and `--target <name>` still answers `route.via:"mesh"`. **direct** adds the 2.1.41 LAN socket + mDNS for direct QUIC on the same network (faster for big files); it is the ONE moment Windows asks, once, and ab explains it on screen (#158). **off** = no iroh; your other machines are reached through the cloud command relay only (encrypted to the relay, which routes your commands). `desktop_mesh_status` reports `mode`; the Mesh view names the mode and shows a padlock on every link. `mesh_enabled` remains as the derived alias for older callers (`false` = off; `true` keeps a mesh that is already on in its mode, else turns it on as relay; before 2.1.174 it meant direct).
+- **New installs start OFF; upgrades keep their mode (2.1.174, wiki #235/#236).** A fresh install (no config.json before its first launch) writes `mesh_mode: "off"` on purpose, and about a minute after launch shows ONE notice saying how to turn the mesh on (Settings > Adom Mesh, Relay recommended). An existing config keeps exactly the mode it had: when `mesh_mode` is present it decides. (2.1.171-2.1.173 read a `relay` + `mesh_enabled:false` pair as "off", which switched new installs and default-built configs off; that rule is gone, and a box left off with nobody having chosen it gets the same one-time notice.) Every explicit choice is recorded in `~/.adom/mesh/mode-choice.json` (`{mode, by, at}`), so "a person switched it off" is distinguishable from "nobody chose". To switch the mesh off by hand-editing config.json, set `mesh_mode: "off"`. Hydrogen renders the setting from ab's schema as an Off / Relay / Direct choice in its own "Adom Mesh" section.
 - **The firewall dialog is explained on screen and mirrored to your other boxes (2.1.56).** When the mesh is turned on (by a person here, or by a verb from another machine), ab draws an on-screen CAPTION next to the Windows firewall dialog explaining what it is asking, that only machines signed into your own account can connect (TLS 1.3 + a per-machine ed25519 key), that every other listener stays on 127.0.0.1, and to click Allow and tick BOTH profiles (Cancel just blocks the mesh). The caption clears when the dialog is gone and always self-clears within 60s. If a verb from ANOTHER machine turned it on (nobody at that keyboard), ab also mirrors a `firewall-prompt` notice to every same-account box over the hc relay AND the mesh: an informational card in the permission stack saying which box is showing the prompt and that you must click Allow THERE (it cannot be approved remotely). This is the general rule for any Windows prompt ab can cause: explain it on the screen it appears on, and tell your other boxes.
 
 ## Recipes