Tailscale as an alternative transport

[karngyan]

Why

A large share of self-hosters already run tailscale on every machine they own. For them the Cloudflare relay is an extra account, an extra deploy, and an extra trust question. On a tailnet the daemon is reachable directly: no relay in the data path at all, and the web bundle is served by the daemon itself, which makes the hostile-relay-origin discussion in the FAQ simply not apply to tailnet users.

Rough scope

• Detect a running tailscaled and offer to bind the tailnet interface alongside loopback, or embed tsnet so flue carries its own node. Detection first, tsnet later if wanted.
• HTTPS via tailscale certs so the PWA installs and the crypto APIs are available.
• Pairing still applies: device identity, not network reachability, stays the security boundary. Whether tailnet identity can stand in for pairing (the tailnet already authenticated the device) is a real design question to settle in this issue.
• The fleet directory needs a substitute for the relay's directory endpoint: machines on the tailnet need a way to find each other, whether that is a client-held machine list or daemons announcing to each other.

Notes

• The relay remains the default path. Tailscale is an alternative for people who already live there, not a replacement.
• Slack, Linear and GitHub style integrations were considered alongside this one. Tailscale ranks above them because it strengthens the core product story (your machines, your network, no third origin) rather than adding a surface.