M18: relay and end-to-end encryption #30

New issue

Open

opened 2026-10-02 01:51:18 +00:00 by jhgaylor · 0 comments

jhgaylor commented

2026-10-02 01:51:18 +00:00

Owner

Depends on: #29, #28
Blocks: #31

From PLAN.md, "Control track → M18: relay and end-to-end encryption".

Relay:
- an enrolled daemon keeps the M4c dial-out connection open to control;
- clients that can't reach a daemon directly (no tailnet, NAT both sides) connect to control, which splices the client's stream onto that daemon's connection;
- control forwards opaque frames, multiplexed as dial-out already is.
Direct when possible:
- the client tries in order: tailnet or LAN URLs from the directory, then the relay;
- the host chip shows which path is in use ("direct" or "relayed").
- Hole punching (WebRTC data channels, for example) is a later optimisation, not this milestone.
E2E per S15:
- every client–daemon stream is encrypted end to end, on the relay and on direct paths, so there's one code path;
- snapshots, output, input, method calls and events all go inside it;
- control sees connection metadata and byte counts.
Fair use: per-account relay byte counters, exposed to M22. Limits are configurable; self-hosted has none by default.
Done when:
- from a phone on cellular, attaching to a Mac behind home NAT through control draws vim correctly, and typing feels the same as on the tailnet (within 30 ms of the direct path);
- a packet capture on control shows no terminal content;
- control's database and logs contain no terminal content;
- switching the phone to the tailnet moves it to the direct path on reconnect.

**Depends on:** #29, #28 **Blocks:** #31 _From PLAN.md, "Control track → M18: relay and end-to-end encryption"._ --- - **Relay:** - an enrolled daemon keeps the M4c dial-out connection open to control; - clients that can't reach a daemon directly (no tailnet, NAT both sides) connect to control, which splices the client's stream onto that daemon's connection; - control forwards opaque frames, multiplexed as dial-out already is. - **Direct when possible:** - the client tries in order: tailnet or LAN URLs from the directory, then the relay; - the host chip shows which path is in use ("direct" or "relayed"). - Hole punching (WebRTC data channels, for example) is a later optimisation, not this milestone. - **E2E per S15:** - every client–daemon stream is encrypted end to end, on the relay *and* on direct paths, so there's one code path; - snapshots, output, input, method calls and events all go inside it; - control sees connection metadata and byte counts. - **Fair use:** per-account relay byte counters, exposed to M22. Limits are configurable; self-hosted has none by default. - **Done when:** - from a phone on cellular, attaching to a Mac behind home NAT through control draws vim correctly, and typing feels the same as on the tailnet (within 30 ms of the direct path); - a packet capture on control shows no terminal content; - control's database and logs contain no terminal content; - switching the phone to the tailnet moves it to the direct path on reconnect.

jhgaylor added the

milestone

control

labels

2026-10-02 01:51:18 +00:00

jhgaylor added a new dependency

2026-10-02 01:51:19 +00:00

#29 M17: illogical control (accounts, devices, enrollment, directory)

jhgaylor added a new dependency

2026-10-02 01:51:19 +00:00

#28 S15: spike before M17 (about two days)

jhgaylor added a new dependency