Pigeon transparency report
What we could hand over
A pigeon can only drop what it has eaten. This is everything Pigeon's servers hold, and so the most any request could get.
It comes from Pigeon's threat model; the right-hand column names the rows there that argue each claim. It's the same table as our law enforcement guidelines, and if it changes, both change.
| Asked for | What we could hand over | Threat model |
|---|---|---|
| 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. | T02, T07, T25 |
| 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. | T08, T09 |
| Contact lists and address books | Nothing. They stay on the device. | Design |
| Group names, members or sizes | Nothing. Groups exist only on members' devices. | T08 |
| Name, phone number, email, payment details | Nothing. We don't ask for them. An account is a set of public keys. | Design |
| Handle (Pigeon name) to account Planned | Which account's public key a handle points to. Anyone can look that up. | Design |
| 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. A court can order a provider to start recording; if one did, we'd say so here when the law allowed. | T05, T36 |
| 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. | T21, T36 |
| 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”. | T22, T79 |
| 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. | Design |
| Invite codes Planned | That an account is registered for the alpha. We keep no record of who invited whom. | Design |
| Name lookups Planned | Nothing from the past: the directory is designed to keep no lookup log. | T27 |
| Payments Planned | No payment record linked to an account: payment proofs are anonymous. | Design |
| Seed phrases, device keys, passwords | Nothing. We don't receive them; they stay on users' devices. | Design |
Requests to do something, not to hand something over
| Asked to | What we could do |
|---|---|
| Preserve data | Preserve what we hold that the request identifies. Preservation can't capture what we don't hold, and messages are deleted once delivered. |
| Remove a file | Remove the exact upload named, and nothing else. |
| Record data from now on | Nothing from the past. An order like this asks us to start holding something we don't hold today. |
| Change the software or the service | Not data. We'd consider every lawful way to challenge a demand like this. |
- The messages themselves are on people's devices. Whoever holds an unlocked device can read them; Pigeon can't unlock a device or help anyone else to.
- “Planned” means the feature isn't running yet; its row describes how it is designed.
- This table changes only with a change to Pigeon's code, which is public, and a new version here. Every entry points at the version in force when it was received.
A court can order a provider to start recording something it doesn't record today. If that happened to us, this table would change, and we'd say so here when the law allowed.
Versions
Every change to this table is kept. Each request and report points at the version in force on its date.
- Version 1, in force from 22 October 2026: First version, the same table as pigeonmessage.io's law enforcement guidelines, version 1.0.
Version 1 as JSON
SHA-256 6525c4a475b72522312d44f79042ff60e0bdb1a03ddfed23848eebda4df2d7c9