Relay: moving a password, a snippet or a screenshot between two devices, safely and briefly

01Executive summary

Everyone has needed to get something small from one device to another: a block of text to or from a borrowed computer, a password, a screenshot. Email leaves a copy forever, and chat apps tie the exchange to accounts. Relay does it with a temporary session. The owner signs in on their own device and starts a session. The other device joins anonymously with an eight-character PIN or a QR code. Snippets and files cross in both directions. The session then expires on its own.

The design principle is that the far end is anonymous by design. A borrowed machine, a shared computer or a public kiosk never needs a login, so nothing about the owner's identity is exposed to it.

02The problem

03Two audiences, one product

Relay serves two very different kinds of user, and nearly every design decision follows from that.

Route-level checks fail closed. An allow-list at the web edge would fail open every time someone added a route and forgot to update it. Sign-in discovery is lazy and self-healing, so an outage of the sign-in service can never take down PIN joining or the share endpoints.

04How a session works

1. The owner signs in with a passkey and starts a session. Relay issues an eight-character PIN and a QR code that carries a join link.
2. The other device types the PIN or scans the code. Failed attempts are rate limited, and the PIN is compared in constant time.
3. Either side shares text, a password, or a file. A hidden mode obscures what is on screen. Paste handles screenshots.
4. Any activity keeps the session alive for at least an hour; an explicit Extend adds another. Idle sessions end at two hours.
5. The owner can close the session at any time; closing deletes everything in it.

Limits keep it a transfer tool rather than a store: twenty snippets, ten files, and fifty megabytes for a file and in total. Filenames are sanitised and dangerous file types blocked.

05Handling secrets

• Passwords are never written to the archive. The estate's working assumption is that any database will eventually be dumped. Encrypting passwords in the database would leave the key beside them, so the only safe store for a password is none. A password lives in the session's memory for that session's life and nowhere else. Search and previews exclude them, and both archive write paths go through one shared policy function.
• Burn after reading. A snippet can be marked so that its text is handed to the receiving side exactly once and then destroyed, leaving only a marker so the sender can see it was received. Find, check and destroy happen with no gap, so two simultaneous requests cannot both receive the text, and the sender is refused so they cannot burn their own message by accident. Burn snippets are never archived either.
• Who sent it is decided by the server. The sender label comes only from the signed-in session, never from anything in the request, which stops a guest forging a message that looks like the owner's.
• An optional archive keeps text snippets (not passwords, not burn snippets) for the owner alone, searchable, with per-item deletion.

06Security design

07Honest limits

v1 keeps sessions, snippets and files in the memory of the running process, which is why they vanish so cleanly and why a restart or deployment ends every open session. That is a feature for privacy and a limitation for continuity, and it is the main driver of v2. The server can also read what passes through it during a session, and v1 does not defend against a server that has itself been taken over. These limits are written into the design rather than discovered afterwards.

08Relay v2

Relay v2 is in progress. Everything is encrypted on the device by default so the server can only hold ciphertext. Sessions survive restarts, paired devices share one account key, an encrypted archive has a recovery key, and a command-line client covers Windows, macOS and Linux. A dedicated white paper for v2 is pending.

09Lessons

• Design for the least-trusted device. If the far end needs no account, the near end exposes nothing.
• The safest storage for a secret is none.
• Make atomic things atomic. Burn-after-reading depends on find, check and destroy having no gap.
• Don't trust labels in a request. Derive identity on the server.
• A policy and its enforcement point are one control. Test them together.
• Look at it. A preview harness gives a human a view of UI changes that a probe cannot judge.

10Appendix: facts and figures