Port 443 + WSS as the universal transport. Three deployment modes covering LAN, VPN, and public.

⚙️ Daemon — localhost:27471

Only ever localhost. No external traffic ever reaches this port — it's the local HTTP context server agents talk to on the same machine. Standardizing at 27471 is fine — it's invisible to corporate firewalls.

Well-known so any IDE extension or tool knows where to find context without config.

📡 Relay — port 443, WSS

WebSocket Secure (WSS) over port 443. Maximum firewall compatibility — this is how Figma, Linear, Slack, GitHub all do real-time. Corporate DPI inspects 443 for TLS handshake, sees valid cert, lets it through. Events flow over the persistent WS connection.

TLS cert required. Self-signed for LAN, real cert for public VPS.

Three deployment modes — same protocol, different connectivity

Mode 1 — LAN (same office / same network) self-hosted, day 1

Setup: Any team member runs synlynk relay start on their machine. Relay announces itself via mDNS (Bonjour/Avahi — same as printers, AirPlay). Other members' daemons auto-discover it on the local network — zero config.

Port: 8443 (non-root) or 443 (root). Self-signed TLS cert auto-generated.

Firewall behaviour: Internal LAN traffic is almost never firewalled between peers. mDNS multicast on port 5353 (always allowed on corporate LAN). WSS traffic stays on the internal subnet.

Remote members: Connect via corporate VPN → appear on the same LAN subnet → auto-discover relay via mDNS. Standard enterprise VPN pattern.

Mode 2 — Cloudflare Tunnel (no VPN, no open ports) hybrid teams, WFH

Setup: Host runs cloudflared tunnel alongside synlynk relay start. Cloudflare Tunnel punches an outbound-only connection to Cloudflare edge — no inbound ports required. Free tier. Team gets a public HTTPS endpoint (relay.yourteam.workers.dev or custom domain).

Migration: Move relay to VPS → update Cloudflare Tunnel config → same public URL. Zero disruption.

Why this works in corporate environments: The tunnel is outbound-only (HTTPS to Cloudflare). Corporate firewalls allow outbound 443 universally. Team members connect inbound via Cloudflare's edge on 443. The firewall sees standard HTTPS traffic.

Tailscale alternative: Same principle — private mesh network, all traffic encrypted, no open ports. Better for teams already on Tailscale.

Mode 3 — VPS (persistent, no single host dependency) teams with budget, always-on

Setup: Relay deployed to Fly.io / Hetzner / Railway. Real TLS cert (Let's Encrypt, auto-managed). synlynk relay connect wss://relay.yourteam.com. All daemons connect outbound to 443 — firewall transparent.

Cost: Fly.io free tier covers 4-10 person team. Hetzner €4/mo if you want dedicated.

This is the graduation path:
Day 1 → LAN (mDNS, self-hosted)
Growing team → Cloudflare Tunnel (no VPN requirement)
Stable team → VPS (always-on, no single-host dependency)

Migration between modes = update relay URL in workspace config + broadcast. Same WSS protocol, same event format throughout.

🔄 Revolving Host Protocol — loud by design

synlynk relay handover <member> — triggers the handover sequence:
1. Old host broadcasts signed RELAY_HANDOVER event to all connected daemons (new URL, new host identity, timestamp)
2. Grace period: 10 minutes — old relay stays alive, proxies any laggard connections to new relay
3. All daemons reconnect to new relay, acknowledge with signed RELAY_CONNECTED event
4. Old relay shuts down after grace period OR when all members confirmed
5. Degraded-mode warning: any daemon that hasn't confirmed within 5 min gets a loud local alert — "relay host changed, work may not be syncing"

Rule: no silent host changes. A member going offline mid-session triggers a degraded-mode warning to all, not a silent failure.

Does this relay architecture address the enterprise concerns? Ready to include this in the spec?

Relay Architecture — Enterprise Network Reality