Pairing

The first owner of a host is established locally, through the operating-system account you are logged in as. Every device after that is paired, and pairing always ends with you approving the new device on the machine that issued the invitation.

Two ways in

Scan a QR code

The direct QR carries the host’s endpoint, its network configuration, a single-use secret and the grant being proposed. It works on a local network with no lookup and no service in the middle.

Type a ten-character code

Shown as XXXX-XXX-XXX. The first four characters locate a temporary meeting record; the remaining six are the shared secret. You never type a full network address.

$ kr pair invite
code   QFM4-7KD-BNP
origin https://reach.kala.to
expires in 5:00 · 5 attempts remaining
# Enter the code on the new device, then approve it here.
$ kr pair confirm

What the code is, and is not

• It is an invitation that expires after five minutes, not a permanent name for your computer. Once it is used, denied, cancelled or expired, it is finished.
• The six secret characters are drawn uniformly from the Base58 alphabet, giving about 35 bits. The host allows five failed confirmation tags per invitation, so guessing succeeds against one host with probability around 1.3 in 10 billion before you are asked to approve anything. That figure assumes the password exchange prevents guessing offline, and it bounds one host: reusing a code across several clients multiplies the attempts.
• Malformed messages, abandoned attempts and local configuration failures consume rate and slot budgets, not that allowance, because they produce no confirmation result.
• Those six characters never enter a service request, a URL, a log or an analytics event.
• Entry accepts spaces and hyphens and preserves case. The input control turns off autocapitalisation and autocorrection, because the code is case-sensitive.

The meeting service sees very little

For code pairing, the client sends only the first four characters to the meeting origin, which returns an invitation identifier and an advertised expiry. Nothing from that service is trusted until the two devices have proved the shared secret to each other. The service never receives a readable host address or key bundle, and it cannot create a grant.

The origin is always displayed, including the default one, both when you enter a code and on the screen that issued it, with a way to change it before an attempt starts. A scanned code that names a different origin requires an explicit confirmation showing the full hostname first.

Owner approval

Proving the secret locks the invitation to one candidate and cancels the others. It does not grant anything. Both devices then display the same short verification value, so you can see you are approving the device in front of you. The host commits the device record and its grant only after you confirm on the issuing device, and the device cannot enlarge the grant it was offered. A denial, expiry, cancellation or five failed confirmations consumes the invitation; a new one needs another deliberate action from you.

Revoking

kr device list shows what is paired and kr device revoke removes it, under local owner authority. Revocation stops future access. Personal owner grants stay valid until you revoke them, so your own access never depends on a service being reachable.