Deleting a post vs deleting an entire comment tree
-
@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.
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
-
-
@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. -
@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.
