NoteKillnotes that do not survive

A disposable encrypted chat room, no app required

One link, no accounts, no phone numbers. Messages are encrypted in the browser, and the whole room is deleted minutes after the last person closes it.

Open a room, share one link, talk

  1. Open a room. Your browser generates a 256-bit key with crypto.getRandomValues and places it after the # in the room link. Browsers never transmit that fragment in HTTP requests, so the key cannot reach the server.
  2. Share the one link. Whoever holds it can join and read. There is nothing to install and nothing to sign up for.
  3. Talk. Each message is encrypted in the sender's browser with AES-256-GCM and decrypted only in the readers' browsers. The server carries ciphertext it cannot open.

The room erases itself

When the last person closes the tab, the room and every message in it are deleted. Here is the exact mechanism, because "a few minutes" is not an answer.

An open room asks the server for new messages every 2.5 seconds, and every one of those checks pushes the room's expiry five minutes into the future. So for as long as anybody has the room open, it keeps renewing itself in five-minute steps and nothing is lost. The moment the last tab closes, nothing renews it any more: five minutes later the room is expired, and a sweep that runs every single minute deletes it.

Worst case, six minutes after the last person leaves — the five-minute expiry, plus up to one more minute waiting for the next sweep. Nothing survives it. The room, every message in it and the participant list are removed together.

The deletion is the server's own scheduled act, not something a visit triggers. A room nobody ever opens again still disappears on time. There is no archive to request and no bin to empty. Deleted means the rows are gone.

You can see who is in the room

The room shows how many people have it open and what they are called, and it says so when somebody joins or leaves. Every browser in the room picks a random identifier for itself and sends its chosen name encrypted under the room key, exactly like a message. Other participants decrypt it; we cannot.

This is the one place where the server learns something new, and we would rather name it than let you find it: we can count the rows, so we know a room has three people in it. We do not know who they are, what they are called or what they are saying, and the rows are deleted the moment the room is. If a participant closes the tab their browser tells the room immediately; if the connection simply dies, they disappear from the list within 45 seconds.

The people in a room are visible to each other and to nobody else. There is no account to sign in to, no email address, no phone number and no username registry — you type whatever name you like, and it is encrypted with the room key before it leaves your device.

What reaches us is a random identifier the browser invents for itself and a block of ciphertext. We hold no key for that ciphertext, so the participant list is, on our side, a row of unreadable characters. We cannot tell you who was in a room. We cannot tell anyone else either, and that includes anyone who arrives with a court order: there is no name stored to hand over, and nothing to decrypt it with.

Names are not linked between rooms either. The same person joining two rooms produces two unrelated identifiers, so nothing here can be used to follow somebody from one conversation to another.

Even your name is inside the ciphertext

The display name you type travels inside the ciphertext of each message, next to the text itself. The server stores the pair as one unreadable row, so it cannot tell who is talking — not as a policy choice, but because there is no readable name in the row to look at.

That name is kept in your browser only, in sessionStorage, so you need not retype it while the tab is open. It dies with the tab. There are no cookies at all.

No app, no phone number, no account

Signal and WhatsApp are built for an ongoing relationship — contact lists, verified identities, history that persists. If you talk to the same person every week, they are the better tools, and we say so without hedging.

This room is for the other case: a one-off conversation with someone you may never speak to again. Handing a password to a contractor. A short exchange with a stranger. A conversation that should not become an entry in anyone's contact graph. You give up persistent identity; you gain a room that needs no app, no phone number, no account — and leaves nothing behind to manage.

What the server stores

Message rows
Ciphertext in the database. The text and the sender's display name are inside it; we cannot read either.
Room identifier
128 random bits from a cryptographically secure generator, never a weak PRNG.
Timestamps
When a message arrived — needed to tell whether anyone is still in the room.
Rate-limit entries
A truncated HMAC-SHA256 of the client IP under a server secret, deleted when its hour-long window closes, so it lives at most an hour plus the minute until the next sweep. The raw IP is never written to the database.

Nothing in that list contains the key. It exists only in the URL fragment, in the browsers of the people you shared it with. Access logging is switched off for this site, so there is no record of who joined which room. The server's error log still exists and can capture an IP address when a request fails.

The encryption code itself is delivered by this server — that is the honest limit of the design, and it is set out in full on the security page.