Research: hosted Connect — sign in on each device, the phone reaches the computer without Tailscale #2387

Goal (Human direction, 2026-10-20)

A T3 Connect–style option: the Human signs in with the same account (WorkOS) on the computer and on each phone, and the devices connect to each other automatically through a tunnel or relay we host (for example Cloudflare Tunnel). No Tailscale install, no tailscale serve, no QR code needed for the common case.

主要是看我们这边用 workos 提供用户登录，然后用户可以来连接，借助我们的 Cloudflare Tunnel？等方式类似 t3 connect，只需要两个或者多个设备都登录，就可以自动连起来

This issue is research plus an ADR for the Human to decide. No implementation before that decision.

Today

• Store test builds set EXPO_PUBLIC_DEEPSEEKBOT_CLOUD=off and pair only over Tailscale HTTPS (*.ts.net) or loopback (apps/mobile/src/host/route.ts, packages/core/src/devices/routes.ts). Tester guide: docs: Tailscale phone pairing guide for testers #2385.
• Hub: DeepSeekBot mobile app — native Expo client for a home Host #1643 explicitly kept a hosted relay out of v2.0: "A T3 Connect–style hosted control plane (account, managed tunnels, relay push) is a later, separate decision."
• ADR-0199: the phone talks only to the device gateway (/botharness-device/*) with a per-device credential, and the pairing link carries an ordered route list. A relay route can be added without changing the phone's protocol.
• TOB already has WorkOS sign-in, PKCE on the phone and a hosted service (ADR-0229, ADR-0230). It handles cloud group Channels, not reaching the Human's own Host.
• Earlier survey: docs/research/2026-09-23-mobile-remote-access-strategy.md (single-user, ruled out self-built Signal/TURN at that time).

Options to compare

1. Per-Host Cloudflare Tunnel managed by us. The Host runs cloudflared (or an equivalent) with a tunnel we provision after sign-in; the phone gets https://<host-id>.<our-domain>. Questions: provisioning API and quotas, per-tunnel cost, binary distribution on macOS/Windows/Linux, and whether Cloudflare (and therefore we) can see plaintext.
2. Our own relay on Workers + Durable Objects (reuse TOB infrastructure). Host and phone both keep an outbound WebSocket to a rendezvous object keyed by account and Host; the relay splices device-gateway traffic. Questions: Durable Object cost per connected Host, WebSocket limits, and end-to-end encryption on top (Noise or TLS-in-WebSocket keyed at pairing) so the relay sees only ciphertext.
3. Hosted mesh (Tailscale-compatible control plane, e.g. Headscale, or embedding tsnet/WireGuard). Questions: whether "just sign in" is achievable without a separate VPN app on iOS (Network Extension), and the operational burden.

For each option: cost at 100 / 1k / 10k Hosts, latency, E2E encryption, abuse surface (open relays, phishing subdomains, bandwidth), what a compromised account or a compromised relay can do, offline and failover behavior, and how it fits the existing route list and device credential (relay as one more route, Tailscale kept as a direct route).

Questions the ADR must answer

• Trust. Does signing in replace QR pairing, or only find the Host? Recommended starting point: sign-in discovers and routes; the device credential and first-time approval on the computer stay, so a stolen account password alone cannot reach a Host.
• Identity. Does the account bind to TOB's WorkOS environment or a separate one? How are Hosts registered to an account and removed?
• Push. Content-free push (ADR-0202) stays as is, or moves through the relay?
• Product. Free tier limits and whether the relay is opt-in per Host.
• Reference. How t3code / T3 Connect does it (pingdotgg/t3code docs/user/remote-access.md), checked against primary sources.

Deliverables

• docs/research/<date>-hosted-connect.md with the comparison above and primary-source citations.
• An ADR draft (Proposed) with a recommended option and a first tracer bullet.
• A decision from the Human before any code.

Refs #1643, #2385