Repository navigation
VPN / Tether — one private peer & explicit route #20
Description
Outcome
One explicitly admitted private route works, refuses other access and remains revoked after restart.
Next planning checkpoint: Init. This is the earliest scope/review conversation, not an assignment or a promise to finish the whole outcome in that week. Selected work starts at #52.
Remaining acceptance
- Define the Tether extension/Rune: interface, listen port, addresses, peer, exact allowed route and DNS behaviour.
- Keep private keys in the secret boundary; validate route/address overlap, ports and key references before binding.
- Admit the typed service contribution and required UDP/network policy through Bind; isolate Tether outside the shared application Pod with minimum privileges.
- Provide authorized peer admission, inspection and revocation through a host-owned operation contract; persist intent and never revive revoked access on restart.
- Prove the intended route works and other listeners/routes remain denied; application authentication and authorization still apply.
- Report tunnel failure without falling back to a public path; provide bounded health and recovery information.
- Verify bind/start/restart/revoke/removal with two endpoints and record the network, runtime and privilege assumptions.
#151 merged on 11 November 2026. Current State of Work records Partial native Tether implementation with source/focused-test evidence; named live deployment, revocation/restart/reboot and device/browser acceptance remain separate. The acceptance above remains binding. Coordinate with the current owner before implementation. #152 includes understanding and selecting a bounded reproduction of the relevant boundary, not a competing rebuild. A VPN experiment supplies reachability evidence, not application authority.
Evidence and handoff
Start from current State of Work and its linked source/tests and owning ADRs. The linked original acceptance remains binding unless a named replacement outcome records its disposition. Detailed scope, negative cases and dated campaign evidence are preserved in preserved scope and evidence; historical evidence does not establish current qualification on its own. Any accepted requirement not selected for this profile needs an explicit route in #62 before this issue closes.
Choose one small implementation or verification slice when this outcome is admitted. Record the responsible contributor, exact profile/revision, observed result, failure/unknown boundary and next checkpoint. The founder reviews and approves all code for this campaign; merge and promotion follow CONTRIBUTING.
Activity
[-]VPN / Tether — Basic: one private peer & explicit route[/-][+]VPN / Tether — one private peer & explicit route[/+]zenithruneblade commentedon Nov 6, 2026
Planning reset — 6 November 2026. The original acceptance below remains binding unless a named replacement outcome records its disposition. This is a preserved historical body, not a fresh capability/qualification claim.
Original issue scope and dated evidence before the planning reset
Provide one operator-controlled WireGuard peer with one explicitly permitted private route, including revocation and visible failure.
Starting point: Tether is Designed. Current deployment is loopback-only and rejects UDP; tunnelling the existing application is not an implementation shortcut.
Checklist
Done when: one peer reaches only the admitted endpoint, loses access after revocation, and stays revoked after restart.
Completion prerequisites: #1 Configuration, #3 Bind and #18 host lifecycle. This network work can proceed alongside Graph.
Related: #19 A2A/Intercom may use this road; outbound polling does not inherently require it.
Later: rotation/export UX, additional peers, Veil/Gateway profiles, roaming/NAT decisions and broader recovery. Consumer VPN exits and anonymous browsing are outside this issue.
References: VPN (ADR 39) · Containers (ADR 08) · Security (ADR 09) · CLI (ADR 19).
Shared foundations: #24 owns application authorization and #37 verifies the admitted network boundary. Tunnel membership alone grants neither.
Network map: #57 owns admitted ingress; #52 keeps Gateway/Legion as later directions rather than expanding this first slice.
Advanced integration review: #62 exercises Tether as optional private reachability for an already admitted A2A peer or endpoint. If the tunnel drops, the selected road becomes unavailable or uncertain; it must not fall back to public transport, mint task authority, or erase an already submitted peer effect.
Contribution entry: Contribute Rune/route validation or a reproducible two-endpoint test profile.
Open decision: Pin the first peer operation and least-privilege service topology under ADR 39.
Verification: Offline route validation; controlled network hosts for acceptance. Shared contribution and touched-docs rules: #52.
Stabilize Server provisioning and persistent filesystem ownership
Stabilize Server provisioning and persistent filesystem ownership (#148)
Merge pull request #151: native Tether lifecycle and named attachments
Merge pull request #157: prepare WireGuard userspace prerequisites
Merge pull request #158: retain native custody of Tether role launches