The Android lab produced an explicit relay path. The captured evidence also showed where the proof stopped.
The Internet-edge test had left us with a clear requirement: direct inbound reachability was not confirmed, so the node needed a relay-assisted option. The next work connected that requirement to an explicit helper and path representation.
The Android evidence package dated September 22, 2026 records a PASS summary. Reading the underlying snapshots gives that result a more precise meaning.
Turning a requirement into a path
The relay work introduced a bounded candidate derived from an accepted helper peer. A target-aware reservation projection could then represent a relay-assisted route and retain the helper's identity separately from the target's identity.
That separation is essential. Connecting to a helper does not establish a connection to every peer the helper might help us reach.
The reservation in this implementation is a local controlled-lab projection. It performs no network reservation exchange and is not a production capacity allocation. Its accepted state records that the represented path can be advertised under the lab's rules.
The Android setup supplied lab-scoped bootstrap and restricted-relay configuration to the native GNS daemon.
What appeared in the snapshots
The captured transport status reported:
- a relay candidate was available;
- the reservation projection was accepted;
- the relay path was advertisable;
- public direct reachability remained unconfirmed.
The peer snapshot contained one connected helper and a target peer in a degraded state. The retained event window recorded failed direct attempts and the transition to relay-required status.
Those observations support a relay candidate and path becoming available on the restricted Android node.
They do not, on their own, establish a successful end-to-end exchange with the target through that relay.
Reading PASS at the right scope
The package summary marks the Android restricted-relay scenario as PASS. The lab procedure describes a stronger condition for target acceptance: the existing relayed hello must succeed before the target is accepted.
The retained snapshots do not settle that stronger question. The connected-peer count can be explained by the helper connection, while the target remains degraded in the peer list. A path-advertisable flag cannot fill that evidential gap.
The preceding relay milestones also contain validation commands explicitly marked as not run by the implementing agent. Their test code and descriptions are useful implementation evidence, but they should not be presented as a separate physical acceptance run.
What would complete the next claim
To describe a verified end-to-end relay connection, the next evidence needs to identify the target's successful handshake, the resulting authenticated peer state, the relay route used and traffic on that route.
That would also need to be distinguished from a controlled local-network setup. This Android package does not establish mobile-data Internet relay readiness or a production relay service.
For now, the recorded progress is concrete: the restricted Android node could represent an available helper and a bounded relay path without pretending that public direct reachability had been established.
The next task is to carry that path through to target-specific connection and traffic evidence.
Built in Public. Documented as we build.
Top comments (0)