2xBRBack to SEND ↗
2XBR SEND / TRUSTED DEVICES

Remember trust.
Not activity.

This advanced SEND surface manages saved browser trust for repeat device work. First trust uses ephemeral ECDH P-256 plus a six-digit human verification code. Reconnect uses rotating rendezvous and mutual proof before any queued SEND action or pathname-only continuity offer can proceed.

01PAIRECDH02COMPARE6 DIGITS03REMEMBERLOCAL KEY04SENDEXPLICIT ACTION
SEND TRUST READYDIRECT P2P FIRSTTRUST LOCAL ONLYNO ACCOUNT

This label is shared only with the peer during the first explicit trust ceremony. It is not registered as an account or cloud device.

TRUSTED ON THIS BROWSER0 DEVICES
No trusted devices yet.Pair once with a verification code. The shared trust key stays inside browser storage on each device.
PAIR A NEW DEVICE

Trust once. Verify together.

Use QR/code signaling to establish WebRTC, then compare a six-digit SAS generated from an ephemeral ECDH exchange before either browser stores trust.

SEND TRUST / STATUSTrust a device once, then reconnect without another QR.
01 / NO DEVICE CLOUDThe server never receives your saved trust key.

Trusted devices live only in this browser’s IndexedDB. The key is stored as a non-exportable Web Crypto key, not as a cookie or account credential.

02 / MITM VISIBLEFirst trust requires a human comparison.

Both browsers derive the same ECDH secret and six-digit SAS. A signaling intermediary that substitutes peers produces different codes.

03 / ROTATING DISCOVERYNo permanent rendezvous ID.

Availability starts only when you explicitly make a device available or connect. It uses an HMAC of the saved trust key and a short time bucket; there is no background presence.

04 / PROVE BEFORE SENDSaved trust is challenged again on reconnect.

Both peers exchange fresh nonces and verify mutual HMAC proof inside WebRTC before Device Hub can service a queued SEND action or continuity route. Route handoff is canonical-path only and drops query/hash data before transmission.

SEND TRUST SURFACE / EXPLICIT BY DESIGN

Trust is subordinate.
Payloads stay specialized.

Trusted Devices does not become a transport and does not merge trust protocol with payload protocols. It only recognizes a saved browser relationship, proves that relationship again, then launches the existing bounded BEAM, LINK, CLIP, TRAY or CONTINUE workflow—or offers a known 2XBR pathname. The receiving browser still explicitly opens or continues.

FIRST TRUST ECDH P-256 + SASSAVED KEY NON-EXPORTABLE HMACRENDEZVOUS ROTATING / 15 MINRECONNECT MUTUAL PROOFACTIONS EXISTING TRANSPORTSHANDOFF KNOWN 2XBR PATHS ONLYBACKGROUND PRESENCE NONESERVER DEVICE LIST NONE