Deleting a post vs deleting an entire comment tree
Technical Discussion
40
Posts
14
Posters
6
Views
-
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:Delete(Object)with a new propertywith_repliesor similarRemove(Context), whereContextis 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
- Two big threadiverse implementors (and probably mbin) currently federate
-
What if instead of doing the Announce, the requestor of the object did a like Subscribe? i.e., "I've had this object federated to me (either by user-lookup or boost from another server), you don't know I know about this object, so I'd like to inform you so that you can send me updates on this object in the future"
-
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?
-
On most forums (and forum-inspired social networks like the old tribe.net or Facebook groups), the first post represents the root of the thread, so when you delete it it deletes the entire thread.
Misskey and *key forks are like this too. Ask me how I know! loslob.
-
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:
- Same as option 1, a new property like
removeChildren; - Make the
targetof theDeletean array. I'm honestly 50/50 on whether this is actually spec compliant, it's not clear to me that it isn't; - Just sending out an individual
Deletefor everyObject. I like this option the least, but it is very easy to implement and needs no changes in other software to work.
- Same as option 1, a new property like
-
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:
- Same as option 1, a new property like
removeChildren; - Make the
targetof theDeletean array. I'm honestly 50/50 on whether this is actually spec compliant, it's not clear to me that it isn't; - Just sending out an individual
Deletefor everyObject. I like this option the least, but it is very easy to implement and needs no changes in other software to work.
Either of those first two sound fine.
- Same as option 1, a new property like
-
@julian @rimu @nutomic @melroy @BentiGorlich
#hubzilla and #friendica had always have the discussion tree
-
Can you clarify a bit what this means?
I'm imaging the following scenario, i.e.
Givengherkin steps,- Alice on her own server Abel.
- Bob on the forum server Forum.
- Alice created a post in a category of Forum. Let's call it "1000 reasons to hug cows". id
http://abel.example/alice/post. - Bob, a million other trolls, replies with "To tip them over! lol!". Bob's post has id
http://forum.example/bob/post/id.
The
Whenblock is simple. Alice deletes her post, it's a root post (with lots of stupid replies). This means aDeleteactivity is send for the object withhttp://abel.example/alice/post.Now, what does this imply? Obviously, we have "The forum sends an
Announce(Delete).". But do we also have:- The forum sends a
Delete(http://forum.example/bob/post/id)as Bob? - The forum sends a
Announce(Delete(http://forum.example/bob/post/id))as the forum?
How does the forum handle posts not made by its users? It obviously cannot delete them! So is there like an
Undo(Announce(Create(Object)))or aRemove(Object)? -
@thisismissem not even orphaned, a delete leaves behind a tombstone object which should still be dereferenceable from anywhere else.
-
@julian @rimu @nutomic @melroy @BentiGorlich
I'm still confused that so many people have thought that using Announce as a solution for something which is at its core, an addressing problem is a good way to do it.
I guess I might not be aware of some subtleties, but why doesn't the original Delete reach all the interested parties? Why is there a need for Announce-ing it in the first place?
-
@julian @rimu @nutomic @melroy @BentiGorlich
I'm still confused that so many people have thought that using Announce as a solution for something which is at its core, an addressing problem is a good way to do it.
I guess I might not be aware of some subtleties, but why doesn't the original Delete reach all the interested parties? Why is there a need for Announce-ing it in the first place?
Lets say you have a user on instance alpha, and a community on instance beta, with followers on various other instances. The user makes a post in the community, but how can he know who the community followers are to send it directly to them? And how could the followers trust that an activity sent directly was actually approved by the community?
Another solution for this would be inbox forwarding, but by now its too late to change the behaviour of all existing platforms.
-
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/Objectfor 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. -
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:
- Same as option 1, a new property like
removeChildren; - Make the
targetof theDeletean array. I'm honestly 50/50 on whether this is actually spec compliant, it's not clear to me that it isn't; - Just sending out an individual
Deletefor everyObject. I like this option the least, but it is very easy to implement and needs no changes in other software to work.
This is slightly different from OP as you are talking about deleting a reply (ie
Note) with children, while OP is about deleting a top-level post with children. Nevertheless both can be represented in the same way over federation.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.
This would be terrible for performance when removing dozens or hundreds of comments at once. Rule of thumb should be one activity for one user action.
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;
The problem with this is that some platforms might get the idea to delete multiple unrelated comments with a single activity, or even comments in different posts. Handling that would make the receiving logic unnecessarily complicated, and would also make it complicated to combine the modlog entries.
Same as option 1, a new property like removeChildren;
This is the simplest and best option.
- Same as option 1, a new property like
-
This is slightly different from OP as you are talking about deleting a reply (ie
Note) with children, while OP is about deleting a top-level post with children. Nevertheless both can be represented in the same way over federation.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.
This would be terrible for performance when removing dozens or hundreds of comments at once. Rule of thumb should be one activity for one user action.
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;
The problem with this is that some platforms might get the idea to delete multiple unrelated comments with a single activity, or even comments in different posts. Handling that would make the receiving logic unnecessarily complicated, and would also make it complicated to combine the modlog entries.
Same as option 1, a new property like removeChildren;
This is the simplest and best option.
@nutomic > Make the target of the Delete an array
It technically is because of JSON-LD (everything can be an array), however, software may not support it because it's pretty common for devs to treat AP as JSON instead of JSON-LD, so doing an assessment of compatibility would be suggested
-
@julian @rimu @nutomic @melroy @BentiGorlich
#hubzilla and #friendica had always have the discussion tree
@tofeo :verified: @julian ...where "always" means "since before there was even Mastodon".
A side-effect of their model, present at least on Hubzilla and Hubzilla's descendants, including still existing (streams) and Forte, is that comments/replies cannot exist in a stream without a) a parent and b) a start post. On all of them, including Friendica, it isn't a post if it replies to something, very much unlike Mastodon where a thread is a bunch of posts.
Depending on whom you ask, a conversation looks either like this:- Post
- Comment
- Comment
- Comment
- Comment
- Comment
- Comment
- Comment
- Comment
- Comment
- Post
-
Lets say you have a user on instance alpha, and a community on instance beta, with followers on various other instances. The user makes a post in the community, but how can he know who the community followers are to send it directly to them? And how could the followers trust that an activity sent directly was actually approved by the community?
Another solution for this would be inbox forwarding, but by now its too late to change the behaviour of all existing platforms.
@nutomic I solved this by having an the instance be an actor that is an intermediary for all operations. All activities get CC'ed to the followers of the user actor, and of the instance actor. (replace instance with community/group, whatever you use as an aggregate element for your implementation)
This should cover all interested parties imho.
The potential downside is that instances need to explicitly operate between themselves with follow operations (which conveniently also solves the problem of unwanted interactions with less savory corners of the fediverse).
Like I said, a problem of addressing. :P
-
@nutomic I solved this by having an the instance be an actor that is an intermediary for all operations. All activities get CC'ed to the followers of the user actor, and of the instance actor. (replace instance with community/group, whatever you use as an aggregate element for your implementation)
This should cover all interested parties imho.
The potential downside is that instances need to explicitly operate between themselves with follow operations (which conveniently also solves the problem of unwanted interactions with less savory corners of the fediverse).
Like I said, a problem of addressing. :P
@nutomic I realize this explanation probably skips a lot of information that's clear to me from my context, but I'll try to answer if anyone has any questions.
-
@thisismissem not even orphaned, a delete leaves behind a tombstone object which should still be dereferenceable from anywhere else.
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?
Gli ultimi otto messaggi ricevuti dalla Federazione
-
@julian you used the word Delete throughout, so i used the same word. either way, you might consider a policy of treating a context deletion as orphaning all items in the context and then you can optionally garbage-collect them. or not. it's up to you, really!
-
trwnh@mastodon.social nobody's deleting anything. We're only dealing with removing content.
(Which I now realize I worded incorrectly in OP, heh)
That it's a Delete is incidental (and unfortunate wording)
-
@julian @rimu @nutomic @silverpill essentially the difference between the two actions only exists internally, not externally.
whether to use a Delete or a Remove is a separate issue of semantics and authority.
whether to use an array of objects is a separate issue of batching and partial failure. semantically, there is no issue. "john deleted 10 posts" makes sense as a statement.
-
@julian @rimu @nutomic @silverpill put another way, there is no difference between a link that doesn't resolve because the resource was deleted and a link that doesn't resolve because the server was down or a link that doesn't resolve because you don't have authorization to see it. it's just a link that doesn't resolve, as far as you're concerned.
the same thing applies to moderation, not just deletion. a direct link might resolve, but the link is omitted from a curated view.
-
@julian @rimu @nutomic @silverpill well, you typically have no authority over "children", so you can't actually delete them. you can treat them as deleted locally (equivalent to garbage collection for orphan references), but as far as the outside world is concerned, you just deleted one object.
i think people should be more aware that orphaned references can and will happen. i'd personally leave them be. link rot is a thing, and those links aren't necessarily invalid, they're just stale.
-
@julian @mariusor @helge
fwiw, letterbook is fine with that
https://github.com/Letterbook/Letterbook/blob/6bf60b1b3d37a8b5d49a1d2554bfd5e4468f00de/Source/Letterbook.Api/ActivityPub/ActorController.cs#L309
-
The thing I'm adding to FIRES is the ability to label data as you import it.
-
trwnh@mastodon.social it's less so that I want receivers to do what I want (the ship has sailed on that), but rather that we have the opportunity to provide some guidance on preferred behaviour.
What's clear here is that there are going to be two separate actions, "Delete object and all children, recursively", or "Delete object but retain children".
We're discussing the best way to represent those two actions.
cc rimu@piefed.social nutomic@lemmy.ml silverpill@mitra.social
