crosslink.onConnected(rpc) fires again on the other side of it.
Reconnection reuses the device’s existing trust. Closing the desktop app,
sleeping or restarting the machine, changing Wi-Fi or moving the phone between
networks all reconnect silently. A new pairing code is required only when the
trust relationship itself is invalid — revoked, removed, or unreadable.
A route the browser refuses is not retried as if the host were down. A page
served over
https cannot open a ws:// socket, so those endpoints are
reported as blocked with the reason, rather than burning a dial timeout on each
attempt. See Durable Origins.How reconnection works
Backoff strategy
Delay ismin(30s, 500ms * 2^attempt), with random jitter of +/-30% applied on top:
Reconnection is a new session
Each reconnection performs a fresh CLX1 handshake with new ephemeral keys:- Forward secrecy is maintained per-session
- No bearer tokens are reused
- Revocation is re-checked on every handshake
- Device identity is verified against stored records
Offline call queueing
Idempotent methods are queued during disconnection:Subscription restoration
Event subscriptions are automatically restored after reconnection:Transport resilience
The client adapts to network changes:Monitoring reconnection
Relay channel recovery
If a relay channel expires (24h lifetime), the host:- Allocates a new channel
- Publishes the new channel ID through signaling
- Clients discover the new channel via presence lookup
- Reconnection proceeds normally