Deleting a post vs deleting an entire comment tree

For context:

• Two big threadiverse implementors (and probably mbin) currently federate Announce(Delete(Object)) for deletion of content — all synchronized communities follow suit and delete the content as well.
• If that object is the root-level node, and it is deleted, everything below it is also deleted.
• Lemmy and Piefed are investigating the possibility of changing this behaviour so that the action deletes the object itself only, and the reply tree stays.

We're in the middle of discussing how best to communicate this. With Delete(Object) behaviour shifting to deleting the single object only, there are two options to delete the entire tree/thread:

1. Delete(Object) with a new property with_replies or similar
2. Remove(Context), where Context is a new url that refers to the entire tree

Thoughts? We're discussing this tomorrow at ForumWG but it'd be nice to get some eyes on it beforehand.

cc @rimu@piefed.social @nutomic@lemmy.ml @melroy@kbin.melroy.org @bentigorlich@gehirneimer.de

@julian said in Deleting a post vs deleting an entire comment tree:
> If that object is the root-level node, and it is deleted, everything below it is also deleted.

Why would everything below be deleted? Would it not simply become orphaned?

I've got a PR for removing an entire comment thread for Lemmy mostly ready, I just need to write the tests and decide on how this exact problem should work, so the timing is honestly impeccable. The things I've been debating between are:

1. Same as option 1, a new property like removeChildren;
2. Make the target of the Delete an array. I'm honestly 50/50 on whether this is actually spec compliant, it's not clear to me that it isn't;
3. Just sending out an individual Delete for every Object. I like this option the least, but it is very easy to implement and needs no changes in other software to work.

@thisismissem not even orphaned, a delete leaves behind a tombstone object which should still be dereferenceable from anywhere else.

If that object is the root-level node, and it is deleted, everything below it is also deleted.

This is not exactly true. When Lemmy receives Delete/Object for a (top level) post, it only marks the post itself as deleted. The replies are not marked as deleted in the database, but are (currently) hidden in the UI. For 1.0 this behaviour is already changed in the API and UI so that deleted posts are removed from listings, but accessible by direct link so that comments can be viewed. This doesnt involve any change to federation and is an implementation detail.

Adding a new activity type for each such implementation detail is not feasible, and we cannot support all of them. So to maximize compatibility you should definitely keep using Delete(Object), and add a new property if you need to be explicit about it.

@mariusor@metalhead.club that works too!

@thisismissem seems I misspoke, as Nutomic's reply above clarifies: the tree stays but is effectively orphaned. Lemmy v1.0 will allow the reply tree to be accessed post-deletion.

The original query does still remain the same: what would be the best way forward to explicitly signal the deletion (or technically, the removal) of an entire reply tree?

cc @jdp23@neuromatch.social @mariusor@metalhead.club

@julian @jdp23 well, a Delete can be operated on an array of objects.

Send one with all the objects that are affected from the local instance (and probably you must keep in mind that not all replies might be).