Deleting a post vs deleting an entire comment tree
Technical Discussion
65
Posts
15
Posters
64
Views
-
@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
-
-
@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 @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 @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 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 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 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.
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 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!
-
@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 yes that's the point. I can't enforce behaviour from anyone but we can signal intent.
That's all this discussion is about. Whether we should
Remove(Context)orDelete(Object)+with_replies. -
trwnh@mastodon.social yes that's the point. I can't enforce behaviour from anyone but we can signal intent.
That's all this discussion is about. Whether we should
Remove(Context)orDelete(Object)+with_replies.@julian with_replies doesn't make sense, but neither does Remove(Context). if the intent is to signal "we locally cleared our cache" then i'm not sure that's relevant to anyone else?
-
@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)
@trwnh I'm not sure how much time you spent thinking about this, but I have and I *do* think that it makes sense, thank you for your input. Also it does not violate any constraints in the specification, though if you know of one I'd love to hear it.
The advantage of having all ancestors there is that the object can be disseminated to all the instances in that list, and be added to all the replies collections of its ancestors. As such when you retrieve any of those ancestor replies collections you have the full thread from their point downwards and you don't need to fetch other replies collections up the chain.
-
@trwnh I'm not sure how much time you spent thinking about this, but I have and I *do* think that it makes sense, thank you for your input. Also it does not violate any constraints in the specification, though if you know of one I'd love to hear it.
The advantage of having all ancestors there is that the object can be disseminated to all the instances in that list, and be added to all the replies collections of its ancestors. As such when you retrieve any of those ancestor replies collections you have the full thread from their point downwards and you don't need to fetch other replies collections up the chain.
-
@trwnh ok, that's a valid opinion to have, but I disagree with it, and as long as you can't offer me a specification quote which contradicts my point of view "misuse" is just like your opinion, man.
Also, please stop reply guying every time I offer my input to somebody else.
-
@mariusor @julian @helge i got here via a discussion on activitypub.space, not via your profile.
in any case, per https://www.w3.org/TR/activitystreams-vocabulary/#dfn-inreplyto
> Indicates one or more entities for which this object is considered a response.
if A says something and B responds to what A said, then C responds to what B said, it is not universally true that C is always responding to A as well.
A: What's your favorite pie?
B: I like apple pie.
C: Hey B, wanna try my apple pie this weekend?C is not a response to A.
-
@mariusor @julian @helge i got here via a discussion on activitypub.space, not via your profile.
in any case, per https://www.w3.org/TR/activitystreams-vocabulary/#dfn-inreplyto
> Indicates one or more entities for which this object is considered a response.
if A says something and B responds to what A said, then C responds to what B said, it is not universally true that C is always responding to A as well.
A: What's your favorite pie?
B: I like apple pie.
C: Hey B, wanna try my apple pie this weekend?C is not a response to A.
@trwnh I dislike to have to get into the semantics of what "a reply" is, but from my point of view the definition matches any downstream element in a discussion. Why? Because in a discussion context matters, both on a comprehension level and on the pragmatic ActivityPub level, as we can see from the work the threadiverse does. So yes, it's not an immediate reply to its ancestors but it is in the "reply chain" of its ancestors, and that is sufficient for me.
If your worry is about how to deal with this programmatically, check JWZ's message threading algorithm, which gives good solutions even with multiple ancestors.
-
@trwnh I dislike to have to get into the semantics of what "a reply" is, but from my point of view the definition matches any downstream element in a discussion. Why? Because in a discussion context matters, both on a comprehension level and on the pragmatic ActivityPub level, as we can see from the work the threadiverse does. So yes, it's not an immediate reply to its ancestors but it is in the "reply chain" of its ancestors, and that is sufficient for me.
If your worry is about how to deal with this programmatically, check JWZ's message threading algorithm, which gives good solutions even with multiple ancestors.
@trwnh an example
for threading based on multiple elements for inReplyTo (using vanilla JavaScript): https://git.sr.ht/~mariusor/oni/tree/master/item/src/js/items-threading.jsThis is my last contribution to this discussion, with apologies for the spamming to all that have been dragged into it inadvertently.
-
@trwnh an example
for threading based on multiple elements for inReplyTo (using vanilla JavaScript): https://git.sr.ht/~mariusor/oni/tree/master/item/src/js/items-threading.jsThis is my last contribution to this discussion, with apologies for the spamming to all that have been dragged into it inadvertently.
i'd rather have an actual context for tracking context. from the point of view of being understood, if you said "What's your favorite pie?" and i said "Julian is invited to my house this weekend", then this is a non sequitur.
a real example of multi-reply:
inReplyTo: [
- AT&T tells the FTC it is a common carrier and the FTC has no jurisdiction
- AT&T tells the FCC that it is not a common carrier and is not subject to net neutrality
]
content: AT&T is doublespeaking -
@trwnh @julian This is a trust and safety issue, so it's more than just "do what you will". People post things that may endanger themselves or others, and when the details are repeated in the discussion tree deleting the original post is ineffective. Servers that handle this badly can and should be sanctioned - so yes, collectively we can and probably will enforce behaviour. It's pretty important that the intent is explicit.
-
@trwnh @julian This is a trust and safety issue, so it's more than just "do what you will". People post things that may endanger themselves or others, and when the details are repeated in the discussion tree deleting the original post is ineffective. Servers that handle this badly can and should be sanctioned - so yes, collectively we can and probably will enforce behaviour. It's pretty important that the intent is explicit.
@mat @julian i understand the situation you're describing, but what kind of notification are you trying to send regarding this? are there any expected behaviors from your audience? there is a far larger problem here: you don't have any consistency guarantees within the distributed system that is the fediverse, precisely because everyone has a different understanding. what are you trying to get your peers to understand?
typically, publishers can Delete, and forum mods can Remove from the thread.
Gli ultimi otto messaggi ricevuti dalla Federazione
-
@trwnh@mastodon.social oooh that's interesting. I actually commented on the former.
But I am realizing now that NodeBB actually explicitly addresses quite a few people because we try to keep everybody in the loop.
Responding to a topic with hundreds of posts could mean a Note object with hundreds of individual users addressed in cc.
Perhaps it's wiser to not assume "addressed? generate notification.", and instead have configurable notifications based on thread/context participation.
-
@julian @mayel subtle difference: sharedInbox is not delivering to the individual inboxes, and it is not strictly delivering to the addressed actors either. what it *actually* means is "make the shared inbox decide who gets it, using the addressing as a *hint*". in theory, the shared inbox is supposed to distribute the activity to the appropriate inboxes internally. this, of course, leads to Problems when the shared inbox doesn't understand a specific recipient (like with private collections)
-
@julian thanks, i hate it
i mean, i get it... but i hate it xD
i would rather mastodon fixed this in mastodon, but i wouldn't blame you if you did. mainly, mastodon should use to/cc/audience when composing a post, not tag.
we have https://github.com/mastodon/mastodon/issues/32242 which is the inverse (receiving, not posting). i just filed https://github.com/mastodon/mastodon/issues/37568 for the other direction (posting, not receiving)
-
@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)
