[bfieser]

Closes #219. Stacked on #218: this PR's base is sync/216-lan-diagnosis. Please review and merge #218 first; this PR then retargets to main.

Why

#218 lets a machine say why it can't find a linked machine on the home network, but only from what it can see itself. One machine alone can't tell that the other one is on another Wi-Fi, has a VPN on, isn't using Home network sync, is asleep, or can't hear it. The other machine can.

What the user sees

New per-machine reasons on the Sync & backup line and in its details:

• "Home network sync isn't on there"
• "can't open its network port" (it's picked there, but the port won't open)
• "it last checked in 3 h ago. Make sure it's awake, with Patch Pilot open and online." (accent tone)
• "a VPN is on there"; "its messages go to a virtual network on it (vEthernet (WSL))"
• "it's on a different network", including the same 192.168.1.x range behind another router
• "it hears this machine, but nothing it sends gets here. Allow Patch Pilot through the firewall on this machine."
• "both are on the same network, but neither hears the other. A firewall… or the router keeps devices apart (client isolation)"
• "Desktop can't hear this machine, so this machine's files aren't reaching it" (shown on the machine that is heard)

A wrong reason is worse than none. A reason is named only when both machines' data agree and the other machine's report is current. "Current" means fresh, reached the relay after this machine last heard that machine, and this machine is online and hasn't just woken from sleep. Advice about this machine's own network (e.g. "set it to Private") is left out while the missing machine may be on another network.

How

• net/<machine id>: a small sealed relay object (crates/local/src/net_report.rs) holding:

  • whether Home network is on and listening, and since when
  • subnets (network address and prefix only)
  • whether broadcasts or internet traffic go through a VPN, or into a virtual adapter
  • whether the last broadcast failed
  • which linked machines it hears now
  • its public address as the relay saw it

  It's separate from the machine/ bundle so network changes don't re-send the scan and every Primary Rig version.

• When it's sent (app/src-tauri/src/lan.rs): on change (at most every 30 s); every 5 min while a machine that might still turn up is missing; every minute while a machine here can't hear this one. Nothing is sent while everything works. A report counts as sent only once the relay took it, so failures retry.

• Relay (app/src-tauri/src/sync.rs): reads each linked machine's report once per session (one row read each, decision Release 0.4.2, with "Bring over all Reaper scripts" #113), then on live changed events.

• Connection health (sync.rs): the live connection now counts as offline when a ping goes unanswered. Waking from sleep restarts the session, so reports from before sleep are never judged as current.

• Rules (crates/local/src/lan_diagnosis.rs): why() gives the per-machine reason, deaf lists machines that can't hear this one, and deaf_cause says why when this machine can tell. No timing rule compares two machines' clocks.

• UI: app/src/Backup.tsx and app/src/api.ts. The line and the details use the same rule for which reason wins.

Relay change (deploys from main via relay.yml)

relay/src/index.ts:

• A PUT now answers with the client's address (ip, from CF-Connecting-IP).
• A GET adds x-age (how long the relay has held the object).

The relay sees the address anyway and stores nothing more. Older apps ignore both. Against the currently deployed relay this PR still works; it just has no public address (so no "same range, other router" or "blocked") and judges report age by when it fetched.

Decision

#124 is Proposed. It is the last row of docs/decisions.md and spells out every rule and threshold. Please look at it in particular: it adds a relay change, and it shares subnets and public addresses between the user's own machines, end-to-end encrypted like everything on the relay.

Review

Before opening this, the change went through four review rounds: one independent reviewer, then three multi-agent rounds in which each finding was checked by separate skeptics. That turned up about 40 real issues, mostly reasons that could be wrong in edge cases (sleep, quick restarts, the same address range at a café, IPv4 vs IPv6, VPN variants, clocks). All are fixed and covered by tests.

Testing

• cargo fmt --check, cargo clippy -D warnings and cargo test on both workspaces: 486 core tests, 26 new; app tests pass.
• npm run build (app); npm test + typecheck (relay, 14 tests, 1 new).
• All 6 relay integration tests pass against a local wrangler dev, including the new "reports travel with their age" and "the live connection answers pings".
• Not tested yet: the real two-machine flow, and macOS. Brian will try it with the laptop on another network and on a VPN.

🤖 Generated with Claude Code