Messy privacy policy

Last updated: 28 September 2026

Messy is a private messaging app run by one person for a small circle of friends. There is no company behind it, no advertising and no analytics. This page says what the app and its server keep, for how long, and who can see it.

What is encrypted

Messages, photos and captions are encrypted on your phone before they are sent, using a key that only the phones in the conversation hold. The server stores and forwards the encrypted copy and cannot read it. The same is true of:

Before a photo or GIF is encrypted, the app takes out the details its file can carry besides the picture, such as where and when it was taken and on which phone. It keeps only what the picture needs to be shown as it looks: its colours, its frames and which way up it goes. A picture the app cannot do this for is not sent.

What the server can see

The server necessarily knows some things in order to deliver messages:

What is kept, and for how long

The backup

The server keeps everything in one file on one computer, so a copy of it is encrypted and sent to off-site storage every night. It is encrypted before it leaves that computer, with a key the storage provider does not have. Copies are kept for about a month; a few of the most recent are always kept whatever their age, so there is never a stretch with nothing to restore from.

A backup holds no messages at all. Not the ones everyone has read, not the ones nobody has read, and not the ones you unsend. Every message is taken out before the copy is made, so no message you write is ever in off-site storage, for any length of time. Nor are reactions, scheduled messages, auto-replies, duress alerts, spoons statuses, which chats people have muted, who changed their name that day or tried to, when anyone’s name changed or who changed it, the ids kept of deleted and unsent messages, the IP addresses of a device seen connected twice, or the keys notification codes are made with.

Everything else is in it, chiefly: account details (names, the name each account was created with and every name it has had since, in order, handles, and each device’s name, public key, notification address, iPhone or Android, app version, when it last connected, and one-way hashes of its sign-in token and of any it replaced), invite codes not yet used, which conversations exist, what group conversations are called, who is in them and the name each member goes by, group invitations still waiting and declines, how long each chat’s messages last and who last changed that and when, how far each person has read in each conversation, who has blocked whom and any change a blocked person made meanwhile to how long their chat’s messages last (and, where a blocker has changed their name since, the name they blocked with), and chat backgrounds, still encrypted. These are the things that could not be rebuilt if the computer were destroyed.

So a backup restored after a failure brings everybody’s account and every phone back, and brings the conversations back empty. That is the same thing that happens to a message at most three days after everyone reads it; the backup simply does not keep one for longer than the server does. Anything scheduled, any auto-reply, any duress alert and any mute would have to be set again.

Besides the nightly backup, the person running the server can take a copy by hand, on that same computer, before changing something. It is not encrypted and goes nowhere else. It holds everything, messages included, but not spoons statuses, scheduled messages, auto-replies, duress alerts or mutes, and it is kept until they delete it.

A deleted account, with the record of every name it had, stays in the copies made before it was deleted until those are deleted: about a month for the nightly off-site ones, which never held its messages, and for as long as the person running the server keeps a copy taken by hand, which may. So that putting one of them back does not bring anyone back, the server keeps a list of the accounts deleted, with only each one’s random number and when. The list is in every copy made after a deletion, and also in a file beside the database, which putting a copy back does not replace; as it starts, before any phone can connect, the server deletes again any account on the list that a copy brought back. Only a copy from before a deletion, put back on a new computer with no later list beside it, would bring that account back, until the person running the server deletes it again.

On your phone

From the version of the app after 0.2.4:

Notifications

The app asks for permission to show notifications once, right after you pair it, and after that only when you tap Background notifications in Settings. (On Android 12 and older, apps may show notifications unless you turn them off in the phone’s settings, so there it does not need to ask.) Once it may, the phone gets a notification address from Apple or Google, has Expo’s push service turn it into one the server can use, and gives that to the server. Expo sees your IP address when the phone asks it, which it does again only when something has changed.

The server sends each notification through Expo’s push service, which passes it on to Apple or Google. Expo, Apple and Google see your phone’s notification address, when each notification was sent, and a short code that only your phone can turn back into the conversation it is about. Your phone’s code for a conversation is different from anyone else’s, so the codes do not tell them which phones share a conversation; they can tell that two notifications to your phone with the same code are about the same one of your conversations. The notification itself never contains a message, a name, or a spoons level; it only says that something new is waiting.

A chat you mute is sent no notification at all until the mute ends: the server wakes none of your phones for it, so Expo, Apple and Google see nothing about it either. The one exception is a duress alert, which wakes your phones with the same notification as any message, because it is meant to reach you at once. Its messages still arrive whenever the app connects, and still count as unread.

A screenshot notice wakes no phone at all, muted or not, and is not counted as unread: it is in the chat the next time the app connects.

The microphone

The app asks to use your phone’s microphone the first time you record a voice note, and not before. It uses it only while you are recording one: from when you press the mic until you let go, send it or discard it, for at most two minutes; at two minutes the recording stops for good. It never records in the background: leaving the app or the chat, or the app locking, stops a recording and throws it away, and so does a call, or anything else on the phone that takes the microphone while you record.

While you record, your phone keeps the sound in a temporary file in the app’s own storage, which is how the phone’s recorder works. When you finish, the app reads it into memory, deletes the file at once, and encrypts the sound before anything leaves the phone. A recording you cancel or discard is deleted without being read.

To play a voice note, the app fetches it encrypted, decrypts it in memory, and writes it to a temporary file for the phone’s player, since the player plays only from a file. That file is deleted as soon as the note stops, finishes or another starts, and when the app goes to the background or locks. The last few voice notes you played stay decrypted in the app’s memory, so that playing one again needs nothing fetched, until the app locks, is unpaired or is closed. None of these files is in your phone’s backups.

You can turn the microphone off for Messy in your phone’s settings at any time; everything else in the app works without it. The app asks for no other permission to do with sound.

YouTube link previews

Off unless you turn them on, in Settings, on each phone. When they are on and you send a link to a YouTube video, your phone asks YouTube for that video’s thumbnail and title and sends them with the link, encrypted. YouTube sees your phone’s IP address, which video, and when; no cookies are sent or kept. If that takes more than a few seconds, the link goes without a preview. Nobody else’s phone contacts YouTube to show the preview you sent; tapping it opens the video in YouTube’s app or your browser.

Invite links

An invite code can be sent as a link, https://chat.tlbmiss.com/i followed by “#” and the code. The code is the part after the “#”, which browsers and phones never send to any server, so opening the link does not give the code to the server or to the relay. A phone that opens the link without the app is shown a short page by the server, the same for everyone, which cannot show the code because it is never sent it; the server keeps no record of that, and the relay logs the connection as it logs every connection (see above). The code reaches the server only when you pair with it, as a typed code does. On a phone with the app, the link fills the code in and pairs only when you tap to pair.

For links to open in the app rather than the browser, phones check that the server allows it: an Android phone checks when the app is installed or updated, itself or through Google, and iPhones ask Apple, whose servers fetch the answer from the server. What they fetch names the app and nothing about you.

Screen lock

The app asks your phone whether it has a screen lock (a passcode, PIN, pattern or password), so that Settings can warn you if it has none. It learns only yes or no, never the lock itself, and the answer stays on your phone: it is not sent to the server or anyone else. On Android, asking needs the permissions to use biometric and fingerprint hardware, which the app uses for that question only; it never asks for your fingerprint or your face.

Who else is involved

Almost nobody. There are no third-party services other than Apple’s and Google’s notification systems and Expo’s push service, described above; YouTube, only if you turn on link previews, described above; Apple and Google checking that the app may open invite links, described above; the company hosting the relay server; and Cloudflare, which stores the encrypted nightly backup and cannot read any of it. No data is sold, or given to anyone for their own use.

Your choices

Contact

Contact the person who invited you, who runs the server, or email support@tlbmiss.com.