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

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: #19, #20, #21, #22, #23, #24, #25, #27 (launch: strangers must be able to install the daemon first)

Blocks: #29, #30

From PLAN.md, "Control track → S15: spike before M17 (about two days)".

E2E design, written up as a short spec:
- Pairwise channels: Noise (IK or XX) between a client device and a daemon, inside the relay's WebSocket. Measure overhead on attach and on a 1 MB burst.
- Shared sessions: the daemon encrypts a session's stream once, to a session key wrapped for each member device. On a revoke, rotate the key. Compare with plain per-viewer channels at 2, 5 and 20 viewers.
- Device keys:
  - Browser: WebCrypto non-extractable keys in IndexedDB, plus passkeys (the WebAuthn PRF extension) to re-derive them. Does PRF work in Safari on iOS and in Chrome on Android?
  - CLI: a key file.
  - Phone PWA: what happens when the browser clears its storage.
- Device approval: the flow from an existing device; recovery codes for losing all of them.
- Push: Web Push payloads are already encrypted to the subscription (RFC 8291). Confirm control can forward them without seeing contents.
Relay:
- prototype on the M4c dial-out transport with control in the middle;
- round trip from a phone on cellular, via control, to a home machine;
- how many concurrent streams per daemon;
- what a hosted relay costs per active user-hour.
Identity:
- GitHub and Google OAuth, and passkeys as a first-class login;
- email magic links for invitees without either.
Read-only links with no account: the key travels in the URL fragment (#k=…), which browsers never send to the server. Check that this works through the service worker and with link previews (Slack's unfurler must not fetch the fragment).

Output: docs/control-e2e.md (the spec) and a go/no-go on PRF for browser keys.

**Depends on:** #19, #20, #21, #22, #23, #24, #25, #27 (launch: strangers must be able to install the daemon first) **Blocks:** #29, #30 _From PLAN.md, "Control track → S15: spike before M17 (about two days)"._ --- - **E2E design**, written up as a short spec: - **Pairwise channels:** Noise (IK or XX) between a client device and a daemon, inside the relay's WebSocket. Measure overhead on attach and on a 1 MB burst. - **Shared sessions:** the daemon encrypts a session's stream once, to a session key wrapped for each member device. On a revoke, rotate the key. Compare with plain per-viewer channels at 2, 5 and 20 viewers. - **Device keys:** - **Browser:** WebCrypto non-extractable keys in IndexedDB, plus passkeys (the WebAuthn PRF extension) to re-derive them. Does PRF work in Safari on iOS and in Chrome on Android? - **CLI:** a key file. - **Phone PWA:** what happens when the browser clears its storage. - **Device approval:** the flow from an existing device; recovery codes for losing all of them. - **Push:** Web Push payloads are already encrypted to the subscription (RFC 8291). Confirm control can forward them without seeing contents. - **Relay:** - prototype on the M4c dial-out transport with control in the middle; - round trip from a phone on cellular, via control, to a home machine; - how many concurrent streams per daemon; - what a hosted relay costs per active user-hour. - **Identity:** - GitHub and Google OAuth, and passkeys as a first-class login; - email magic links for invitees without either. - **Read-only links with no account:** the key travels in the URL fragment (`#k=…`), which browsers never send to the server. Check that this works through the service worker and with link previews (Slack's unfurler must not fetch the fragment). **Output:** `docs/control-e2e.md` (the spec) and a go/no-go on PRF for browser keys.

jhgaylor added the

spike

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

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

jhgaylor referenced this issue