The standard CRUD (Create, Read, Update, Delete) behaviours in ActivityPub specify a single Delete activity for use in all cases. This is insufficient to describe two-stage deletion, often referred to as “soft” and “hard” deletion.
Not all software implements two-stage deletion, and so the behaviours described here progressively enhance the functionality for those supporting it, while retaining backward compatibility otherwise.
A blog post by kaniini advocates for the treatment of copies of remote data as a cached representation. From there we derive the following assumptions:
Delete activity should be treated as a request to refresh the locally cached copy or delete it otherwise.The Forums and Threaded Discussions Task Force (ForumWG) has identified a common nomenclature when referring to organized objects in a threaded discussion model.
When an object is soft deleted, the object’s ActivityPub representation MUST be updated to Tombstone. Servers SHOULD continue to respond to requests for the object with a 200-level response code; the object continues to exist in-place.
A Delete activity SHOULD be published in order to propagate the soft deletion to other servers.
When an object is hard deleted, the object MUST no longer have an ActivityPub representation. Servers MUST respond to requests for the object with a 400-level response code. A 404 Not Found is acceptable, although a 410 Gone sends a more explicit signal that the object was explicitly removed. Security or privacy considerations may affect your decision to send anything more than a 404.
A Delete activity MUST be published in order to propagate the hard deletion to other servers.
When a Delete activity is encountered, the actor may not match the attributedTo of the targeted object. Follow the origin-based security model for verifying authenticity of the received activity.
Handle the received activity as below based on the received response code or object type. In cases where the object is referenced (not embedded in the activity itself), request the object (via its id) from the origin server directly.
TombstoneThe local object SHOULD be soft deleted as per the local implementor’s standard behaviour.
TombstoneUpdate the object’s local representation if applicable.
The local object SHOULD be hard deleted as per the local implementor’s standard behaviour.
An earlier implementation of two-stage object deletion published an Update(Tombstone), but this approach was deemed superfluous as it signified the same effect as a Delete—to proceed with a cache invalidation and update.
It is safe to assume the majority of ActivityPub-enabled software does not support two-stage object deletion. Publishing a Delete ensures that the intended behaviour of a soft deletion—that the object’s content is no longer visible—is carried through to other servers.
Implementors are free to handle a soft deletion in the way they prefer (e.g. NodeBB will continue to associate the post (object) with the original actor, and simply blank out the content for non-privileged users.) This FEP explicitly does not specify how individual implementors should handle local representations of remote data.
The recipients list of the published Delete activity is outside the scope of this document.
CC0 1.0 Universal (CC0 1.0) Public Domain Dedication
To the extent possible under law, the authors of this Fediverse Enhancement Proposal have waived all copyright and related or neighboring rights to this work.