Field Notes

concept

Advisory deletion

StatusStableUpdatedStands on4 sourcesSupportsnotes

Deletion is advisory when a system can ask the parties holding a copy of something to remove it, but cannot compel them. The user performs what looks like an operation on their data; what actually happens is that a request propagates, and each recipient decides independently whether to honor it. Compliance is then a property of the other party’s software and intentions, not of the protocol.

The distinction that matters is not whether deletion is reliable — almost nothing is perfectly reliable — but whether the system’s guarantee is removal or notification. A database DELETE against storage you control is the first. Everything that crosses a trust boundary tends toward the second.

Where the property comes from

Any system that hands a copy of data to a party it does not control has already lost the ability to erase it. Replication is the usual route, and it is normally deliberate: the same copying that provides availability, censorship resistance, offline reading, and independent verification is what puts copies beyond reach.

The trade is direct. A system that can reliably delete is one in which some party has authority over every copy, which is the same authority needed to censor. Distributing that authority to make censorship hard distributes it far enough to make erasure hard by the same mechanism. Any design that claims both is either centralizing something or relying on participants’ goodwill.

The request is more durable than the deletion

Specifications in this family converge on a recognizable shape, and they are candid about it.

Nostr’s NIP-09 is titled “Event Deletion Request”. Relays should stop publishing referenced events, and clients may tell the user that the request guarantees nothing because removing an event from every relay and client is impossible. It also instructs relays to keep republishing the deletion request itself indefinitely, since clients that already hold the target event need to learn about it.1

That last detail generalizes into something counterintuitive: the tombstone frequently outlives the thing it buries. A retraction has to be as widely and as permanently distributed as the material it retracts, or later arrivals will never see it, so the durable record ends up being the record of the attempt. Where the deleted item was sensitive, this converts a private removal into a public, permanent signal that something at a given position was withdrawn.

Matrix redactions behave the same way. A redaction strips an event’s content while the event’s place in the room graph remains, because other events authenticate against it. Whether a given homeserver honors the redaction, or later serves the unredacted original to a server backfilling history, is that operator’s choice.

ActivityPub delivers a Delete activity to the servers it knows about. Servers that received a copy by another route, or that decline to act, keep theirs.

AT Protocol propagates deletion through the account lifecycle, and its own guidance notes that downstream systems which do not follow the protocol may retain records.

Degrees, not a binary

Treating this as on-or-off loses the distinctions that decide how much a deletion is worth.

Degree What the system can promise Example
Enforced Every copy is under one authority that removes it A single-operator service deleting its own storage
Enforced at the boundary Removal where the operator controls storage; nothing beyond it A platform deleting a post that was already screenshotted
Propagated A conforming implementation removes on receipt; non-conforming ones are unconstrained ActivityPub Delete, AT Protocol lifecycle
Requested The protocol defines the ask and explicitly disclaims the outcome Nostr NIP-09, Matrix redactions
Impossible The data structure forbids removal Append-only signed feeds; auth-chain events in a Matrix room

The ladder is not the same as trustworthiness. A propagated deletion among a handful of well-run servers may remove more copies in practice than an enforced deletion at a platform whose data was already sold to brokers. The question to ask is who holds a copy, not what the protocol calls the operation.

The one thing that does work

Crypto-shredding is the exception, and it is the reason encrypted systems can offer something stronger. If ciphertext is distributed but the key is not, destroying the key makes every copy permanently unreadable without needing any copy-holder’s cooperation. This is what forward secrecy buys at the session level, and what disappearing messages approximate at the application level.

It moves the problem rather than removing it. The guarantee now rests on the key never having been extracted, on every endpoint that decrypted the content not having retained the plaintext, and on the key material actually being destroyed rather than merely dereferenced. An endpoint that saved a decrypted copy is a copy-holder like any other.

The law arrives at the same structure from the other direction. EU and Swedish data removal rights records that GDPR gives a person enforceable rights against each controller separately, not a command that makes information disappear; a controller that made data public owes only reasonable steps to inform other controllers. Reasonable steps to inform is precisely an advisory deletion, written as an obligation rather than a protocol message.

This is why removal services can be honest about their reach and still be worth buying. DeleteMe and Incogni submit requests to brokers, and Redact.dev drives platform deletion interfaces; none can reach a copy the recipient declines to remove or never disclosed holding.

Designing against it

The property is not a defect to be fixed at the protocol layer, because fixing it means centralizing the authority the design gave away on purpose. It is a constraint that belongs upstream, in what gets published at all.

  • Treat publication as irreversible when the audience is untrusted, and size the disclosure accordingly. Data minimization is the operative control, because the cheapest copy to delete is the one never distributed.
  • Say which degree the interface actually offers. A “delete” button over a requested deletion is a false affordance, and users calibrate risk against the affordance.
  • Prefer key destruction where confidentiality is the goal and the content can be encrypted end to end.
  • Expect the retraction to be public and durable, and design so that a withdrawal does not itself disclose what was withdrawn.

  1. NIP-09, “Event Deletion Request” uses SHOULD for relay and client compliance throughout, instructs relays to continue republishing deletion requests indefinitely because clients may already hold the target event, and states that clients may inform the user that deletion is not guaranteed because removing events from all relays and clients is impossible. ↩

Built on 4 sources (4 external).

Working out connections…