Adom Bridge

Direction from John (2026-10-09): a brand-new install starting with the mesh off is fine. An ordinary version upgrade must never switch the mesh off. Whatever mode a machine was in before the upgrade, it stays in after.

What that means for the fix:

1. Make fresh installs off on purpose, and say so. Today a fresh install ends up off only by accident (the default pair relay + mesh_enabled:false trips the 2.1.171 rule). If off is the intended fresh-install state, set it on purpose (default_mesh_mode() = "off", with a consistent mesh_enabled:false). Then fix the Settings help text, which still says "On by default, through the Adom relay", and the skill text that says relay is the default. The new machine then needs a clear way for the person to turn the mesh on and ask to join, since nothing will prompt them otherwise.
2. Upgrades keep the mode. An existing config.json must come through any upgrade with the same effective mode it had before. In particular, the 2.1.171 "explicit mesh_enabled:false beside a non-off mode means off" rule must not flip a machine that was running the mesh before. Please check that against configs written by every release since 2.1.61, not only by the current save path, and add a test per historical shape (missing mesh_mode, relay + true, relay + false from a default-built config, direct + true).
3. Tell apart "fresh install" and "existing config". The only reliable signal is whether config.json existed before this launch, so decide from that, not from the field values.
4. Recover machines this already hit. Any box that upgraded in the last day and came up off without a person choosing it should go back to the mode it had. If that can't be known for certain, put up one notice ("Adom Mesh was switched off by an update. Turn it back on?") rather than changing it silently.

Side note, from the same test: on AdomLapper, Bridge passed one mirrored shell approval from winvm to ah three times within 200 ms (PERMISSION-MIRROR: delivered type=shell-approval id=remote:winvm, at 07:54:44.319, .517 and .519 local). John saw it once, so there was no visible duplicate, but it looks like the relay copy and the mesh copy aren't being de-duplicated before they're handed to ah.

Fixed in 2.1.174 (insiders now), following your direction.

Upgrades keep their mode. When mesh_mode is in config.json, it decides. The 2.1.171 rule ("mesh_enabled:false beside a non-off mode means off") is gone. That rule was wrong because ab's own defaults wrote exactly that pair (relay + false), so every default-built config read as "off". There is now a unit test for each config shape a past release could have left on disk:

• no mesh_mode, with mesh_enabled true / false / missing (2.1.41–2.1.60, and first-launch files)
• relay + true, direct + true, off + false (2.1.61+ saves)
• relay + false from a default-built config → stays relay
• an unknown mode
• AppConfig::default() serialized → relay, with a consistent mesh_enabled: true

Fresh installs start off on purpose. The only signal used is whether config.json existed before this launch. When it didn't, ab writes mesh_mode: "off" + mesh_enabled: false explicitly and logs FRESH-INSTALL: in startup.log.

Turning it on. About a minute after launch, a machine whose mesh is off with no recorded choice shows one notice (once per machine; it goes to Hydrogen when ab is embedded). It says how to turn the mesh on: Settings > Adom Mesh, Relay recommended. On a box that upgraded into "off", the wording says an earlier update may have switched it off. Hydrogen's Settings gets the Off / Relay / Direct choice from #236. Every explicit choice (Settings window, or settings_set from Hydrogen or an AI) is recorded in ~/.adom/mesh/mode-choice.json, so "a person switched it off" can now be told apart from "nobody chose".

Machines this already hit. I didn't flip any box silently, except that I restored my own test box arav-rog, which was off with no recorded choice. On 2.1.174 it showed the notice (MESH-MODE: off with no recorded choice; showed the one-time notice), then settings_set {mesh_mode:"relay"} brought it back: relay, connected, 3 peers, choice recorded. Any other affected box gets the same notice. winvm needs one settings_set {mesh_mode:"relay"}, or a click in Hydrogen's Settings once it's on 2.1.174.

Checked after the upgrade: ConfRoomROG came through 2.1.173 → 2.1.174 still in direct (running, 2 peers).

Side note (3 deliveries to ah in 200 ms). That log line truncated the id to 12 characters, so every prompt from winvm printed as remote:winvm. It may not have been one prompt three times. Either way:

• A mirrored prompt is now forwarded to Hydrogen only on its first arrival. The relay copy and the mesh copy land milliseconds apart; the second one only refreshes ab's own record.
• The log line now prints the full composite id, so this can be read exactly next time.