Skip to main content

Pairing flow

Pairing runs over whichever route the client reaches the host on. There are two, and the cryptographic exchange is identical either way: Direct — the client opens a WebSocket straight to the host using a route from the QR (lan on the same network, wan through a router mapping). No service is involved at all. This is the default and needs no infrastructure. Brokered — for a host reachable neither way, a signaling service relays the same frames between the two sides.
Step 3 is the reason a scan works without setup: the QR names the host, so the client has somewhere to go before any service exists. Repeated wrong codes are throttled on the host — a 9-digit code is only about 30 bits, and a direct socket has nothing in front of it — and the code is compared in constant time.

Pairing code

Format

Properties

Generation

Pairing URI

The QR encodes a pairing URI carrying a list of routes, not one URL:
Endpoint kinds are lan, wan, sig, relay and tunnel, and the client attempts them in that order. A real example:
An unknown kind or a malformed URL is dropped rather than making the QR unscannable, so a newer host can advertise a transport an older client does not understand. A loopback address is never accepted as a lan or wan route: on the phone, 127.0.0.1 is the phone. Version 1 URIs (v=1&s=<signalingUrl>) still parse, and are read as a single sig endpoint.

Delivering the URI to a phone

iOS has no handler for a custom scheme, so a camera app will refuse to open crosslink:// directly. Hosts put the pairing URI in the fragment of an ordinary HTTPS/HTTP bootstrap URL instead:
The fragment is never sent to the server, so the pairing code does not land in anyone’s access log.

SAS verification

Short Authentication String (SAS) digits are derived from:
Both parties must see the same 6 digits. If they differ, a MITM is likely.
Never skip SAS verification. It is the primary defense against man-in-the-middle attacks during pairing.

Fingerprint pinning

The QR code includes the first 16 hex characters of the host’s Ed25519 fingerprint:
The client verifies this matches the actual host public key during pairing.

Pairing options

Host-side options

Client-side options

Re-pairing

If a device loses its paired record:
  1. Generate a new pairing code
  2. Scan the QR code again
  3. Complete the pairing flow
  4. The old paired record is replaced

Security considerations

  • Single-use codes prevent replay attacks
  • Short TTL limits the window for interception
  • Fingerprint pinning prevents MITM by a compromised signaling service, or by anything else that can relay a host’s address while substituting its own identity
  • SAS verification confirms no active attacker
  • Capability scoping limits blast radius of compromised client