For the curious
How Pigeon is built
This page is the detailed version. It is written so a careful reader can understand the design — what is locked, what is not, and where we are honest about limits. It is not a recipe for attacking the system. We do not publish packet layouts, key-derivation internals, or operational secrets.
Last updated 25 August 2026 · Closed beta · Operator: Kastia
The short version
Pigeon is a messenger. You install it on a phone or a computer. You sign in. You talk to people. The important part is when the lock is applied: on your device, before the message is sent.
Our servers are a post office for sealed envelopes. They can see that an envelope exists, which conversation it belongs to, roughly how large it is, and when it showed up. They cannot open it. A phone sitting next to you on Bluetooth is the same story: it may pass a sealed envelope along, but it does not get a copy of the letter.
There is one locking engine and two roads. The internet is the usual road. Nearby is the spare road for when that road is gone. The letter is sealed the same way on both.
What we protect — and what we do not claim
Security writing often lists only the good news. Here is the whole table, in plain language.
| Situation | What we designed for |
|---|---|
| Someone watching the internet | They see encrypted traffic. They do not get message text or photos. |
| Someone with our servers (including us, or a court order aimed at us) | They can see accounts, membership, and sealed envelopes. They cannot read private chats, groups, or files. We cannot turn that into plaintext for anyone. |
| A stranger’s Pigeon phone used as a Nearby relay | It can forward a sealed packet. It cannot decrypt it. |
| A radio in the same room | Bluetooth is local. Timing, size, and “a Pigeon user is nearby” can leak. Message bodies still do not. |
| A stolen unlocked phone | If the device is open, the thief can read what the owner could read. Use a device passcode and the in-app lock. |
We are not an anonymity network. We do not claim that Kastia cannot tell which account talked to which chat. We do not claim sealed sender (hiding who sent a message from the server). We do not claim that malware on your phone is something we can defeat. Those are real limits. Naming them is part of the product.
How a message is locked
For one-to-one chats we use the Signal Protocol — the same family of designs used by Signal. Specifically:
- PQXDH to start a session (including a post-quantum hybrid step, so a later break of today’s public-key math is harder to rewind).
- Double Ratchet after that, so each message gets fresh keys. If a device is stolen later, older messages that already left the device stay out of reach. That property is called forward secrecy.
We did not invent a new cipher and hope for the best. We use a widely reviewed protocol through a maintained library. If verification or decryption fails, the message is rejected. There is no “best effort” decrypt that might show garbage or skip a check.
The lock sits above the network. TLS (the padlock in your browser) protects the pipe to our servers. Bluetooth has its own radio layer. Neither of those is the privacy story. Confidentiality is the envelope, not the truck.
There is no release switch that turns this off and sends chats in the clear. If a build cannot lock a private message, it should not send it.
Checking you have the right person
Usernames can be typed wrong. For a careful check, Pigeon supports comparing a safety number and scanning a QR code in person. That binds the person in front of you to the cryptographic identity on their device. Do that before you treat a new contact as fully trusted.
Groups and channels
Groups (families, clubs, a project of up to a few hundred people) use Sender Keys on top of the same pairwise Signal sessions. In English: each member can post, everyone in the group can read, and people outside the group — including us — cannot. Roles decide who can add members. Leaving a group means you should not keep reading new posts; the design is built so membership actually matters.
Channels are for broadcasts: a class, a team, an announcement board. Public posts are signed so readers can tell they came from the channel’s publishers. Private channels are sealed so followers can read them and we still cannot. We store locked copies, not a readable archive.
Photos and files
A picture is not “a message with a JPEG attached in the clear.” On your device, Pigeon encrypts the file first, with a fresh key. Then it uploads the sealed blob. The key that opens the file travels inside the encrypted message to the other person — not as a readable field on the file server.
When the other person downloads the blob, their app decrypts it locally. We cannot generate a thumbnail. Support staff cannot “just preview the image.” If that sounds inconvenient for us, that is the point.
What the server actually holds
To deliver mail and run an account we need some labels. That is normal. It is also the part people skip when they say “encrypted.” Here is what that means for Pigeon:
- We keep: username, display name, optional profile photo, the email or phone used to sign in, device names and public device keys, which chats you belong to, plan limits, and opaque envelopes (ciphertext plus delivery metadata: conversation, size, time).
- We do not keep: private message text, group plaintext, file plaintext, backup passphrases, or a spare copy of your message keys.
Display names, usernames, and profile pictures are visible to people you chat with, like a name on a mailbox. They are not end-to-end encrypted. The letters inside the mailbox are.
Logs follow the same rule. We do not write message bodies into logs. Push payloads do not include the text. If we cannot read it, we should not be printing it either.
Accounts, devices, and sign-in
An account is a person. A device is a phone or computer that person has allowed. Credentials are bound to the device. If a laptop is lost, you can revoke that device from another signed-in copy of Pigeon. We cannot “just log in as you” from our side and dump a chat history — we do not have the keys.
Sign-in uses a short code emailed (or, when enabled, a phone code), or a Google sign-in. When Google is used, we verify a signed identity token from Google. We do not want your Google password, and we do not log those tokens.
A new device starts empty. History does not silently appear on a second computer. If you want history on a new device, you restore a backup you made (next section). That is less magical than some messengers. It is also how we avoid keeping a readable copy “just in case.”
Notifications
Phones need a tap on the shoulder to wake the app. We use the usual vendors (Firebase Cloud Messaging on Android, Apple Push Notification service on iPhone). The payload they see is a generic wake-up: “New message.” Not the sentence you wrote. Not a preview. Not a name if we can avoid turning the notification into a leak.
You can turn notification permission off in the operating system. Delivery still works when you open the app.
Nearby (when the internet is gone)
Nearby is Bluetooth. Range is about a large room, not a city. If other Pigeon users in between also have Nearby on, a message can hop. That can cover a hallway or a dense crowd. It will not find a phone across town by itself, and it is not Apple or Google’s Find My network. Those systems work because millions of strangers’ phones upload encrypted location over the internet. We do not have that crowd, and we are not going to pretend we do.
The spare road uses the same sealed envelopes as the internet road. Relays forward bytes they cannot read. You turn Nearby on when you want it. Turn it off, and the phone stops advertising that it is participating.
Honest local limits still apply: anyone with a radio nearby can observe that Pigeon traffic is happening — timing, rough size, proximity. That is the nature of Bluetooth, not a bug we can advertise away. The body of the message stays sealed.
When the internet returns, a message that went over Nearby can also be sent on the cloud path so devices that were not in the room still get it. Same letter, second road.
Backups and a new device
Optional encrypted backup seals your conversations (and the local copies of messages) with a passphrase you choose. That passphrase is turned into a key on your device; it is not sent to us as a password we could type later. We store a sealed blob. If you forget the passphrase, we cannot reset it. That is harsh. It is also the only honest design if we refuse to hold a spare key.
Linked devices do not auto-sync history in this beta. Restore is something you do on purpose.
A lock on the app itself
Optional Face ID, fingerprint, or Windows Hello can close Pigeon when you leave it. Biometrics stay on the device. They are a door on the app, not a key we keep. They do not replace a strong device passcode.
Limits we will not paper over
- Metadata exists. We can see that accounts and chats exist. We are not a mixnet.
- The endpoint is the weak point. Malware, a shared family computer, or an unlocked screen beats any envelope.
- Nearby is local. No city-wide tracking. No 911 claim. No “find my phone from another country.”
- Calls are not in this version. Messaging, media, groups, and Nearby come first.
- Closed beta. Details will change. If we find a mistake, we would rather fix it than hide it.
Review and what we keep private
We intend a formal independent review before a public store launch. Until then, treat this as a careful beta, not a finished audit badge.
What we are willing to explain in public is the model: proven protocols, encrypt-on-device, blind relay, honest metadata, Nearby as a spare local path.
What we will not publish: wire formats, packet internals, Bluetooth frame layouts, exact key-schedule parameters, server-side query details, or anything that is only useful as a map for abuse. Security is not improved by handing out a blueprint of the locks. It is improved by using boring, reviewed cryptography and by refusing to make exceptions “just this once.”
Questions: [email protected]. Legal wording: privacy policy · terms of use.