Pastpond — Privacy Policy
Last updated: 2026-10-08. Provisional v0.28.
This describes what personal data Pastpond collects, why, where it lives, and what your rights are.
Pastpond is operated by NATIFY LIMITED, a company incorporated in the Abu Dhabi Global Market (ADGM), registration number 17201. NATIFY LIMITED is the controller of the personal data described here. "We" and "us" mean NATIFY LIMITED.
Read this first: a release changes what we can read
Every statement in this policy about what we cannot read is true until your capsule is released. Your capsule is encrypted on your device with a key derived from your passphrase, we never receive that passphrase or any key derived from it, and we cannot read what you store.
There are two ways a capsule is released, and almost everything below concerns the first. One is a release condition you set, to people you named. The other is a default that applies when you set nothing at all — described under How your capsule is released — and it is the one worth reading carefully, because it is the only route that does not begin with an instruction from you.
A release ends that, for the capsule that is released and for nothing else. When a release condition you set is met, we open that capsule to the people you named, and from that point we are able to read it too. There is no code and no key for anyone to have kept.
That boundary is enforced by our systems, not by mathematics. "Only once the condition is met" is a rule our own code follows. The capsule is opened with a key we hold, so anyone with both that key and access to our database could open it earlier, in breach of that rule. We are telling you this rather than describing it as something arithmetic prevents, because it is not.
We chose it deliberately. The alternative required a code handed to each person while you were still here, kept safe for years, and found again by someone else later. If it was lost, the capsule could never be opened by anyone, including us. Sealed while you are here; readable by the people you chose after.
One qualification on that last line, because two of the three release conditions do not wait for you to be gone. A fixed date and a beneficiary's age can both arrive while you are alive and checking in every day, and when one does, the capsule opens exactly as described above. If you set one of those, you have chosen to open your capsule sooner, and this policy means it. What controls whether we can read a capsule is whether it has been released — not whether you are still checking in.
Nothing above changes anything before a release. A capsule that has not been released stays sealed, and we cannot read it. Note the wording: released, not a condition you set has been met. A capsule for which you configured no plan at all can still be released, by the default described below, and that is why this policy no longer says "a condition you set" anywhere it means "we can read it".
Data we collect
You give us:
- Your email address (for sign-in and notifications).
- Your sign-in method. You can sign in three ways: a one-time link sent to your email, your Google account, or a passkey.
- If you sign in with Google, we receive the email address on your Google account, and the name and a link to its profile photo if your account has them. We keep the link, not the photo: the picture stays with Google, and your browser loads it from there when Pastpond shows it to you. It is shown only to you, never to the people you name, and our server never fetches it. We never receive your Google password.
- If you add a passkey: its public-key credential record — the credential ID, public key, signature counter, transports, device type, and whether it is backed up (synced). This is verification material used only to confirm sign-in; it cannot decrypt your capsule. Your biometrics never leave your device — we never receive them.
- Your profile photo, if you upload one. It is the one picture we hold that is not encrypted, and we can see it. It is shown at the top of every page you open, including on a device where your capsule is still locked, so it cannot be sealed with your key. Before it is stored, our server checks that it is a square no larger than 256 pixels on a side and re-encodes it, and only that re-encoded copy is kept; anything else the original file carried, such as its location or camera details, is not. Uploading a new photo replaces the old one, which is not kept.
- Who sees it: you, on your capsule; and the people you named, once your capsule is released to them — on the page that opens it, and in the email that tells them it is ready. It is the only photo of you they are shown. If you have not uploaded one, they see no photo at all: not the one on your Google account, which our server never fetches.
- Your encryption passphrase (only at the moment of derivation in your browser; we never receive or store it).
- File contents you upload — photos, documents, and letters — encrypted on your device before upload. A photo usually carries embedded metadata of its own — the date it was taken, the camera and lens, and often GPS coordinates. That metadata is part of the file, so it is encrypted with it, and we cannot read it. Your device reads the capture date out of it to place the photo on your timeline, and stores that date encrypted too. Nothing else is taken from it — the location in particular is never extracted, never indexed, and never sent to OpenAI (see AI processing below). It stays inside the file — and so a release that opens the photo opens the coordinates with it.
- Names and email addresses of the beneficiaries you designate, and the release conditions you configure for each. If you set a release to happen at a beneficiary's chosen age, that includes the beneficiary's date of birth.
We collect automatically:
- Check-in timestamps. Using the app records that you were active (at most once every few hours). These "proof of life" timestamps are what the release safeguard reads — see How your capsule is released below.
- Assistant reply counts. How many replies Pastpond's assistant has given you — for each capsule, per day, or in total for an account with no plan — so the limit on replies can be kept. A count is all it holds: nothing of what was asked or answered.
- IP address — recorded by our hosting and infrastructure providers in the server logs described below. It is not stored in the Pastpond database, and we do not use it to profile you.
- Browser/device user-agent string.
- Server logs (retained 30 days).
We do not collect the plaintext of any file you upload while your capsule is sealed, with four exceptions. Three are transient: they pass through our server in memory and are discarded immediately. The first is photo bytes on their way to OpenAI for description (see AI processing below) — with the photo's embedded metadata already removed on your device, before it is sent. The second is the text of a note or a document on its way to OpenAI for the same purpose: the text is read out of the file on your device, and it is the text that is sent, up to a fixed limit, never the file (see AI processing below). The third is a photo you import by connecting a public profile: it is downloaded through our server because your browser cannot read it directly from the source, and it is encrypted on your device before it is stored (see Connecting a public profile below). Nothing is written to disk in plaintext in any of the three. The fourth is not transient: a released capsule. Once a capsule is released — whether by a condition you set or by the default that applies when you set none — we hold the keys to it and can read what it contains, for as long as the capsule exists. See Read this first above and How your capsule is released below. We never receive your passphrase or any key derived from it, and a release does not reach it; the release path opens the capsule by a different route, described below. Your profile photo is not part of your capsule and is outside all of this: it is stored unencrypted, as described above. We run no third-party analytics or advertising trackers, and we do not build a behavioral profile of you.
How we use it
- To run the service: storing your encrypted capsule, charging you, sending transactional emails.
- To operate the release safeguard: recording your check-ins and, if you configure an inactivity-based release, acting on prolonged inactivity exactly as you instructed.
- To carry out a release: once a condition you set is met, opening the released capsule and serving its contents to the people you named. We do this because you instructed it — it is the service you bought.
- To carry out the default for a capsule you configured no plan for: opening it and contributing its contents, stripped of your account identity, to a public repository. This is the one thing in this list you did not instruct, and it is described in full under How your capsule is released. No donation route is in operation today. Those two are the only purposes for which we hold a capsule in readable form on an ongoing basis.
- For security: detecting abuse, fraud, and unauthorized access.
- For legal compliance: responding to lawful requests.
We do not sell or share personal data with third parties for advertising.
AI processing — OpenAI
Photos. When your capsule organizes itself, each photo is decrypted on your device and sent, via our server (held in memory only, never written to disk), to OpenAI, which returns a description and tags.
Only the picture is sent. Before a photo leaves your device it is re-encoded, which removes the metadata a camera or phone writes into the file — GPS coordinates, the camera's serial number, lens and exposure settings, and any name the camera stored. OpenAI receives the image and nothing else. If the re-encoding fails for some reason, the photo is not sent at all rather than sent as it is. Your original file keeps its metadata and stays encrypted in your capsule.
The same path also estimates when a photo was taken, so it can be placed on your timeline. Where a photo carries a capture date, that date is read on your device, from the file's own metadata, and only the resulting date is used — OpenAI is never asked for it. OpenAI is our only AI sub-processor: API data is retained by OpenAI for up to 30 days for abuse monitoring, is not used to train models, and is covered by our data processing agreement. The returned description is encrypted on your device with the same per-item key that protects the photo itself before it is stored — so while your capsule is sealed we cannot read your descriptions afterwards. A release opens them along with the photos they describe.
Notes and documents. The same step reads what you have written. A note, or a document that is a PDF or a plain-text file, is decrypted on your device and its text is read there — the file itself is never sent anywhere to be read. That text, up to the first 12,000 characters (a few pages), goes via our server (held in memory only, never written to disk) to OpenAI, which returns a description and tags and estimates the date it belongs to. This happens when you save a note or add a document, and when you press Organize or ask Pastpond to organize. These are your own words rather than a picture: a letter you save as a note is sent as you wrote it, up to that limit. A document in any other format, and a scanned PDF with no readable text, is not sent at all. The retention is the same as for a photo — up to 30 days at OpenAI for abuse monitoring, and no training on it — and what comes back is encrypted on your device with that item's own key before it is stored, exactly like a photo's description.
Your story. If you ask Pastpond to write a chapter of your story, your device sends a short summary of that chapter: each memory's description and tags — whether Pastpond produced them or you typed them yourself — the dates on your timeline, and the milestone labels you wrote yourself. If you ask for a rewrite, the note you type about what to change is sent with it; it is used for that one request and never stored. Your files, your notes and letters, and your photos themselves are not sent for story writing — only the descriptions already made of them. The prose that comes back is encrypted on your device before it is stored, exactly like a description. Nothing is written unless you ask for it, and nothing reaches the people you chose until you accept it.
Asking Pastpond. The panel beside your capsule answers questions about using Pastpond, and where it can, it does what you ask: it switches the view, opens a page, keeps a note, sets your birth date, organizes your memories or writes your story, each exactly as if you had pressed that button yourself. Your device does it, with your keys, so what it sends anywhere is what that button sends, as described above. It cannot delete or archive anything, pay for anything, change how you sign in, or change who receives your capsule; for those it can only open the page where you would do it yourself. When you send a message, your message goes via our server (held in memory only, never written to disk) to OpenAI, together with up to six of this visit's earlier questions and answers and a line our server writes about where you are: which view is open, how many memories the capsule holds, whether a story has been started, whether you have a plan or can still start a free trial, and whether the capsule is your own or one you keep for someone else. That line holds counts and yes-or-no facts — never the contents of a memory, your profile or your story. The conversation is not stored: not by us, and OpenAI is asked not to store it either; it stays in that tab, across the pages you open there, until you close or reload it, and it is gone then. OpenAI's up-to-30-day retention for abuse monitoring still applies to each request. What we keep is the reply count described under Data we collect, and nothing of what was said. A note you type and save with the pencil is not sent to OpenAI as a question: it is encrypted on your device, like any other note. If instead you ask Pastpond to keep something you wrote as a note, your message has already gone to OpenAI as a question, as described above; the note it keeps is your own words, cut unchanged from that message, and is encrypted on your device like any other. A note you dictate is covered under Speak, next.
Speak. Speak lets you say something instead of typing it. When you press Speak in the panel beside your capsule, Pastpond records from your microphone until you press Stop or Send, for up to five minutes. The recording goes via our server (held in memory only, never written to disk) to OpenAI, which turns it into text on their servers and returns the words. The words land in the box where you type, and from there they are treated exactly like words you typed: if you send them as a question, they reach OpenAI as described under Asking Pastpond; if you save them as a note, the note is encrypted on your device before it is stored, like any other note. The recording itself is never stored — not by us and not in your capsule — and nothing plays it back; the words are not kept by our server on their way back to your screen either. OpenAI's up-to-30-day retention for abuse monitoring applies to each recording, as it does to every request. An audio file you attach is refused rather than kept: Speak is the only way something you say reaches Pastpond, and it arrives as text.
The people you named can read these descriptions once the capsule is released to them, because a release opens the same per-item keys that protect the memories they describe.
While your capsule is sealed, the encrypted-at-rest copy of your file in storage is never decrypted on our infrastructure. After a release it is decrypted there, to serve it to the people you named.
Connecting a public profile — Apify
You can bring memories in by pasting the address of a public social profile. When you do, we ask Apify — a managed fetching service, and our second external processor after OpenAI — to read that profile's public posts and return their addresses and captions to us.
What Apify receives is the profile address and nothing else about you: not your email, not your account, and nothing from your capsule. What they return is a list of public posts, capped at 100 per import. That cap is fixed in our code and is not something you or we can raise from the page; the archive upload stays the route for bringing in more than that.
What we keep. Not the profile address. It is used to make the fetch and is then discarded — what remains on the record is which kind of profile was connected and when it last synced, and nothing that says whose profile it was. There is no encrypted copy either, because there is no copy. Each photo you choose to import is downloaded through our server, because your browser is not permitted to read it directly from the source, and it is encrypted on your device before it is stored. It is held in memory in transit and never written to our disks in plaintext.
Apify's own handling. Apify acts as our processor under a data processing agreement. They do not train AI models on data processed on our behalf, and the result set one of our runs produces is unnamed, which means it expires on their platform after 7 days.
Who can do this at all. Connecting a profile requires a paid plan. An account on a free trial cannot do it, and neither can an account with no plan — so no free or trialling account can cause a transfer to Apify.
Apify performs no AI processing. OpenAI remains our only AI sub-processor.
If someone connected a profile that is yours
This section is for people who never signed up for Pastpond.
Because a pasted profile address needs no proof of ownership, someone may connect a public profile that belongs to you rather than to them. If that happens, we become a controller of the personal data in those public posts, and this is the notice we owe you under Article 14 of the GDPR — published here because Article 14(5)(b) allows a controller to discharge it by making the information publicly available, which is the only route open to us when we have no way to contact you.
Who we are. NATIFY LIMITED, registered in the Abu Dhabi Global Market, registration 17201. Contact: hello@pastpond.com.
What is taken. A public profile address, and up to 100 public posts from it — their images and captions. Nothing private, no messages, and no follower or connection lists.
What is then done with it. Each imported photo is described by OpenAI, which returns a short description and tags that are stored with it. The importing user's browser encrypts the item before it is stored, so we hold ciphertext — until the capsule it was added to is released to the people that user named, at which point we hold the keys to it as well. See Read this first at the top of this policy.
Why we consider ourselves entitled to. Our lawful basis is legitimate interests, Article 6(1)(f) — set out in full in Our legitimate-interests assessment below.
How long it is kept. For as long as the capsule it was added to exists. A capsule is built to outlive the person who made it, so treat this as indefinite.
What we can and cannot do, honestly. We do not keep the profile address at all, and while a capsule is sealed its content is encrypted with keys we do not hold. So we cannot search for you, cannot confirm whether your posts are in one, and cannot delete them on request — not as a matter of policy, but because the one field that would let us find you was never written down.
That limit does not apply to a capsule that has been released. Once a release condition is met we hold the keys to that capsule, so for a released capsule we can search it, confirm whether your posts are in it, and delete an individual item. If you write to us we will do so. The number of released capsules is small and the search is manual, but it is possible, and we would rather say that than repeat a limit we have stopped having.
What you can do. Write to hello@pastpond.com. Where a report is verified we will act on it against the account responsible, under the acceptable-use terms, and — for any capsule that has been released — we will also remove the individual items you identify. For a sealed capsule the account-level route is the only remedy the encryption leaves us, and we will use it. You may also complain to your local data protection authority.
Our legitimate-interests assessment
This is the balancing test behind the Article 6(1)(f) basis named above, written out rather than asserted.
The interest pursued. NATIFY LIMITED has a legitimate interest in giving paying users a durable way to preserve public material that forms part of their own history, and to pass it to the people they choose. The user has a matching interest in keeping that material. The purpose is private preservation — with one exception now on the record, which is that a capsule its owner configured no plan for defaults to publication rather than to erasure. That is a materially different purpose from private preservation and is assessed as such below. Neither purpose is advertising, profiling, data brokerage, or any commercial use of the person in the posts.
Necessity. Providing the feature requires processing the profile address and the posts at it; there is no version of an import that does not. We considered requiring proof that the profile belongs to the person pasting it, and it is not a less intrusive way of achieving the same purpose — it processes the same posts, and it removes a category of legitimate use (material from a shared history published on an account the user does not control) rather than reducing the intrusion. Asking users to download each item and upload it by hand would move the same personal data through the same steps while making the feature unusable. What we do instead is place the obligation on the user, in the terms, not to import another person's posts without a proper basis.
The effect on the person in the posts. Public availability reduces this interest but does not extinguish it. Someone who posts publicly may reasonably expect their posts to be seen and saved. They are less likely to expect them to be imported as a set, described by AI, kept effectively permanently, and eventually shown to people they have never met. They will usually not know it has happened and will not have agreed to it. The weight on this side is increased by five things in particular: a capsule is built to outlast its owner; posts can reveal relationships, locations and circumstances that the person did not think of as sensitive when posting one at a time; the contents may later be released to the people the owner named; that release also makes them readable by us, so the material stops being protected from the controller as well; and a capsule whose owner configures no plan defaults to publication, which would put the same material in front of everyone rather than in front of a named few. The fifth is now the heaviest, and it displaces the fourth, which held that position in the assessment of 2026-09-01. It is also the only one that operates on the owner's silence rather than on their instruction, so the person in the posts is exposed by an omission neither of them made deliberately.
A limitation on rights, stated plainly, and where it stops. We never store the profile address, and while a capsule is sealed the imported items are ciphertext: we cannot search our systems for a named person, and therefore cannot confirm, produce or erase that person's data in response to a request naming them. That counts against us in the balance and we have not discounted it. For a released capsule the limitation lifts only in part — we can search the items it holds, and produce or erase them, but we still hold nothing recording whose profile they came from, so a request that names a person is one we cannot answer by searching for that name. So the rights limitation is narrower than it was, and the intrusion is correspondingly greater: the same event that restores part of the person's remedy is the event that makes their material readable by us.
The safeguards the balance rests on. Connecting a profile requires a paid plan, so no free or trialling account can cause a transfer at all. Each import is capped at 100 posts. Only public posts from a public profile are fetched — never private content, messages, or follower and connection lists. The profile address is not stored at all, which is a safeguard that holds permanently rather than one that ends. The content is stored encrypted for as long as the capsule is sealed; on release it becomes readable by us, and that is a safeguard which ends rather than one which holds — it is counted here as ending. Apify acts under a data processing agreement, trains no model on what it processes for us, and its unnamed result sets expire after 7 days. There is no profiling, no behavioural advertising, no ad tracking, and no sale. Onward disclosure is limited to the two routes named in this policy: a release to the people the owner named, and the donation default for a capsule with no plan — which is a disclosure to the public and is the least containable thing in this assessment, because it is the only one that cannot be withdrawn once made. It is not in operation today; when it is, imported third-party material will be screened before any capsule is published, and a verified report from the person concerned will stop that capsule being published at all. A verified report is in every case acted on against the account responsible.
Conclusion. On balance the processing is justified under Article 6(1)(f), but only for this narrow purpose and only while every safeguard above remains in place. This assessment was redone on 2026-09-07, its own conclusion having made that a precondition: the release arrangements changed again, this time by a ruling that the anonymized-donation default decrypts and publishes rather than merely declining to erase.
The conclusion holds for the private-preservation purpose and is unchanged there. It does not extend to publication, and we are not asserting that it does. Publication to the public repository is a distinct purpose with a distinct balance — the intrusion is categorically greater, it is irreversible, and it rests on the owner's silence rather than on any instruction — and it is not in operation. Before a donation route operates, this section has to be completed for that purpose specifically, with the screening safeguard and the report-stops-publication safeguard named above actually built, and the change notice this policy promises given. Naming the default here without claiming it is already justified is the honest position and is deliberately the one taken.
If the scope, the cap, the retention model, the AI step, the release arrangements, or our ability to act on a report changes materially again, this assessment has to be redone before that change ships.
Cross-connections — optional, off by default
Settings has a "Let Pastpond's AI find connections" switch. It is off by default. When you turn it on, you authorize Pastpond's AI to use facts extracted from your capsule (names, places, dates from descriptions) to suggest possible family or professional connections to you, as those features launch. No suggested connection is ever revealed to another person without your explicit confirmation of that specific connection. Turning the switch off withdraws the authorization going forward. While it is off, nothing in your capsule is used for matching. A released capsule is never used for matching, whichever way you left the switch — nobody can withdraw an authorization on your behalf, so we do not act on one.
How your capsule is released
Pastpond exists to pass your capsule to the people you choose. For each beneficiary you set one release condition:
- A fixed date — the capsule is released to them on that day.
- A beneficiary's age — released when they reach the age you chose (this is why an age-based release stores their date of birth).
- Prolonged inactivity — the check-in safeguard. Because using the app records a check-in, staying active keeps everything private to you. If you configure an inactivity-based release and then stop checking in, we email you a reminder after about 9 months, and after 12 months of silence a further escrow period you set (a year by default) begins, with another notice. Only if that whole window passes with no check-in do we email your designated beneficiaries a link to open the capsule. Any single check-in resets the clock.
A release email delivers a link. Opening that link sends a one-time code to the address you named for that person, and the code is what opens the capsule — so a link on its own, forwarded to anyone else, reaches nothing. There is nothing you had to give them while you were here: no code to keep safe for years and find again later. That is deliberate — a secret that has to survive in a drawer is the most likely way for a capsule to be lost, and when it is lost nobody can help.
If you set no release condition at all, a fourth thing happens instead. The default is not erasure: the capsule is opened and its contents are contributed, stripped of your account identity, to a public repository. It is set out in full in Section 6 of the Terms, and the three points that matter are that nobody is emailed a link, that we can read the capsule from that moment exactly as in a release, and that publication cannot be undone — published material can be copied and cached by people we have no relationship with, so deleting our copy afterwards does not unpublish it. "Anonymized" means we remove what identifies the account; it cannot mean we remove what identifies you from inside your own memories. No donation route is in operation today — this policy is stating the default before one exists, which is what our own change-notice period requires. You can replace the default at any time by naming someone, or end it by deleting your account.
The cost of that choice is stated plainly in Read this first above and is repeated here because this is where it applies. From the moment a capsule is released, we can read it. Until then we cannot. The line between the two is enforced by our systems rather than by encryption: it is a rule our code follows, not something arithmetic makes impossible. A capsule that has not been released stays sealed to us — and note again that the default described in the paragraph above releases a capsule for which no condition was ever set, so "not released" is the test, not "no condition met".
Where your data lives
- Encrypted file contents: Cloudflare R2.
- Your profile photo, if you upload one: Cloudflare R2, unencrypted.
- Database metadata: Supabase.
- Backups: encrypted backups within our providers' infrastructure (Supabase database backups; Cloudflare's replicated storage). A second cloud and a cold-tier archive in a second jurisdiction are planned, not yet live.
- Release key material: the keys that open a released capsule are held separately from the database, so a copy of the database on its own opens nothing.
Sub-processors
Cloudflare, Supabase, Stripe, Resend (transactional email), Vercel, Google (only when you choose to sign in with Google: sign-in, and the photo on your Google account, which your browser loads from Google to show to you alone), OpenAI (describing your photos, notes and documents, timeline placement, story writing, answering the questions you ask in your capsule's panel, and turning a recording you make with Speak into text; photos are sent stripped of their embedded metadata, a note or a document is sent as text and never as the file, recordings are not stored, and the questions and answers are not stored by us and are sent with a request that OpenAI not store them; up to 30-day retention for abuse monitoring, no training on your data), Apify (only when you connect a public profile — see Connecting a public profile above; they receive the profile address and return its public posts, act as our processor under a data processing agreement, do not train models on data processed for us, and the result set their run produces is unnamed and expires after 7 days), Notion (only when you send us a note through the in-app feedback widget — the note you wrote, the page you wrote it from, and your account email are filed as a card on our internal task board; nothing from your capsule is sent).
OpenAI remains our only AI sub-processor. Apify performs no AI processing of any kind.
For a released capsule, our hosting and storage providers (Vercel, Supabase, Cloudflare) additionally process its contents in readable form, because that is what serving the capsule to the people you named requires. They do so as our processors and for no other purpose. No other party in the list above receives a released capsule. A capsule that goes to the donation default would be received by the public rather than by a sub-processor, which is a disclosure rather than a processing arrangement and is why it is described in How your capsule is released instead of here; no such route is in operation today.
Cookies
We use only the essential cookies that keep you signed in and maintain your session. We set no advertising cookies and no third-party tracking cookies.
Your rights
You may have rights to access, correct, delete, export, object to or limit processing of your data, and to file a complaint with your local data protection authority. You can delete your account from Settings at any time. To exercise any other right — including a copy of the personal data we hold on you — email hello@pastpond.com and we will respond within one month.
A copy covers all thirteen of the records we keep about you:
- Your profile (email address; your display name, if you set one; the name and the link to your profile photo, if you signed in with Google; and your profile photo, if you uploaded one).
- Your capsule metadata.
- Your items — the memories themselves, and the descriptions and dates attached to them. These are encrypted while your capsule is sealed; for a released capsule we can produce them in readable form.
- Your beneficiaries, and the release condition you set for each.
- The relations between your capsules, where you have connected one to another.
- Your subscriptions.
- Your payment records — what was charged, when, and for which plan.
- Your AI credit ledger — every grant and every deduction.
- Your registered passkeys — the public-key credential records described above, never your biometrics.
- Your check-in timestamps.
- Your assistant reply counts — numbers only, per capsule per day, or in total for an account with no plan.
- Your release grants — for each person you named, the record that a release was prepared for them and which memories it covers.
- Your release links and their state — whether a link was issued, delivered, opened, or has expired.
We list these individually rather than promising "everything" because a request is answered by a person working from this list, and a category that is not named here is a category that gets missed.
Because we are encrypted client-side, our ability to honor some requests depends on which state your capsule is in. While it is sealed, producing readable copies of your files depends on the passphrase you still control: we cannot decrypt them on demand, though we can confirm what we hold and we can delete it. Once a capsule has been released, that limit no longer applies to it and we can produce its contents in readable form.
Retention
- Active capsule: as long as your storage plan is active.
- Released capsule: for as long as the capsule exists. A release is not undone by your account being closed — the point of a release is that it outlasts you — so a released capsule and the keys that open it survive closure, unless you or the people you named ask us to delete it.
- Donated capsule: indefinitely, and this is the bullet with the honest caveat. Once contents have been contributed to a public repository we can delete our copy on request, but we cannot retrieve copies other people have already taken, and we do not claim to be able to. There is also nobody you named who can ask on your behalf. No donation route is in operation today.
- Check-in timestamps: kept while your account is open, because the release safeguard depends on them.
- Profile photo: until you replace it, remove it, or close your account. A replaced photo is overwritten, not kept.
- Assistant reply counts: a capsule's counts are deleted with that capsule, and every count is deleted when you close your account.
- AI credit ledger: kept for as long as your account is. Deleting a memory — or a whole capsule, which deletes every memory in it — does not remove the ledger entries recording the credits their AI processing spent, because the ledger is append-only accounting — a balance that is the sum of its entries cannot have entries taken out from underneath it. What remains is the accounting entry and nothing else: a number of credits, a reason from a fixed list, and a date. It holds no part of the memory, and the identifier it carries stops resolving to anything once the memory is gone. Closing your account deletes the ledger along with the rest of your data.
- Server logs: 30 days.
- Backups: 90 days after capsule deletion.
- Storage keys awaiting purge: deleting a memory, a capsule, your profile photo or your account places each file's storage key in a service-only queue until storage confirms the file is gone — normally within the hour, and the key is dropped the moment it is. A key is your account's id and the file's random id (for your profile photo, your account's id and the words "profile-photo"), nothing else; it names no file content. A purge that keeps failing keeps its key queued until it succeeds, because dropping it would leave the file behind.
- Send-once records: kept indefinitely, and stored without the address. Every message we send about your capsule or your plan — a check-in reminder, the notice that an escrow has begun, the email that opens a capsule for someone you named and the code that verifies them, a billing notice — is recorded first, and that record is the only thing stopping the same message being sent a second time. Sign-in links and the email that confirms your address are the exception: they are never recorded here, because a second sign-in link for the same address is legitimate and expected, and a sign-in that depended on this table would fail whenever the table did. An account that only ever received sign-in links therefore leaves no send-once record behind at all. Deleting a record when you close your account would not free anything: it would re-arm the message. So we keep it, and we keep it in a form we cannot read or send to — a one-way SHA-256 digest of the destination address, a short reason code, and the dates it was attempted and delivered. Nothing of the message itself is in it. We should be precise about what that does and does not achieve: the table cannot be read out as a list of people, but a digest is not anonymity, and anyone holding both this record and a particular address could test whether that address is in it. This is also the one record we hold about the people you name as beneficiaries who never open an account, and it is why closing your account does not reach it — there is no account of theirs to close either.
Children
Pastpond is not for users under 18. We do not knowingly collect data from minors.
International transfers
Your data may be stored or processed outside your country of residence. We rely on standard contractual clauses and equivalent mechanisms where required.
Changes
We will email you at least 30 days before material changes take effect.
Contact
NATIFY LIMITED, Sky Tower, Shams Abu Dhabi, Al Reem Island, Abu Dhabi, UAE. Registered in the Abu Dhabi Global Market (ADGM), registration 17201.