Law Enforcement Guidelines

This page is for law enforcement and other government agencies seeking information about a Peachy account. It explains where to send legal process, what each kind of process reaches, and — more usefully — what we do not hold and therefore cannot produce at any level.

It is not legal advice and it does not waive any objection. Nothing on this page is a commitment to produce anything without valid legal process.

Who you are dealing with

Peachy is a very small operation. There is no legal department, no outside counsel on retainer and no ticketing system behind the address below — the mail reaches one person, who reads it. We say this first because it sets realistic expectations about response times, and because it means we cannot pretend to an internal review process we do not have.

If your process must be served on a named entity or a registered agent, write to the address below before serving and we will tell you where to serve it.

Where to send legal process

Email support@pchy.app with Legal process at the start of the subject line. Send it from an official government email address, and attach the signed process as a PDF. This is a mail alias that lands in a person’s inbox; it is not a portal and there is no case number to quote back.

We will acknowledge receipt. We cannot commit to a turnaround time: one person reading mail is the whole of the process, and a request that arrives on a Friday may be read on a Monday.

Identifying an account

Give us a phone number in E.164 format (for example +14155550123) or a @handle. Those are the two things that address an account. Internally an account has an opaque identifier that is never shown to anyone, including its owner, so quoting one to us is not possible and not necessary.

We cannot identify an account from an IP address, because we hold none (below). We cannot identify one reliably from a display name either: in Peachy the name you see for somebody is drawn from your own address book where you have one, so a display name is a property of the person looking rather than of the account. An account may have an email address on it, but it is optional and most do not.

Please also state the date range you are asking about and which categories of record you are seeking. A request for “all records” with no date range is one we will ask you to narrow.

What each kind of process reaches

We treat content as requiring a search warrant or its equivalent. Subscriber records and non-content records we will produce on a subpoena or court order valid in a jurisdiction that reaches us. For requests originating outside the United States, a mutual legal assistance treaty request or letter rogatory is the ordinary route.

Subpoena

Basic subscriber information, where it exists:

• The phone number on the account.
• The @handle, and the profile name, photo and email address if one was given.
• When the account was created.
• The devices registered to the account — platform, the browser’s user-agent string where there is one, when each was registered, and whether it is still signed in.
• When each session was last used, to the day. We record the day and not the time: that field used to be written at full resolution on every request, which made it a minute-by-minute record of when a person’s devices were in use, and it no longer is. A session idle for 90 days is deleted.

There is no billing record, no payment instrument and no alternate email of record, because Peachy charges for nothing and has no passwords. There are no IP addresses or connection logs at any level of process; see below.

Court order

The above, plus non-content records, within whatever retention window still holds them:

• Which conversations an account is a member of, and when it joined or left each.
• Message metadata — that a message passed between the members of a conversation at a given time, and its size. This is available for sealed conversations too, because it is the part encryption does not cover.
• Which accounts follow, or are followed by, the account.
• Notification triage records less than 30 days old: one line per notification routed, naming the sender, the verdict and an excerpt of the message it was a verdict about.
• Records of assistant runs less than 30 days old — what was asked, what the assistant did step by step, and how it came out.
• Push notification token registrations per device.

Search warrant

The above, plus the content we are able to read:

• Messages in public rooms, organisation rooms and the commons, and Slices posts, comments and reactions.
• The account’s conversation with the Peachy assistant, both halves — what was asked and what was answered.
• Photos, videos and files attached on any of those readable surfaces.
• Every place the account shared, anywhere, including inside an encrypted conversation, at the precision it was picked.
• The address book the account synced: phone numbers in the clear, plus the private name saved for each number that already belongs to a Peachy account.
• Private messages that predate encryption, or that could not be encrypted. See below.

What we cannot produce

• The contents of a sealed private conversation. Since 17 September 2026 every direct message and private group chat is end-to-end encrypted with MLS (RFC 9420). The keys are on the devices in the conversation. We hold a ciphertext and have never held a key, so an order for those messages can be answered only with bytes that nobody at Peachy can open. This is a limit on us, not a policy of ours — a policy could be changed by the people who wrote it.
• Photos, videos and files sent inside a sealed conversation. Since 18 September 2026 each one is encrypted on the sending device with its own key, and the key travels inside the sealed message. What we store is a blob and its byte size. The existence and size of an attachment are producible; its contents are not.
• IP addresses and connection records. We do not log the address a request came from: not in the application, not in the request log, not against an account or a session, and the log pipeline masks anything IP-shaped before a line is written. A request asking which addresses an account connected from, or which account connected from a given address, cannot be answered and cannot be reconstructed.
• Passwords. There are none. Sign-in is a one-time code sent to the phone number.
• Payment or financial records. Peachy charges for nothing.
• Continuous location. We hold the places a person chose to share in a message or a post. There is no location history, no background tracking and no stored trail. The approximate position a device sends along with a place search is used to answer the search and written to no table.
• Advertising identifiers or third-party analytics profiles. There are none.
• Anything already deleted. See the next section.

Two things people assume are protected and are not. The first is the metadata of an encrypted conversation: who its members are, when they wrote, how often, and the existence and size of anything they attached are all readable by us and producible. Encryption in Peachy hides content and does not hide who talked to whom. The second is private messages written before 17 September 2026: encryption is not retroactive, and as of 18 September 2026 our database holds 918 such message rows in plaintext. They are readable by us and producible under a warrant.

Retention, and preservation requests

Several categories delete themselves on a schedule, and the sweeps do not pause for a request:

• Server logs: 14 days. Nothing older exists to preserve.
• The encrypted delivery record of a conversation: eight weeks. The envelopes age out. They were never readable by us in any case.
• Unrated notification-triage records and assistant run records: 30 days. A rated triage record keeps its row past that and loses the words it was a verdict about.
• Usage counts: 180 days. Which screens were opened, not what was on them.
• Sign-in codes: deleted a day after they expire. A code itself is valid for ten minutes.
• Sessions idle for 90 days are deleted, and with them the record that the device existed.

Everything else — profile, contacts, readable messages, places, posts — is kept until the person deletes it or deletes their account, at which point it goes immediately. There is no grace period and no undo.

One honest qualification on “immediately”, since it is the kind of sentence a reader of this page will test. Our database is hosted, and the hosting provider takes its own backups on its own schedule as part of running the service. We do not operate a per-account restore, we have never restored one, and we could not extract a single deleted account’s data from a provider backup to answer a request. What we can say is that deletion removes the data from the live system and that nothing in our own process brings it back.

We can honour a preservation request, and we have never done one. Say plainly which account and which categories you want held, and for how long. It would be carried out by hand, by a person, because there is no preservation tooling; we would rather tell you that than imply a button exists. A preservation request cannot recover anything a retention sweep has already deleted, and it does not stop the account’s owner deleting their own data.

Notice to the person

We will tell the person whose data you asked for. Our default is to notify them before producing anything, and to give them the request, so that they have an opportunity to object.

The exceptions are the usual ones, and we hold ourselves to them narrowly:

• Where a court order or statute prohibits notice, we will not give it — and we will give it as soon as the prohibition lapses, including after a non-disclosure order expires. We will not treat an indefinite request for confidentiality that carries no legal force as a prohibition.
• Where we believe notice would create a risk of death or serious physical injury to a person, or where the account is being used to harm a child.

Emergency requests

If there is an imminent risk of death or serious physical injury, email the address above with Emergency disclosure at the start of the subject line, from an official government address, and include: the nature of the emergency, the identity of the person at risk, the account identifier you are asking about, exactly what information you need and why it cannot wait for legal process, and a telephone number we can call back.

We do not operate a 24/7 rota. There is one person. If your matter cannot survive the possibility of a delay of hours, you should pursue other avenues alongside writing to us rather than instead of it. We would rather say this than let a page imply a hotline.

Costs and testimony

We do not charge for responding. We can provide a signed declaration describing how records were produced and that they are kept in the ordinary course; there is no designated custodian of records and no standing arrangement for live testimony.

Requests received

None. As of 18 September 2026 we have received no subpoena, no court order, no warrant, no emergency disclosure request, no national security process and no government content-removal request, and we have produced no user data to any government, anywhere.

That is a person saying so, not a system reporting it: no automated test checks it, and none could. It is answerable by one person because Peachy has no separate legal department such a request could have gone to instead. The count is published in our transparency report and will be updated there whether or not it stays at zero. If we are ever legally prevented from stating a count, we will say that rather than say zero.

Related

Transparency report — what we hold, what we could be made to hand over, and what changed. Privacy Policy — what we collect and why. Security — reporting a vulnerability.