Can you actually delete your data from a Solid pod?

A file, yes. Your account, no, and we have no erasure workflow anybody could test. The term is not-built in our own lexicon. Nothing here is legal advice.

The good half, and it is not ours

Deletion is a first-class verb in the Solid protocol. A resource in a pod is an HTTP resource, and HTTP has always had DELETE. The Community Solid Server implements it; the specification defines it; we wrote neither. Solid solved storage and access control, and our contribution to the part of this page that works is: we call their library.

Our file interface imports deleteFile and deleteContainer from the Solid client library and issues the request against your pod over an authenticated, key-bound session.

Grade that evidence honestly: it is a code read, not something we performed for you. Deleting a resource needs a signed-in session, so the check available to a reader is the same one we did, read the file, follow the import. If you have a pod, you can do better than us here: delete something and see.

The industry-wide tension, which we did not solve

An append-only ledger and a right to erasure pull in opposite directions. A record's value comes from nobody being able to rewrite it quietly; erasure asks for exactly that rewrite.

This is everyone's problem, not a Solidus invention, and the standard answer is architectural: never put erasable personal data on a ledger at all. What our own record actually contains, key material, timestamps, a version identifier, and no personal fields, verified on one record, not established as systematic.

A pod sidesteps that tension by being ordinary storage. That is the honest reason deletion works here: nothing clever is happening.

Deleting your copy is not un-reading

Access control gates the first read. It does not reach into anything already fetched. An application you granted access to could have retained what it read, and no delete you issue in your own pod touches that copy.

This is the single most over-claimed thing about personal data stores, and we are not going to repeat it. "You can revoke access" means future requests fail. It does not mean the data comes back.

The regulation is alive to this, Article 17(2) asks a controller who made data public to take reasonable steps to inform others holding it. Nothing in a pod automates that, and nothing in our deployment does either.

And the part that is squarely on us: there is no account deletion

You can delete a file. You cannot delete your account.

The users row holds an email address, a password hash and a pod URL. No path for removing it exists in our frontend or our backend, the account section of settings offers sign-out.

The same search style finds the sign-up path in five files. The search works. The deletion path is not there.

That is a real gap, it is ours, and "the protocol supports DELETE" does not cover it.

A trap for anyone checking our backend, which we walked into ourselves

Our own storage layer has a deleteFile function that no route calls. Grep the backend for a DELETE handler and you find none, from which the obvious conclusion is that deletion is unimplemented, and that conclusion is wrong.

The file path does not go through that backend at all. It goes from the browser to the pod, over the Solid protocol. The blob layer is marked in its own comment as an earlier phase, and it has been superseded.

We are naming this because we made the mistake while writing the page, and a reader doing the same check deserves to be told where the live path actually is.

What is already in place, stated so the page is not only absences

This is not nothing:

• Deletion of a resource genuinely works, via a specification and a server with real implementations behind them.
• Personal data is kept off the chain, so the hard case, erasing something immutable, is one we have mostly designed our way out of rather than argued our way around. Checked on one record.
• The pod's own tables sit in an ordinary database, where a delete is a delete. The mechanism is not the obstacle. The missing workflow is.

The path, and what would make this page shorter

Two decisions recorded on 2026-07-31 belong here as well: there is no EU representative and no privacy counsel today, and both were scoped rather than appointed.

The repository contains no backup job for this deployment, and that sentence is scoped to the repository. What an operator retains outside it is not something a code read can settle, and until an erasure workflow says what happens to backups, neither can we.