\"Pay once, stored forever\" and the right to erasure are in direct tension

One product promises your data outlives your relationship with any company. One regulation promises a person can require their data be deleted. Both are reasonable. They cannot both be fully true of the same bytes.

Nothing here is legal advice.

The offer, stated fairly

Perpetual storage is a real product with a real economic argument behind it. You pay once, the payment endows the storage, and the data persists without anyone renewing a subscription. Against renting space by the month from a company that might change its prices or its mind, that is a genuine differentiator, and the products selling it are not pretending otherwise.

For a great many things it is exactly right. Public datasets. Software releases. Scientific records that should survive the institution that produced them. Anything whose value comes from still being there in twenty years.

The collision

Permanence is achieved by making deletion structurally hard. Distribute the shares widely, pay the network to keep them, remove any single party's ability to withdraw the data, and you have durability that does not depend on goodwill.

Every one of those properties is also a barrier to erasure. There is no operator with both the authority and the ability to remove a copy, which is the same sentence read from the other side.

A right to erasure assumes somebody can be compelled to act. Perpetual storage is engineered so that nobody can.

Why this is not a gotcha

Nothing above says any product is breaking any rule. Whether a specific deployment satisfies a specific regulation depends on what data it holds, whose it is, where the parties are, and what lawful basis applies. Those are facts this page does not have, and a page that implied otherwise would be doing the thing this estate exists to avoid.

The tension is structural and it belongs to the whole industry. It shows up in append-only ledgers too, for the same reason: the property that makes the record trustworthy is the property that makes it unremovable.

The answer the field has converged on

Keep erasable personal data out of the permanent layer.

Put the durable thing on the permanent layer, a hash, a commitment, a public dataset with no personal data in it. Put the personal data somewhere a delete is a delete, and bind the two with a reference rather than a copy.

That is not a clever trick. It is an admission that the two requirements cannot be satisfied by one storage system, and the design work is deciding which bytes go where. Getting it wrong is expensive in a specific way: once personal data is on the permanent layer, no later policy fixes it.

Where we sit

Pod's content lives in an ordinary database and filesystem. A delete is a delete, and a file can be removed through the Solid protocol, which is a first-class verb there and not our work.

So we do not have this problem, and the reason is not foresight. We have not built a permanent layer, so nothing of ours can strand personal data on one.

What we do have is no account-deletion path at all, verified against a control that finds the sign-up path in five files. A product that cannot delete an account has an erasure problem of its own, and it is a duller one than the interesting problem on this page.

What a buyer should ask

Ask any storage vendor, including us, three things. Which layer holds personal data. What happens when somebody asks for it to be removed. And who has both the authority and the technical ability to act on that request.

A vendor that answers the third with a name has thought about it. A vendor that answers it with an architecture diagram has not.