Deleting a post vs deleting an entire comment tree

submitted by

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:

  1. Delete(Object) with a new property with_replies or similar
  2. Remove(Context), where Context is 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

33
6

Back to main discussion

Parent comment

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

@helge

 reply
2

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

 reply
1

@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

 reply
1

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

 reply
1

@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

 reply
1

@mariusor @julian @helge i got here via a discussion on activitypub.space, not via your profile.

in any case, per w3.org/TR/activitystreams-voca

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

 reply
1

@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

 reply
1

@trwnh an example
for threading based on multiple elements for inReplyTo (using vanilla JavaScript): git.sr.ht/~mariusor/oni/tree/m

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

@julian @helge

 reply
1

@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

 reply
1
Insert image