Deleting a post vs deleting an entire comment tree
Technical Discussion
25
Posts
12
Posters
0
Views
-
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.
I do agree that
with_replies, or similar, would be the easiest approach, but I don't think it is the most specific.The bool suggests that all replies to a given object are deleted. However, you do not know whether your idea of what the reply tree is matches that of the originating server (which replies are included, etc.?)
Remove(Context), on the other hand does imply both that the container is deleted, and all of its replies, which are dereferenceable by resolving the context directly. It also has the benefit of being able to provide a pointer to where it was removed from, which is useful.So to me it's not just a matter of preference, but that there are additional benefits to
RemoveI will of course concede that it is more work to deliver
Remove.cc thisismissem
-
@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
I'm sure that approach works as well. This would have been worth discussing 4 or 5 years ago when I was just implementing federation in Lemmy for the first time. By now FEP-1b12 is already an established standard which is used by various platforms, and it would be completely unfeasible to replace it with something else.
-
I fail to see what the fundamental difference is. If you are unsure about the target with
Delete/Object, you can also resolve thecontextof Object to figure that out. Anyway the instance where theGroupis hosted is always the authority, so the state there is the correct one.Actually I would rather think of this from a different perspective, namely from the perspective of the mod who clicks the remove button. That would happen when a post is offtopic or violates the rules, and then the intent clearly is to remove all replies as they are not useful. It wouldnt make sense to leave up a single reply two levels deep just because it wasnt included in the context for some reason.
-
@julian This sounds like an implementation detail to me. Some fedi platforms delete a child object when its parent is deleted, others don't.
If you want to make the removal of a subtree explicit, I'd recommend a
Removewhereobjectis an array (similar to what @mariusor suggested):Remove(object: Note[], target: Context)This also helps with migrating away from
Announce(Delete). I saw your FEP draft, will provide more feedback once I read it in full. -
I'm sure that approach works as well. This would have been worth discussing 4 or 5 years ago when I was just implementing federation in Lemmy for the first time. By now FEP-1b12 is already an established standard which is used by various platforms, and it would be completely unfeasible to replace it with something else.
@nutomic if you're implying that I should have spoken sooner, I'm pretty sure I did. I remember exchanging messages with both you and @dessalines when you started lemmy...
I have no specific memory about this topic, but to my recollection lemmy federation was pushed as fait-accomplit at one point without me seeing any previous research on your guys part.
Gli ultimi otto messaggi ricevuti dalla Federazione
-
Hi all,
I've recently had some questions about what tool to use for note taking during taskforce meetings, personally I've been using hedgedoc from social.coop, but it's a private instance and you need an invited account. I've also used hackmd in the past. I've seen other taskforces use Google Docs, and I think one even used CryptPad.
Officially the W3C way of scribing meetings is via an IRC bot: https://www.w3.org/2006/tools/wiki/WebExBestPractices#Meeting_Record_(Minutes)
However, this isn't necessarily the most approachable to many members of the Social Web CG.
At the end of the day, the most important part is that taskforce leads capture meeting notes and preserve them, e.g., in the taskforce github repository on swicg or swicg/meetings. (I could also automate taskforce to swicg/meetings sync)
I currently own the socialcg.org and swicg.org domains, and I'd be happy to spin up a hedgedoc server on a subdomain there that taskforce leads can use for creating and taking meeting notes. However, to do this I'd need to figure out some funding for it (not particularly a lot, but some amount of money — somewhere in the range of €60-180 a year, I'd guess).
What tooling would you like to use for taking meeting notes? Would having a hedgedoc install for the CG be valuable?
(I am also in the process of hosting the Activity Summary Bot on a VPS, which produces these emails to the mailing list weekly: https://lists.w3.org/Archives/Public/public-swicg/2025Oct/0028.html — it was running on github actions but kept failing there due to GitHub restrictions, so I've had a VPS on a server sponsored by one of the large fediverse hosts to replace GitHub Actions for more reliable delivery)
Yours,
Emelia
-
@nutomic if you're implying that I should have spoken sooner, I'm pretty sure I did. I remember exchanging messages with both you and @dessalines when you started lemmy...
I have no specific memory about this topic, but to my recollection lemmy federation was pushed as fait-accomplit at one point without me seeing any previous research on your guys part.
-
@julian This sounds like an implementation detail to me. Some fedi platforms delete a child object when its parent is deleted, others don't.
If you want to make the removal of a subtree explicit, I'd recommend a Remove where object is an array (similar to what @mariusor suggested):
Remove(object: Note[], target: Context)This also helps with migrating away from Announce(Delete). I saw your FEP draft, will provide more feedback once I read it in full.
-
I fail to see what the fundamental difference is. If you are unsure about the target with Delete/Object, you can also resolve the context of Object to figure that out. Anyway the instance where the Group is hosted is always the authority, so the state there is the correct one.
Actually I would rather think of this from a different perspective, namely from the perspective of the mod who clicks the remove button. That would happen when a post is offtopic or violates the rules, and then the intent clearly is to remove all replies as they are not useful. It wouldnt make sense to leave up a single reply two levels deep just because it wasnt included in the context for some reason.
-
I'm sure that approach works as well. This would have been worth discussing 4 or 5 years ago when I was just implementing federation in Lemmy for the first time. By now FEP-1b12 is already an established standard which is used by various platforms, and it would be completely unfeasible to replace it with something else.
-
I do agree that with_replies, or similar, would be the easiest approach, but I don't think it is the most specific.
The bool suggests that all replies to a given object are deleted. However, you do not know whether your idea of what the reply tree is matches that of the originating server (which replies are included, etc.?)
Remove(Context), on the other hand does imply both that the container is deleted, and all of its replies, which are dereferenceable by resolving the context directly. It also has the benefit of being able to provide a pointer to where it was removed from, which is useful.
So to me it's not just a matter of preference, but that there are additional benefits to Remove
I will of course concede that it is more work to deliver Remove.
cc thisismissem
-
@julian @jdp23 well, a Delete can be operated on an array of objects. :D
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).
-
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?
