Deleting a post vs deleting an entire comment tree
Technical Discussion
46
Posts
14
Posters
6
Views
-
@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.
Gli ultimi otto messaggi ricevuti dalla Federazione
-
@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 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'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 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 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@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 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 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)
