Deleting a post vs deleting an entire comment tree
Technical Discussion
65
Posts
15
Posters
68
Views
-
@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...
