fix(mesh): route send-content-inline over federation for radio-less peers #133

Open
ssmithx wants to merge 2 commits from fix/mesh-send-content-inline-federation-fallback into main
2 Commits
Author SHA1 Message Date
ssmithxandClaude Sonnet 5 7560e0b5e6 fix(mesh): don't offer radio-only resource transfer to radio-unreachable peers
The first fix (federation fallback in the plain content-inline path) wasn't
enough — mesh.transport-advice recommended the "resource-mesh" tier purely
from our own device being Reticulum-capable, without checking that THIS
peer actually has a radio route. For a federation-only contact (no radio
twin) that steered the frontend into send-content-inline's Reticulum
resource-transfer path, which has no dest_prefix to send to and fails with
"Peer is federation-only (no radio twin)" — reproduced again on
archy-x250-mad2 after deploying the first fix.

Adds MeshService::has_radio_route(contact_id), and gates both the
"resource-mesh" tier in mesh.transport-advice and the resource-transfer
branch in mesh.send-content-inline on it. Federation-only peers now fall
through to the has_tor branches, which route the frontend to
mesh.send-content (already correctly federation-aware) instead.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-07 15:09:46 +00:00
ssmithxandClaude Sonnet 5 937f7b71ec fix(mesh): route send-content-inline over federation for radio-less peers
mesh.send-content-inline always called send_typed_wire (the LoRa/radio
path), which fails with "Peer is federation-only (no radio twin)" for
any contact reachable only via Tor federation — reproduced sending a
picture from the companion app to a federation-only peer on
archy-x250-mad2. mesh.send-content already resolves the peer's
federation onion and falls back to send_typed_wire_via_federation;
mirror that same lookup here.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-07 12:26:00 +00:00