Deleting a post vs deleting an entire comment tree
Technical Discussion
65
Posts
15
Posters
64
Views
-
@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?
-
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
-
mariusor@metalhead.club let's ask helge@mymath.rocks what implementor support for
Delete(Array)looks like LOL -
mariusor@metalhead.club let's ask helge@mymath.rocks what implementor support for
Delete(Array)looks like LOL@julian as long as it's in the spec, I don't really care.
If we all bow to inferior implementations the ecosystem will stagnate. Mastodon's quirks have done enough damage in my opinion. My choice is to be brave and build for the future.
PS. Not to brag or anything (🤞) but my implementation can operate on activities with arrays as object, actor, etc.
One thing where you can lead the way (because the threadiverse would really benefit from it) is to accept arrays in inReplyTo (where you put all the ancestors of the current post, not just the parent).
-
@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.
-
@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.silverpill@mitra.social mm I may have been premature regarding phasing out Announce(Delete).
nutomic@lemmy.ml made it clear that it wasn't going anywhere, and I will remove the "backwards compatibility" label from it in my draft.
-
@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.
Back then I didnt understand federation so well yet, so its possible that I didnt get what you were saying. And once I got the federation working there wasnt much reason to redo it in a different way which would effectively do the same thing.
-
@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
@thisismissem @nutomic it's not a JSON-LD thing. it's the lack of schematic constraint within the Activity Vocabulary. any property not defined as "functional" can have more than one value.
-
@julian as long as it's in the spec, I don't really care.
If we all bow to inferior implementations the ecosystem will stagnate. Mastodon's quirks have done enough damage in my opinion. My choice is to be brave and build for the future.
PS. Not to brag or anything (🤞) but my implementation can operate on activities with arrays as object, actor, etc.
One thing where you can lead the way (because the threadiverse would really benefit from it) is to accept arrays in inReplyTo (where you put all the ancestors of the current post, not just the parent).
@mariusor @julian @helge i don't think "all the ancestors" makes sense for inReplyTo. by doing that, you are claiming that your post is a response to every post in the thread above it. multiple inReplyTo still makes sense but should be used only where you are actually responding to certain things. if you want ancestors, define a property "ancestors" which is a list of ancestors ordered in a specific way (like in the mastodon api)
-
@julian @rimu @nutomic @melroy @BentiGorlich is this a problem? it seems to only be a problem if you require the others to behave exactly as you do. the same "issue" applies to any activity in general. say you send a Delete; the others can do what they want:
- purge all children
- orphan all backlinked objects
- replace with a tombstone
- rewrite content to say "this post is deleted"
- ignore your activity as unauthorized or invalid or spamthe intent could be clearer...
-
@julian @rimu @nutomic @melroy @BentiGorlich is this a problem? it seems to only be a problem if you require the others to behave exactly as you do. the same "issue" applies to any activity in general. say you send a Delete; the others can do what they want:
- purge all children
- orphan all backlinked objects
- replace with a tombstone
- rewrite content to say "this post is deleted"
- ignore your activity as unauthorized or invalid or spamthe intent could be clearer...
@julian @rimu @nutomic @melroy @BentiGorlich the complicating factor here is not what other people do, but that you would be using the terms incorrectly or imprecisely according to their definition. this happens all the time in natural language where people sometimes use words they don't fully understand or use them with definitions not matching consensus. it's how we get people saying "literally" for things that are not literal, and other such slang.
-
@julian @rimu @nutomic @melroy @BentiGorlich the complicating factor here is not what other people do, but that you would be using the terms incorrectly or imprecisely according to their definition. this happens all the time in natural language where people sometimes use words they don't fully understand or use them with definitions not matching consensus. it's how we get people saying "literally" for things that are not literal, and other such slang.
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
Gli ultimi otto messaggi ricevuti dalla Federazione
-
@mayel@bonfire.cafe oh that is an interesting choice. I suppose that makes sense, I never really thought about it. NodeBB just sends to shared inbox if available.
-
@julian@activitypub.space Hi yes we send to sharedInbox when there's more than one recipient on that instance, otherwise direct to to the user's inbox.
-
Hi @mayel@sunbeam.city, does Bonfire utilise the sharedInbox value?
I noticed this come through my nginx logs today:
128.140.127.206 - - [21/Jan/2026:19:58:04 +0000] "POST /uid/1/inbox HTTP/1.1" 500 128 "-" "https://btfree.social - Bonfire ActivityPub federation" "-"
/uid/1/inbox is an endpoint specified in my user's inbox, but that actor also sends "endpoints":{"sharedInbox":"https://activitypub.space/inbox"}, so wanted to double-check that Bonfire uses it. It should, it helps reduce the number of requests to send if multiple users belong to the same server :smile:
-
@julian (I replied to this from Hubzilla, but it doesn't seem to have showed up, so reposting from Mastodon... sorry for the duplicate)
Yes, it does.
I think FEP-171b is the relevant spec; Mike Macgirvin's description of Conversation Containers might be relevant too.
It's running Hubzilla, which is already listed as an implementer of FEP-f228.
-
Hey @fentiger@zotum.net, I was debugging something @thisismissem sent me a couple days back, and in the process of doing so discovered that Zotum.net serves context with activities!
It looks to be following FEP f228, and would be one of the few implementations that serves activities. The bug related to handling context collections specifically sending activities, so that was a fun dive :smirk:
Ping @silverpill@mitra.social, the FEP could be amended to include Zotum (or whatever the software is called)
-
-
@js
Well, all of our fediverse software is in deno. For example, as user agent for Menchys we use menschys.org just like Julian said already. I would not use an external software name as user agent. Would be cool if you could update thank you.
-
Mm I believe the community is already addressed. Mastodon doesn't prepopulate the mention in a reply unless it is explicitly in the AP object.
