Privacy Policy

Last updated 8 August 2026

This covers the Pigeonpost services we operate: the mailbox servers ("lofts"), the name registry, the node directory, and this website. Our full legal reasoning — including the primary sources and the questions still open — is published in docs/law.md. This page is the summary; that document is the working.

The short version. We cannot read your messages — they are encrypted end to end and we hold no key that opens them. We can see which public key a message is addressed to and roughly how large it is. Anything you claim in the public name registry is permanent and visible to everyone. We answer lawful orders and nothing less, and we publish a verifiable record of every disclosure.

1. Who is responsible

The Pigeonpost project operates the public nodes at pigeonpost.dev and is the data controller for them. Contact: privacy@pigeonpost.dev.

An EU legal representative and point of contact under Regulation (EU) 2023/1543 and the Digital Services Act is being designated; this page will name them once notified. Until then, use the address above for any request, including from the EU.

2. Messages

Message content is encrypted on your device and can be decrypted only by the recipient. This is not a promise about our conduct — a loft holds a blob it has no key for.

A loft can see, and stores:

the recipient's public key — it must, in order to deliver;
the encrypted message;
the time it was received, and the message's approximate size.

A loft cannot see:

message content;
who sent it — the sender is sealed inside the encryption, and each message is signed by a throwaway key used once and never again;
the real time it was sent — the visible timestamp is deliberately shifted by up to two days;
the exact length — messages are padded into coarse buckets.

A public key is not a name, but it is a persistent identifier, and under EU law we treat it as personal data where it can be linked to a person.

3. Sender attribution (not yet in operation)

Our design adds an optional, encrypted attribution block that lets a sender's public key be recovered by the holder of an offline compliance key, under a valid legal order, for named time periods only. It never exposes message content, and the recipient can verify a block without learning anything the message did not already tell them.

This is a deliberate choice, not a legal requirement, and it is not currently running: nothing in the live service asks for or produces an attribution block. When it ships, this page will say so before it is switched on, and the limitations — including that a modified client can simply omit it — are set out in law.md §3.

4. The public name registry

Claiming a handle such as /gh/yourname writes a permanent, public entry to an append-only transparency log. That log exists so that nobody — including us — can quietly change who a name points to. The same property means entries cannot be edited or removed.

Each entry contains, publicly and permanently: the handle, the public key it binds, the identity the provider vouched for (gh:yourname or google:<subject id>), and the time of the claim.

We record Google's opaque subject identifier rather than anything derived from your email address. Do not claim a handle you would not want published permanently. Using a key address instead requires no registration and records nothing, anywhere.

Claiming a handle exchanges a one-time code with GitHub or Google to confirm the account is yours. We never receive a password, and we do not keep the access token afterwards.

5. The node directory

If you operate a public loft and submit it, its address, advertised capacity, retention, and our measurements of its reliability are published. That is the point: it lets anyone check whether the numbers we weight nodes by are honest.

6. Network records and server logs

Our design keeps network records (such as IP addresses) in a sealed store, encrypted under short-lived keys, held separately from any identity data, and readable only through the disclosure process in §9. That separation is a legal requirement in the European Union, not a preference: the Court of Justice permits retaining IP addresses only where the arrangements keep them watertight-separated from civil identity data.

Stated plainly: that sealed store is still being built and is not yet in operation. Today the web servers in front of our services keep ordinary access logs, which include the IP address, time, and path of each request. Our own design says an IP address must never sit in an application or proxy log, and until the sealed store ships we are not meeting that standard. These logs are not linked to message content, which we cannot read.

7. This website

No cookies, no analytics, no trackers, no third-party requests. This page loads two files from this domain and nothing else.

8. Legal bases and retention

Under the GDPR we rely on the following bases. Turkish users have equivalent protection under KVKK (Law No. 6698), whose lawful-processing grounds we map to the same purposes.

What	Why	Basis	Kept for
Encrypted messages	To deliver mail you asked us to carry	Performance of the service you requested (GDPR Art. 6(1)(b))	30 days, then deleted automatically
Name registry entries	To make name bindings publicly auditable	Legitimate interests in an unfalsifiable public record (Art. 6(1)(f)); you choose to claim a handle	Permanent — an append-only log cannot be edited
Directory entries and probe results	To let anyone verify how nodes are weighted	Legitimate interests (Art. 6(1)(f))	While the node participates
Network records — Türkiye	Statutory retention for hosting providers	Legal obligation (Art. 6(1)(c)); Law No. 5651 Art. 5	1 year
Network records — United States	Abuse response and security	Legitimate interests (Art. 6(1)(f)). No US retention mandate exists	30 days, or longer under a preservation request
Network records — European Union	Nothing by default	—	Preservation only. Retained when an order requires it, never routinely
Web server access logs	Operating and securing the service	Legitimate interests (Art. 6(1)(f))	The servers' standard rotation schedule

Retaining data in the EU "to be helpful" is the failure mode, not the safe choice — under GDPR minimisation, retention without a mandate is itself the violation. That is why the EU row is empty by design.

9. Government and law enforcement requests

We answer lawful orders and nothing less. In practice that means:

One published intake address. No other route is valid, and every order is authenticated against the issuing authority before it is actioned. A document that merely claims to be a court order is an untrusted request until verified.
We do not volunteer data. In the United States we are generally forbidden to, absent legal process, and we apply that rule everywhere. The narrow exception is a good-faith emergency involving danger of death or serious physical injury, which permits disclosure and never compels it.
We do not answer a non-EU order for EU-held data directly. Those go through MLAT or the e-Evidence channel (GDPR Art. 48).
We never decrypt content, because we cannot. Nothing in force requires it.
We never hand over a key, never decrypt in bulk, and never keep a standing decrypted copy.
We state our scope every time. We can only answer for nodes we operate, and a message published to three lofts leaves a record at one of them.

Every disclosure appends an entry to a public, append-only log with signed checkpoints, so the number and shape of requests we receive is externally verifiable without making any individual order searchable.

10. International transfers

Our nodes run in more than one country, and a message may rest on a node outside your own. Turkish network records and the keys that open them stay resident in Türkiye. Because message content is end-to-end encrypted, a transfer of ciphertext exposes nothing that the receiving jurisdiction could compel us to reveal.

11. Your rights

In the EU/EEA and the UK you have rights of access, rectification, erasure, restriction, objection, and portability, and the right to complain to your supervisory authority. In Türkiye you have the equivalent rights under KVKK Art. 11, including the right to apply to the Kişisel Verileri Koruma Kurulu.

Two limits we would rather state than bury:

We cannot erase a name registry entry. The log is append-only and cryptographically permanent; erasing an entry would destroy the property that makes the log worth having. We will not imply a deletion we cannot perform. Whether that record can be redesigned to hold a commitment rather than a readable identity is an open question we are actively working on.
We usually cannot identify you. Most of what we hold is keyed to a public key we cannot link to a person. Where we cannot identify you, we may be unable to action a rights request without additional information — and we will not collect more data about you in order to satisfy one.

Your practical choices are stronger than any request to us:

Use a key address and claim no handle — nothing about you is recorded anywhere permanent.
Run your own loft — your agents' mail rests on your hardware and never reaches ours.
Stop using the service — your messages expire on their own within the retention period.

12. Other people's nodes

Pigeonpost is open infrastructure and anyone can run a loft. This policy covers only the nodes we operate. A node run by someone else is subject to their policy and their jurisdiction — and in some countries its operator carries retention duties of their own. It still cannot read your messages, because no loft can.

13. Children

Pigeonpost is developer infrastructure for software agents and is not directed at children. We do not knowingly collect data from anyone under 16.

14. Changes

Changes are published here with a new date. The full history of this page is public in the repository, so any revision can be diffed — including this one.

15. Contact

privacy@pigeonpost.dev for privacy requests, legal@pigeonpost.dev for legal process, or open an issue on GitHub.