FEP-4f05: Soft Deletion
ActivityPub Protocol
8
Beiträge
4
Kommentatoren
22
Aufrufe
-
Hi all,
Some discussion regarding NodeBB's handling of soft deleted posts and Discourse's parallel implementation prompted the creation of this FEP, which attempts to describe how the concept of soft deletion can be published without the introduction of new activities—using
as:Deleteas-is and relying on a backreference check for Tombstone in order to signal a soft delete. -
Hi all,
Some discussion regarding NodeBB's handling of soft deleted posts and Discourse's parallel implementation prompted the creation of this FEP, which attempts to describe how the concept of soft deletion can be published without the introduction of new activities—using
as:Deleteas-is and relying on a backreference check for Tombstone in order to signal a soft delete.@Claire, in Feb 2002, you created a topic where you mentioned soft deletes. While this isn't strictly related to
Undo(Delete), this FEP recommends thinking of a receivedDeleteas an instruction to invalidate the cache, and re-fetch, which would give you a better answer as to how to handle the receivedDeleteorUndo(Delete).Perhaps this might help.
-
Hi all,
Some discussion regarding NodeBB's handling of soft deleted posts and Discourse's parallel implementation prompted the creation of this FEP, which attempts to describe how the concept of soft deletion can be published without the introduction of new activities—using
as:Deleteas-is and relying on a backreference check for Tombstone in order to signal a soft delete.>Request the object (via its id) from the origin server directly
Couldn't
Deleteactivity itself indicate the type of operation?For example, if
Deletecontains embeddedTombstone, then treat it as a soft delete. Otherwise, treat it as a hard delete.>The Forums and Threaded Discussions Task Force (ForumWG) has identified a common nomenclature when referring to organized objects in a threaded discussion model.
I find this nomenclature a bit confusing. Commented on the linked issue.
-
>Request the object (via its id) from the origin server directly
Couldn't
Deleteactivity itself indicate the type of operation?For example, if
Deletecontains embeddedTombstone, then treat it as a soft delete. Otherwise, treat it as a hard delete.>The Forums and Threaded Discussions Task Force (ForumWG) has identified a common nomenclature when referring to organized objects in a threaded discussion model.
I find this nomenclature a bit confusing. Commented on the linked issue.
The assumption is that the object is not embedded. If it is, then it stands to reason that the embedded object can be used as is. I'll call it out in that section, thanks.
-
Hi all,
Some discussion regarding NodeBB's handling of soft deleted posts and Discourse's parallel implementation prompted the creation of this FEP, which attempts to describe how the concept of soft deletion can be published without the introduction of new activities—using
as:Deleteas-is and relying on a backreference check for Tombstone in order to signal a soft delete.@rimu@piefed.social I noticed today that PieFed supports the concept of soft deletes:
Perhaps this FEP would be of interest to you.
-
Hi all,
Some discussion regarding NodeBB's handling of soft deleted posts and Discourse's parallel implementation prompted the creation of this FEP, which attempts to describe how the concept of soft deletion can be published without the introduction of new activities—using
as:Deleteas-is and relying on a backreference check for Tombstone in order to signal a soft delete.What would happen if you receive a
Deletefor an object that you believe to have been soft deleted, but now it shows up as an object instead of aTombstone? Like, it was undeleted by the time you receive theDeleteor something?Likewise, you receive an
Undo(Delete)and when you fetch the referenced object, it returns back aTombstoneinstead of the object?It'd be good to document those cases, because I think the answers are:
- If you receive a
Deleteand the object returns an object, not a 410 / 404 orTombstone, then you discard theDelete - If you receive an
Undo(Delete)and the object returns a 404, 410 orTombstone, then you discard theUndo(Delete)
- If you receive a
-
What would happen if you receive a
Deletefor an object that you believe to have been soft deleted, but now it shows up as an object instead of aTombstone? Like, it was undeleted by the time you receive theDeleteor something?Likewise, you receive an
Undo(Delete)and when you fetch the referenced object, it returns back aTombstoneinstead of the object?It'd be good to document those cases, because I think the answers are:
- If you receive a
Deleteand the object returns an object, not a 410 / 404 orTombstone, then you discard theDelete - If you receive an
Undo(Delete)and the object returns a 404, 410 orTombstone, then you discard theUndo(Delete)
Hi Emelia, thanks for the second pair of eyes on this.
I will amend the FEP with those behaviours. It makes sense that no action be taken if the backreference check fails.
Secondly, on re-read of my own FEP it is unclear that a backreference call is to be made, so I will need to make it clearer as well.
- If you receive a
-
Hi Emelia, thanks for the second pair of eyes on this.
I will amend the FEP with those behaviours. It makes sense that no action be taken if the backreference check fails.
Secondly, on re-read of my own FEP it is unclear that a backreference call is to be made, so I will need to make it clearer as well.
I have amended the FEP with an "Unexpected Responses" section.
Of note, it's less so that you discard the activity, but since you already made the request, you may as well go through with what you received back.
So if you get a
Deleteand a backreference shows the object alive and well, then just process it as anUpdateif you so wish.
