Law enforcement guidelines
Pigeon is end-to-end encrypted and asks for no phone number, email or name. For almost any request, the honest answer is that we don't have it. This page says exactly what we do have.
Version 1.0, 22 October 2026. These guidelines describe our practice; they aren't legal advice and don't create rights for anyone.
What we could provide
This table describes Pigeon's servers as they currently work. “Not built” means the feature isn't running.
| Asked for | What we could provide |
|---|---|
| Message content (text, photos, files) | Only encrypted data we can't decrypt, and only while it's still stored. A message is deleted from our servers once the recipient's device confirms it has it. We hold no keys: they stay on users' devices. |
| Who talks to whom | Nothing. A stored message carries no account, sender, recipient or group, and the mailbox addresses it's stored under change over time and aren't derived from anyone's keys. |
| Contact lists and address books | Nothing. They stay on the device. |
| Group names, members or sizes | Nothing. Groups exist only on members' devices. |
| Name, phone number, email, payment details | Nothing. We don't ask for them. An account is a set of public keys. |
| Handle (Pigeon name) to account Not built | Which account's public key a handle points to. Anyone can look that up. |
| IP addresses and connection times | Currently none from the past: our servers don't record visitors' IP addresses. Our hosting provider's own network records are outside our control. |
| Timing and size of stored data | For messages still waiting on a server: the order they arrived and their size band, not linked to any account. |
| Files and photos | Encrypted pieces we can't decrypt, if identified by their exact identifiers, until they expire. We can't search for “a user's files”. |
| Abuse reports | A report someone chose to send us: the messages they selected, the sender's account key and device, and the report's arrival time and IP address. |
| Invite codes Not built | That an account is registered for the alpha. We keep no record of who invited whom. |
| Name lookups Not built | Nothing from the past: the directory is designed to keep no lookup log. |
| Seed phrases, device keys, passwords | Nothing. We don't receive them; they stay on users' devices. |
The messages themselves are on people's devices. Pigeon can't unlock a device or help anyone else to.
The legal process we require
We respond only to valid legal process that is properly served and that names the data it seeks precisely: a handle, or an exact identifier we issued. We review every request and may object to or narrow one that is unclear, too broad or not valid. For requests under US law:
- Basic subscriber records (which for Pigeon means only a handle and its key, if any): a subpoena, court order or warrant.
- Other non-content records: a court order under 18 U.S.C. 2703(d), or a warrant.
- Stored content: a search warrant issued on probable cause. Stored content is encrypted, and we can't decrypt it.
- Preservation (18 U.S.C. 2703(f)): we'll preserve data we hold that the request identifies, for 90 days, extended by 90 more on a renewed request. Preservation can't capture what we don't hold, and messages are deleted once delivered.
- Requests from outside the US: through a mutual legal assistance treaty request or another process recognised by US law. We don't answer a foreign demand made directly to us unless US law allows it and we judge it lawful.
Send legal process to [LEGAL ENTITY NAME], [POSTAL ADDRESS], or by email to legal@pigeonmessage.io where the process may be served that way. We don't accept requests by any other channel, and this address is only for government and legal process.
Emergency requests
US law lets a provider share information voluntarily, without a court order, when it believes in good faith that an emergency involving danger of death or serious physical injury requires it without delay (18 U.S.C. 2702(b)(8) and (c)(4)). Email legal@pigeonmessage.io with “Emergency” in the subject, from an official government address. Tell us who you are, the nature of the emergency, who is at risk, and what you need. We decide each request ourselves. What we could provide is still only what the table above shows.
Telling users
Our policy is to tell a user when someone has asked for their data, unless the law or a court order forbids it, or there's an emergency. If an order forbids notice for a time, we'll notify the user after it ends. Currently we have no way to contact a user outside the app, and in-app notices aren't built, so we may be unable to notify.
No backdoors
We haven't built any way for Pigeon to decrypt messages, and our servers hold no keys that could. We won't build a hidden way in. If we receive a demand to change our software or to start recording what our servers see, we'll consider every lawful way to challenge it, and we'll say so publicly when the law lets us.
A limit we state plainly: currently, users have no technical way to detect it if we were forced to send one person a modified app or add a hidden device to their account. Protections against that (verifiable builds and a public key log) are planned, not built.
Transparency
We publish the requests we receive, as far as the law allows, in our transparency report.