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!

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) or Delete(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?

@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.

@julian @helge

@mariusor @julian @helge i'm saying you should define an "ancestors" property for this instead of misusing "inReplyTo". if i am responding to specific posts, i am not necessarily responding to something 20 recursive replies upward.

@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.

@julian @helge

@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.
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.

@julian @helge

@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.js

This is my last contribution to this discussion, with apologies for the spamming to all that have been dragged into it inadvertently.

@julian @helge

@mariusor @julian @helge

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.

@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.

@mat @julian if the redaction is coming from the author, they can send a Delete to anywhere they expect to have stored a copy.

if the redaction is coming from the aggregator, they can send a Remove to anywhere relevant.

but these are always going to be best-effort, because of 2 main reasons:

- you don't have a way to track everyone who has a copy.
- your peers might not agree with what "badly" means.

generally, the answer to "how do i delete a tree" is "you can't", because trees aren't real.

@mat @julian for something that exists outside your authority, the only thing you can do is refuse to acknowledge it. i can't delete stuff from other people, and other people can't remove stuff from my thread. if they delete something and i don't remove it, then i have a broken link. if they don't delete something and i remove it, then you can't access it unless you discover it some other way. you can navigate from the offending post to the thread, but the thread will not show the offending post

@trwnh @julian Yes everything will be best effort. In this situation it's valuable to send a message "please hide the tree under this post", using whatever vocabulary. When it's working, peers will hide posts that the original author never even saw. Perhaps some people will still see parts of the tree, but the fewer the better. "You can't do it perfectly" is importantly different from "you can't".

The point is, the current situation is ambiguous on a technical level. I send a delete message, but there's no way for a receiver to know my intent: did I want just that post deleted, or the entire tree?

I absolutely can enforce that all my peers agree on what "badly" means, by defederating from servers that disagree. The predictable problem here is that when I start doing that, everyone's gonna end up in a fight about what the spec means.

I don't really mind whether the spec says instances SHOULD or MAY hide the reply tree, or if it adds a field to specify one or the other, but it should be explicit. There's a real need here, but if the answer is MAY, then the need should be addressed some other way, such as reply control.

@mat @julian if the intent is "please hide the tree under this post", then Remove(object=[n posts],target=thread) is the most straightforward way to say that in a single statement: "removed n posts from this thread"

this is something that isn't currently widely supported, but it should be. the main challenge is that not everyone understands Remove, and not everyone is equipped to handle batches. it can be overcome, but also is a more general issue.

@mat @julian i think that "defederate everyone who disagrees" will likely result in isolated clusters of each software only federating with other instances of the same software. maybe friendica and misskey can reach some limited consensus among themselves, but are friendica and misskey admins prepared to defederate every mastodon/pixelfed/pleroma/etc server over this?

@mat @julian one of my... "favorite"... examples of this kind of breakdown is that there is no specified way to remove a follower. if you accept someone's follow, then how do you revert? do you Undo Accept, do you Reject Follow, do you Remove from followers? even when two peers agree on a method (say Reject Follow at any point), they might still fail to agree for other reasons. one nasty bug between misskey and pleroma is that misskey generates ids for Follows that pleroma considers invalid.

trwnh@mastodon.social said in Deleting a post vs deleting an entire comment tree:
> Remove(object=[n posts],target=thread)

That would indeed be the most explicit, but that isn't needed from threadiverse because that information is already contained when you set object to the context itself.

It's even resolvable! So there's no need to send your own array of items that might be out of date by the time it is delivered.

Hence why I advocate for Remove(Context)