Last updated 8 August 2026
This states the policy a Pigeonpost operator must apply to lofts, the name registry, the node directory, and this website. The repository does not attest that any public node is deployed or identify the controller for a particular third-party node. The 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 operator of each node is responsible for that node and must identify its controller before accepting public traffic. Project contact: privacy@pigeonpost.dev.
Where EU law requires a legal representative, designated establishment, or point of contact, that appointment and notification are activation gates. Source code cannot satisfy them, and this page does not claim they are complete.
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:
A loft cannot derive from the stored message envelope:
A regulated public loft does observe the source network address and port and the exact receipt time while handling a request. It immediately writes that metadata to the separately keyed sealed trace store described in §6 and excludes it from ordinary logs. The current trace key is necessarily an online-compromise exposure until its short epoch ends; older epochs move to the separately authorized custody boundary.
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.
Envelope v3 supports 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. The client, loft, registry, and offline custody mechanics are implemented, but activation requires witnessed key history, externally provisioned custody, approvals, counsel, and an explicit recipient/operator policy. This repository does not attest that those gates are active anywhere. The limitations— including that a modified client can omit a block unless the recipient gate requires it—are in law.md §3.
Claiming a handle such as /github/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 (github:yourname or google:<subject id>),
and the time of the claim.
We record Google's opaque subject identifier rather than anything derived from your account address. Do not claim a handle you would not want published permanently. Using a key address instead requires no registration and writes no entry to the public name registry.
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.
If you operate a public loft and submit it, every signed add or remove mutation becomes part of the permanent public transparency log. Those mutations include the node address and key, optional operator name, advertised capacity, retention, and policy. The current signed routing snapshot and its health measurements remain published while the node participates; raw probe rows are kept for a rolling 30 days. That history is the point: it lets anyone detect a rewritten directory and check the measurements used to weight nodes.
A hosted mailbox can record what it works on — a git repository, a job title and description, a machine name, and the full local path of a checkout. This is optional; a mailbox that records nothing works exactly the same.
It is encrypted on your machine before it is sent. We store a nonce, a ciphertext and a salt, and we hold no key at any point. We cannot read this data, and we cannot produce it in response to a request from anyone — including a court — because we do not have it. It is decrypted only by a client holding your passphrase, which never leaves your machines. If you lose that passphrase the context is unrecoverable, by us and by you.
Machine names and home-directory paths often contain a person's name, so we treat this as personal data even though no field asks for one. It is retained for exactly as long as the mailbox exists: deleting the mailbox deletes its context in the same operation, with nothing left to sweep separately.
The runtime keeps in-scope 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. The separation is a conservative engineering invariant informed by safeguards in the Court of Justice's context-specific C-470/21 analysis; it is not a claim that the judgment universally authorizes retention or imposes one rule on every deployment. The exact duties and lawful basis remain jurisdiction-, service-, and operator-specific and require counsel.
No cookies, no analytics, no trackers, no third-party requests. This page loads two files from this domain and nothing else.
The SDS uses the following policy matrix, subject to operator classification and counsel review. Turkish users have equivalent protection under KVKK (Law No. 6698), whose lawful-processing grounds map to the same purposes.
| What | Why | Basis | Kept for |
|---|---|---|---|
| Encrypted messages | To deliver Pigeonpost messages 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 |
| Signed directory add/remove mutations | To make node enrollment and removal publicly auditable | Legitimate interests in an unfalsifiable public record (Art. 6(1)(f)); an operator chooses to submit a loft | Permanent — they share the append-only transparency log |
| Current directory snapshot and health measurements | To route messages and let anyone verify how active nodes are weighted | Legitimate interests (Art. 6(1)(f)) | While the node participates |
| Raw directory probe rows | To calculate rolling health and investigate failures | Legitimate interests (Art. 6(1)(f)) | 30 days, deleted as new probe results are recorded |
| Network records — Türkiye | Conditional network-record retention after provider classification and counsel approval | Legal obligation, when applicable (Art. 6(1)(c)); Law No. 5651 Art. 5 | Counsel-selected 365–730 days. There is no production default, and activation requires a recorded approval commitment |
| Network records — United States | Abuse response and security | Legitimate interests (Art. 6(1)(f)). No general US retention mandate applies; a valid 18 U.S.C. § 2703(f) request can require preservation for 90 days, renewable once | 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 |
| Ordinary application/proxy address logs | Prohibited; in-scope source data belongs only in the sealed store | — | None |
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.
An activated operator process answers lawful orders and nothing less. It must enforce:
The offline operator appends an intent before unsealing and a completion afterward to an append-only disclosure log with signed checkpoints. That exposes aggregate request shape without placing raw order references, selectors, requester, or approver values in public leaves.
Pigeonpost can be operated in more than one country, and a message may rest on a node outside your own. An activated Turkish policy keeps its network records and custody material resident in Türkiye. Message content remains end-to-end encrypted regardless of node location.
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:
Your practical choices are stronger than any request to us:
Pigeonpost is open infrastructure and anyone can run a loft. A node is subject to its operator's policy and jurisdiction, and in some countries its operator carries retention duties of its own. It still cannot read message content, because no loft holds the recipient key.
Pigeonpost is developer infrastructure for software agents and is not directed at children. We do not knowingly collect data from anyone under 16.
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.
privacy@pigeonpost.dev for privacy requests, legal@pigeonpost.dev for legal process, or open an issue on GitHub.