Deleting a post vs deleting an entire comment tree
Technical Discussion
65
Posts
15
Posters
69
Views
-
@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
-
@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.
@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.
-
@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 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 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.
-
@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.
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) -
@julian what does Remove(Context) mean here?
-
@julian what does Remove(Context) mean here?
trwnh@mastodon.social it signals that the actor is removing the context from the targeted audience.
The audience can optionally announce it, and receivers synchronizing with that audience (per 1b12) should follow suit and remove the context as well.
-
@julian like removing a whole thread from the forum? Remove(object=thread, target=forum)? this seems like something altogether different than removing posts from a thread.
removing threads from a forum is possible but if the thread is owned by the forum then the forum can also delete them.
the part that differs between impls is whether Delete(thing that is a context) should do anything to objects where context = the Delete.object, right? i think it makes the most sense to just orphan them.
-
@julian like removing a whole thread from the forum? Remove(object=thread, target=forum)? this seems like something altogether different than removing posts from a thread.
removing threads from a forum is possible but if the thread is owned by the forum then the forum can also delete them.
the part that differs between impls is whether Delete(thing that is a context) should do anything to objects where context = the Delete.object, right? i think it makes the most sense to just orphan them.
trwnh@mastodon.social specifically however, is that you're not deleting the context. Just removing it.
NodeBB has the concept of a context not belonging to an audience (the "uncategorized" pseudo category.) in those specific situations, contexts would be removed from the audience, not deleted.
Lemmy and Piefed don't have these concepts, so they simply delete them. So therein lies some of the confusion I believe.
-
@julian the confusing thing to me, though, is that both Delete and Remove already don't imply anything about posts in the thread if the thread is deleted/removed from the forum.
by default, if you Delete a thread, the forum might still have a broken link to the now-deleted thread, and the posts also have broken links to the thread.
by default, if you Remove a thread from the forum, the posts still exist within the thread.
-
@julian the confusing thing to me, though, is that both Delete and Remove already don't imply anything about posts in the thread if the thread is deleted/removed from the forum.
by default, if you Delete a thread, the forum might still have a broken link to the now-deleted thread, and the posts also have broken links to the thread.
by default, if you Remove a thread from the forum, the posts still exist within the thread.
@julian if the intent is to signal what happens when nodebb moves a thread to "uncategorized", then i think the simplest thing is for nodebb to treat "uncategorized" as a forum in itself, still. you already assign them an id of -1, so you are in effect treating the "uncategorized" category as a category still.
-
@julian if the intent is to signal what happens when nodebb moves a thread to "uncategorized", then i think the simplest thing is for nodebb to treat "uncategorized" as a forum in itself, still. you already assign them an id of -1, so you are in effect treating the "uncategorized" category as a category still.
@julian i'd say the confusion is primarily that we've shifted topic around several different things and i'm still not sure which is the intended topic of the discussion :x
- deleting posts that are in a thread
- removing posts from a thread
- implications for downstream posts in a thread when some ancestor in the reply chain is deleted/removed
- deleting a thread that is in a forum
- removing a thread from a forum
- moving a thread to the "uncategorized" forum
- ...?
Gli ultimi otto messaggi ricevuti dalla Federazione
-
@reiver i think the disjunction between Object and Link was actually unnecessary. https://github.com/w3c/activitystreams/issues/666
i also think there's too much emphasis on types when there really shouldn't be -- it's the *properties* that you end up using almost all of the time. pretty much the only types that actually matter are the Activity types (because you can't infer those).
-
-
@reiver Did you and I discuss queryfy a while ago, or was it one of my other projects?
Just wondering whether I owe you a heads up since queryfy has been bumped up to v0.3.0
-
With ActivityPub / ActivityStreams...
To me, it feels like there should have been something that is a common parent of both 'Object' and 'Link'.
That just had the "name", "nameMap", and "preview" fields (along with "id" and "type, of course) — since that is what 'Object' and 'Link' share in common.
I'll just call this common parent: 'Entity'.
...
It could have even been an opportunity to talk about how to handle unknown types.
-
@soapdog@toot.cafe hmm... just thinking aloud here.
You posit in another post that the network effects inflate exponentially:
> Push models are resource hogs that approach exponential growth in a large network like the fediverse
That's not true. If you post a message then it sends a copy to each follower. That's linear growth. If you collapse recipients via shared inboxes you can reduce that further.
If you're referring to the torrent of requests that happen if your post is shared (the "thundering herd" problem) then that's actually a PULL happening from those requesting instances!
Secondly, in a pull model of AP, you would need to continually poll servers of all your followers so as to approach a real-time effect. You'd be polling servers over and over again, and many of them would have nothing new, with so much wasted traffic.
If your expectations include semi real-time updates, the push model is much more performant, in my humble opinion.
-
@evan @mariusor @silverpill i think we probably need to revisit the user story of creating multiple objects at once, or more accurately, the user story of minting and binding multiple identifiers at once.
-
@evan my suggestion: https://github.com/w3c/activitypub/issues/533
-
@evan @mariusor @silverpill re: ids though the RDF ecosystem (and jsonld) doesn't use "null", it uses blank node identifiers (those prefixed with _: are special cased by the prefix expansion algorithm). this can allow for "transient" activities or "anonymous" objects (and the graph data model auto assigns _:b1, _:b2 and so on when "id" is missing; the canonicalization algorithm assigns _:c14n0 and _:c14n1 and so on)
this is maybe not the best way to create replies collections though...
