From 38f7de309452596fcca181f31d5ec5cdb74db2b9 Mon Sep 17 00:00:00 2001 From: devnull Date: Tue, 15 Apr 2025 18:25:21 +0000 Subject: [PATCH] FEP-4f05: Soft Deletion (#553) This FEP describes how implementors should handle two-stage deletion (also known as soft delete and hard delete) when federating between instances. Behaviours are specified for both publishers and receivers. Co-authored-by: Julian Lam Reviewed-on: https://codeberg.org/fediverse/fep/pulls/553 Co-authored-by: devnull Co-committed-by: devnull --- README.md | 1 + fep/4f05/fep-4f05.md | 91 ++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 92 insertions(+) create mode 100644 fep/4f05/fep-4f05.md diff --git a/README.md b/README.md index 477e968..4820bb9 100644 --- a/README.md +++ b/README.md @@ -154,6 +154,7 @@ Do you have ideas to improve the FEP Process? Post your suggestions to the issue | [FEP-5711: Inverse Properties for Collections](./fep/5711/fep-5711.md) | `DRAFT` | [#539](https://codeberg.org/fediverse/fep/issues/539) | 2025-03-24 | - | | [FEP-044f: Consent-respecting quote posts](./fep/044f/fep-044f.md) | `DRAFT` | [#547](https://codeberg.org/fediverse/fep/issues/547) | 2025-04-03 | - | | [FEP-1042: Peer to Peer Fediverse Identities](./fep/1042/fep-1042.md) | `DRAFT` | [#546](https://codeberg.org/fediverse/fep/issues/546) | 2025-04-03 | - | +| [FEP-4f05: Soft Deletion](./fep/4f05/fep-4f05.md) | `DRAFT` | _TBD_ | 2025-04-15 | - | ## License diff --git a/fep/4f05/fep-4f05.md b/fep/4f05/fep-4f05.md new file mode 100644 index 0000000..c51a3b1 --- /dev/null +++ b/fep/4f05/fep-4f05.md @@ -0,0 +1,91 @@ +--- +slug: "4f05" +authors: Julian Lam , Angus McLeod +status: DRAFT +dateReceived: 2025-04-15 +discussionsTo: https://socialhub.activitypub.rocks/t/fep-4f05-soft-deletion +--- +# FEP-4f05: Soft Deletion + + +## Summary + +The standard CRUD (Create, Read, Update, Delete) behaviours specified 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. + +### Assumptions + +[A blog post by kaniini][DeleteSocialHub] advocates for the treatment of copies remote data _as a cache_. From there we derive the following assumptions: + +* data living on the remote server is considered canonical. +* an incoming `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][Nomenclature] when referring to organized objects in a threaded discussion model. + +* this FEP assumes the items in question are objects, although the concept described can apply to contexts as well. + +## Publishers + +### Soft deletion + +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. + +### Hard deletion + +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`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/404) is acceptable, although a [`410 Gone`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/410) 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. + +## Receivers + +When a `Delete` activity is encountered, the `actor` may not match the `attributedTo` of the targeted object. Follow the [origin-based security model][fe34] for verifying authenticity of the received activity. + +Request the object (via its `id`) from the origin server directly, and handle appropriately based on the received response code or object `type`. + +### `Tombstone` + +The local object SHOULD be soft deleted as per the local implementor's standard behaviour. + +### Not a `Tombstone` + +Update the object's local representation if applicable. + +### HTTP 404 or 410 + +The local object SHOULD be hard deleted as per the local implementor's standard behaviour. + +## Additional Considerations + +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. + +## Implementors + +* NodeBB +* Discourse + +## References + +- Christine Lemmer Webber, Jessica Tallon, [ActivityPub][ActivityPub], 2018 +- kaniini, [_The Delete Activity And It's Misconceptions_][DeleteSocialHub], 2019 +- Julian Lam, [ForumWG Nomenclature][Nomenclature], 2024 +- silverpill, [FEP-fe34: Origin-based security model][fe34], 2024 + +[ActivityPub]: https://www.w3.org/TR/activitypub/ +[DeleteSocialHub]: https://socialhub.activitypub.rocks/t/the-delete-activity-and-its-misconceptions/137 +[Nomenclature]: https://github.com/swicg/forums/issues/4 +[fe34]: https://codeberg.org/fediverse/fep/src/branch/main/fep/fe34/fep-fe34.md + +## Copyright + +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.