Roadmap: E2E encrypted relay for remote access without Tailscale

[devswha]

Motivation

Paseo (getpaseo/paseo, AGPL-3.0) ships phone access with no VPN and no inbound ports: daemon and client each make an outbound WSS connection to a relay, and all payloads ride an end-to-end encrypted channel the relay cannot read. ChatMux currently requires Tailscale (or LAN password mode) for remote access.

Mechanism (from paseo source review, commit 098122be)

• Daemon keeps a persistent Curve25519 keypair (daemon-keypair.json, mode 0600); pairing QR carries the public key in the URL fragment so the relay never sees it (SECURITY.md:22-44).
• Client uses an ephemeral key; NaCl handshake gates all commands; payloads are XSalsa20-Poly1305 (packages/relay/src/encrypted-channel.ts).
• Relay is a separate self-hostable service (getpaseo/paseo-relay, Elixir); it only sees ciphertext + connection metadata.

Design prerequisites before implementation

1. Relay service: operate one, or self-host-only?
2. Key lifecycle: rotation, revocation, multi-device pairing.
3. Replay protection: paseo explicitly lacks in-live-session replay defense (SECURITY.md:52-54) — we should not inherit that gap.
4. Metadata exposure policy and threat model documentation.
5. How this composes with the existing tailscale/password/vpn access modes (chatmux access).

Non-goals for now

Not scheduled for a specific release; LAN password mode remains the no-Tailscale answer until this is designed.