Your recovery key
A recovery key is an optional way back into your account for the day you have lost every device. You make it once, in Settings, write it down, and keep the paper. If you ever need it, you type it on the sign-in screen and your account's own keys come back. It is yours to turn on, and it is off until you do.
What it brings back, and what it cannot
A recovery key brings back your account's identity (so the people you talk to see no change), the keys you had accepted for them, your personal key if you have one, how you arranged the app, and the messages you sent that this server still holds.
It cannot bring back what other people sent you. Those messages were sealed to the keys of the devices you have lost, which are erased as they are used and were never copied anywhere, so nobody can open them again. Drafts and the history your old devices had already opened are gone with those devices.
That is the honest size of it. Yeetline holds no key that opens your messages, so no backup of an account can include the keys of messages that were never kept anywhere but on the devices that received them. A recovery key keeps your identity, and the part of your history that was sealed under your own account's key.
It is as secret as your password
Anyone who holds your recovery key can restore your account's keys, so keep it as secret as your password: on paper in a safe place, or in a password manager. Do not photograph it into a cloud album, and do not send it in a message. If you think someone has seen it, make a new one (below), which stops the old one at once.
Make one
You are offered one once, in a notice right after you create an account, and it waits in Settings after that.
- Open Settings and find Recovery key, then Make a recovery key.
- Read what it does and does not do, and choose Make the key. You are asked to confirm it is you first (see below), before any key is made.
- The key appears once, in fourteen groups of four letters and numbers. Write it down, copy it into a password manager, or Save as a file and print the file. The letters and numbers are chosen so that none can be mistaken for another: a zero and an O are the same to the app, and so are a one, an I and an L, and the last four characters are a check that tells you when a character is wrong.
- To show you really have it, type the last two groups. Only then is the key turned on. Cancel at any point and the key never existed.
The key is made on your device from the browser's own random source (256 bits). It is never sent anywhere: not to this server, not to Yeetline, and not into a message. When the dialog closes the page forgets it.
Use it
On the sign-in screen choose Forgot your password?, then Recover this account, then I have my recovery key. Type your username and the key (capitals, hyphens and spaces do not matter), choose a password for the device you are on, and choose whether to sign out every other device your account has used. That is recommended if you lost them. Then Restore my account.
There is no email to wait for and no waiting period: the key is the proof. If your account has a second factor (an authenticator app or a passkey), you are asked for it when you sign in, as always: the recovery key does not replace it. If you lost that along with your devices, use one of the recovery codes you saved when you set it up, or ask an administrator to reset it. Nobody's safety number changes, because your account's keys are the ones it always had.
On a device you restore this way, the account starts with Sync keys off. Turn it on in Settings if you want it. Your recovery key stays on, and your old paper still works.
Confirming it is you
Making a key, replacing it and turning it off are the three things that change the one way into your account that needs no device, so each asks for a fresh proof first, even on a device that is signed in. Without it, somebody who picked up your unlocked laptop could make a key of their own, or replace the one you wrote down, and hold a way back your paper no longer opened. The proof is for one change, on that device, and lapses after fifteen minutes. What you are asked for is the strongest thing your account has:
- If it has a second factor: your passkey, a code from your authenticator app or one of your recovery codes, or a code mailed to the address on the account. Never a password, because a password is the one proof somebody holding a signed-in session might already have planted, or that a restore left behind under an old one.
- Otherwise: your password on this device. The server holds nothing it could check a password against (it never sees one), so this device checks it. That stops somebody at your unlocked device; it does not stop a program that speaks to the server. Adding a second factor in Settings makes this a real check, and the screen says so.
A wrong answer counts against that connection and against your account from that network address, and against nothing else: it does not slow your sign-in, and it cannot keep you from making a key from somewhere else. The background refresh of the backup (below) is not one of the three changes and asks for nothing.
The backup is always a backup that fits
A backup holds, first and always, your account's identity, its self key and your personal key; then the contacts whose keys you accepted, the ones you talk to most recently first; then how you arranged the app. It is built to a size it always fits (about 900 KB before sealing). For nearly everyone that is all of it. An account with many thousands of contacts (an organization's) gets the most recent ones, and when something is left out the page says so in words, never silently:
- The Settings card says when the newest changes are not backed up and why ("Your newest changes are NOT backed up. The server did not answer the last tries. What a recovery key would restore is the backup from Tuesday; this page keeps trying"), and when the backup is incomplete ("it holds the 5800 most recent of the 20000 contacts whose keys you have accepted").
- A notice appears in the page, once, when a refresh fails for a reason a retry does not cure (the server refused it) or has not cured (the server did not answer twice), with a button to the card. It tries again in a minute, then five, then every half hour, and tells you when the backup is current again.
- After a restore from an incomplete backup you are told how many contacts were not in it. You will be asked to accept their keys again, as for anyone new.
Replace it, or turn it off
Make a new key in Settings replaces the old one: the old paper opens nothing from that moment. Turn off deletes the backup from the server, and the paper opens nothing. Both ask you to confirm it is you first. Both are mailed to the address on your account, and so is making a key and using one; using the key also puts a notice on every device you have open. If you get one of those messages and it was not you, sign in, sign out the devices you do not know, make a new key, and change your password.
Those messages go to the address on your account. An account with no address has nobody to mail: a use of the key is shown on its open devices and written to the audit log, and making, replacing or turning off the key is only in the audit log. If you want to be told, add an address to your account first.
What the server keeps
| What | Why | For how long |
|---|---|---|
| A public key the recovery key makes, and a signed note naming your account's identity key | The first is what a signed-in device seals the backup to; the second is how the device you restore on tells your backup from one somebody made up. Both are public by nature | Until you replace or turn off the key, or the account goes |
| A hash of a value the key derives | So the backup is handed only to somebody holding the paper; the value cannot be turned back into the key | The same |
| The backup: your identity keys, the keys you accepted for your contacts, your personal key, how you arranged the app, sealed so only the key opens it, and padded to a size bucket | It is the whole point | Replaced as your account changes; deleted with the key |
| An audit line when a key is made, replaced, turned off or used (with the address the request came from) | So you and your administrators can tell | As long as the audit log is kept |
The server cannot read the backup: it does not hold the key. A copy of the database, or of a backup of the database, holds a sealed backup and nothing that opens it. Nor can it make one up: the paper signs, once, a note that names your account's identity key, and your devices sign each backup with that identity key, so the device you restore on checks both against your paper before it believes a byte. What the server could still do is hand back an older backup your account really made, or none at all. Renaming an account, an administrator handing the name over with a new password, and recovering the account by email (which gives it new keys) each delete the recovery key too, because the keys it describes are gone or the name is sealed into it.
What this has not had
The recovery key is built from parts the cryptography community trusts (HKDF-SHA-256, Ed25519 and X25519 key agreement, and AES-256-GCM), and nothing of Yeetline's own design. How they are put together is new, and it has had no formal model and no review by a cryptographer outside Yeetline yet. We say so here so you can weigh it. It is a second way back, not a replacement for keeping a device signed in.
Against a future quantum computer
The backup is not post-quantum, and the Settings card, the sheet you save and the box that opens when you make the key all say so in these words:
The backup is sealed with X25519 key agreement, which a quantum computer would break. Somebody who copied this server's database today and had a quantum computer one day could open it: they could take your account's identity keys, read the messages your account sent that the server holds, and use your personal key. It holds none of the post-quantum keys that protect what is sent to you, so it does not weaken that protection. A post-quantum seal for the backup is not built.
What is protected: the backup has no lattice (ML-KEM) key in it, so a copy of it does not weaken the post-quantum part of the handshake that protects what other people send to you. What is not: the seal itself, which is the sealed block of the rest of the app and has no lattice leg. Closing that would need a hybrid seal (X25519 with a lattice key derived from the paper) and a second public key on the server; it is a new composition, listed for the owner to decide, and not built.
If your devices were stolen
A recovery key restores your account's own keys, so it does not lock out someone who already holds a device of yours and its password. If a device was stolen and its password may be weak, recover the account the other way instead (new keys, see Recovering your account), and use a long password on every device.
See also Your account and The ways to sign in.
Last changed 2026-10-19