Pre-Alpha ActivityPub-related bug reports
-
@trwnh @julian @silverpill I think the question here is "does a thread actually have any distinct properties of its own?"
Maybe a title, but that can also be inherited from either the first or most recent post. Many threaded discussion systems don't have thread objects at all, of course (email is perhaps the canonical example)
So I lean towards the idea that you should just redirect to the first thread in the post, and place the context (which when becomes just a collection of in-thread posts; an implementation detail) at another URL where it mostly becomes invisible to users.
And I think that's better, especially because having significant semantics on collections starts getting confusing when e.g. you have collection pages flying around
Really I think most types which can be represented directly as a collection (e.g. image galleries) are best represented as an object that possess a collection, though not everyone might agree@erincandescent @julian @silverpill It makes sense for threads to have not just their own title, but also their own audience and moderators, as well as flags for whether the thread is pinned or locked.
-
@trwnh @julian @silverpill I think the question here is "does a thread actually have any distinct properties of its own?"
Maybe a title, but that can also be inherited from either the first or most recent post. Many threaded discussion systems don't have thread objects at all, of course (email is perhaps the canonical example)
So I lean towards the idea that you should just redirect to the first thread in the post, and place the context (which when becomes just a collection of in-thread posts; an implementation detail) at another URL where it mostly becomes invisible to users.
And I think that's better, especially because having significant semantics on collections starts getting confusing when e.g. you have collection pages flying around
Really I think most types which can be represented directly as a collection (e.g. image galleries) are best represented as an object that possess a collection, though not everyone might agree@erincandescent@akko.erincandescent.net said:
So I lean towards the idea that you should just redirect to the first thread in the post, and place the context (which when becomes just a collection of in-thread posts; an implementation detail) at another URL where it mostly becomes invisible to users.
That's why I'm still on the fence about this whole thing. In principle, a thread object can and does exist in software, but in practice there is lots of prior art that says otherwise.
That said, email might be a threaded chain of messages, but most email clients I know have standardized around representing them as a discrete topic, if only in the UI.
@trwnh@mastodon.social @evan@cosocial.ca @silverpill@mitra.social
-
@trwnh @julian @silverpill I think the question here is "does a thread actually have any distinct properties of its own?"
Maybe a title, but that can also be inherited from either the first or most recent post. Many threaded discussion systems don't have thread objects at all, of course (email is perhaps the canonical example)
So I lean towards the idea that you should just redirect to the first thread in the post, and place the context (which when becomes just a collection of in-thread posts; an implementation detail) at another URL where it mostly becomes invisible to users.
And I think that's better, especially because having significant semantics on collections starts getting confusing when e.g. you have collection pages flying around
Really I think most types which can be represented directly as a collection (e.g. image galleries) are best represented as an object that possess a collection, though not everyone might agree@trwnh @julian @silverpill (the other option is instead of redirection do
<link>tags, and then you can link to both if you wish; imagine including<link rel="as:context" href="...">) -
@erincandescent@akko.erincandescent.net said:
So I lean towards the idea that you should just redirect to the first thread in the post, and place the context (which when becomes just a collection of in-thread posts; an implementation detail) at another URL where it mostly becomes invisible to users.
That's why I'm still on the fence about this whole thing. In principle, a thread object can and does exist in software, but in practice there is lots of prior art that says otherwise.
That said, email might be a threaded chain of messages, but most email clients I know have standardized around representing them as a discrete topic, if only in the UI.
@trwnh@mastodon.social @evan@cosocial.ca @silverpill@mitra.social
@julian @erincandescent @evan @silverpill Let me put it this way: the latter half of FEP-7888 can be summarized as "reifying context as an object, and specifically a Collection". If you *just* want the grouping, then it could be an arbitrary opaque IRI. But what you gain by reifying the context as an object is specifically the ability to give it metadata properties. Particularly things like `attributedTo` or `audience`. Maybe even `followers` or `outbox`. An opaque IRI cannot do this.
-
@julian @silverpill We could define a dedicated type for Thread or Conversation or whatever you want to call "a Collection that contains only "post" objects", but it would still be a Collection as well. I think this was something I was considering for a FEP that I ended up never really writing because it felt unnecessary and also very premature. The general idea is to define some way to know what a Collection "contains" -- is it a Conversation or a MediaAlbum or whatever. The problem is taxonomy
I think you could also put a summary or name on a Collection and use that for the title of the thread?
-
@julian @erincandescent @evan @silverpill Let me put it this way: the latter half of FEP-7888 can be summarized as "reifying context as an object, and specifically a Collection". If you *just* want the grouping, then it could be an arbitrary opaque IRI. But what you gain by reifying the context as an object is specifically the ability to give it metadata properties. Particularly things like `attributedTo` or `audience`. Maybe even `followers` or `outbox`. An opaque IRI cannot do this.
@trwnh @julian @evan @silverpill I never did the URI should be opaque; what I implied was that perhaps it should be an implementation detail URI as opposed to a directly visible one.
Some of this is that I wonder how decoupled such a thread truly is *semantically* from it's root post -
@trwnh @julian @silverpill (the other option is instead of redirection do
<link>tags, and then you can link to both if you wish; imagine including<link rel="as:context" href="...">)@erincandescent @julian @trwnh @silverpill a thread is a tree with a root. Every non-root node in the tree has an `inReplyTo` that points to one of the other nodes.
It's represented by a `Collection` in the `context` property of each object. (I don't like this, but it's common so we should just use it).
It's in reverse-chronological order.
If you started at the root node and walked the tree using the `replies` collection, you should visit exactly the same nodes as in the `context` collection.
-
@julian @erincandescent @evan @silverpill Let me put it this way: the latter half of FEP-7888 can be summarized as "reifying context as an object, and specifically a Collection". If you *just* want the grouping, then it could be an arbitrary opaque IRI. But what you gain by reifying the context as an object is specifically the ability to give it metadata properties. Particularly things like `attributedTo` or `audience`. Maybe even `followers` or `outbox`. An opaque IRI cannot do this.
@trwnh @julian @erincandescent @silverpill you can also get the whole thing! That's the big benefit of having a `Collection` -- you can retrieve it.
-
@trwnh @julian @evan @silverpill I never did the URI should be opaque; what I implied was that perhaps it should be an implementation detail URI as opposed to a directly visible one.
Some of this is that I wonder how decoupled such a thread truly is *semantically* from it's root post@erincandescent @julian @evan @silverpill I've never really understood why anyone would semantically collapse them. You lose so much expressivity by doing that. In my mind, they're *very* distinct from each other. A thread can have its own title which is separate from the title of the "root post". In fact, I don't think "root post" is even the best way to think about it. You can group posts that aren't replies to each other. Your first post may be a response to something outside of the thread.
-
@erincandescent @julian @trwnh @silverpill a thread is a tree with a root. Every non-root node in the tree has an `inReplyTo` that points to one of the other nodes.
It's represented by a `Collection` in the `context` property of each object. (I don't like this, but it's common so we should just use it).
It's in reverse-chronological order.
If you started at the root node and walked the tree using the `replies` collection, you should visit exactly the same nodes as in the `context` collection.
@evan @erincandescent @julian @silverpill I don't think a thread *has* to be a tree -- it's a set. The "reply tree" is a separate structure. Threads can be forked out of other threads.
(I also dislike "reverse chron" and heavily favor "forward chron", but custom sorting of collections is not well-specced rn so that's a future step.)
-
@julian I reported this to you because one user asked me by "why I can't discover this NodeBB thread from my instance?". I think this is going to happen quite often across the Fediverse.
Maybe in the future we will figure out how to deal with these collections, but right now this leads to a bad user experience -
@julian @Erin
I'm not a dev, so I don't have the technical details down pat.
But Friendica and everything that came after it, including Hubzilla, handle conversations as something enclosed with exactly one (1) post and otherwise only comments, as opposed to Mastodon's loose chain of posts. Replies are always comments instead of posts, and they're always sent to the thread starter who is the owner of the whole thread, and who then distributes them to all participants.
Right after Friendica, permissions were introduced. These aren't stored with each comment separately and with the post only for the post itself. Rather, they're unified for the whole thread. The thread starter defines who is allowed to see what and who is allowed to do what. As opposed to Mastodon, commenters cannot change the permissions of their comments away from those of the start post.
Last year, (streams) switched to conversations as containers. To the outward, it works the same, but internally, it's different. Again, I'm not a dev. @Mike Macgirvin
️ has made all this. But to my understanding, this is when a thread really became an object of its own.
CC: @infinite love ⴳ @Evan Prodromou @silverpill
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Friendica #Hubzilla #Streams #(streams) #Conversations -
@julian I reported this to you because one user asked me by "why I can't discover this NodeBB thread from my instance?". I think this is going to happen quite often across the Fediverse.
Maybe in the future we will figure out how to deal with these collections, but right now this leads to a bad user experience@silverpill @evan@cosocial.ca @erincandescent @julian @evan@community.nodebb.org I'd prefer impls update to support showing threads/collections, rather than NodeBB being held back. UX will get better as other impls update.
At the very least, browser.pub can do it!
-
@evan @erincandescent @julian @silverpill I don't think a thread *has* to be a tree -- it's a set. The "reply tree" is a separate structure. Threads can be forked out of other threads.
(I also dislike "reverse chron" and heavily favor "forward chron", but custom sorting of collections is not well-specced rn so that's a future step.)
@trwnh @evan @erincandescent @julian +1 for forward chron, that way you can start displaying posts without fetching the whole thread
-
@trwnh @evan @erincandescent @julian +1 for forward chron, that way you can start displaying posts without fetching the whole thread
@silverpill @trwnh @erincandescent @julian Use the `last` property to start with the oldest page.
-
@silverpill @trwnh @erincandescent @julian Use the `last` property to start with the oldest page.
@silverpill @trwnh @erincandescent @julian Also, I think you're imagining some kind of pre-order traversal sorting. If you want that, it's a lot easier to just walk the `replies` tree.
-
@silverpill @evan@cosocial.ca @erincandescent @julian @evan@community.nodebb.org I'd prefer impls update to support showing threads/collections, rather than NodeBB being held back. UX will get better as other impls update.
At the very least, browser.pub can do it!
@trwnh @silverpill @evan @julian @evan so, truthfully, I'm ambivalent to whether a thread object exists. But if it does, I feel like it should probably be reified distinctly from the thread collection primarily because I don't think treating collections as objects is a good idea. Maybe I'm wrong, but that's my strongly held opinion!
And yeah, then we can give threads a following collection and let people follow them as they wish. -
@trwnh @silverpill @evan @julian @evan so, truthfully, I'm ambivalent to whether a thread object exists. But if it does, I feel like it should probably be reified distinctly from the thread collection primarily because I don't think treating collections as objects is a good idea. Maybe I'm wrong, but that's my strongly held opinion!
And yeah, then we can give threads a following collection and let people follow them as they wish. -
@silverpill @trwnh @erincandescent @julian Use the `last` property to start with the oldest page.
@evan @silverpill @erincandescent @julian just seems backwards to me, for no real reason. if you wanted reverse chron viewing of a forward chron collection, then it makes sense to fetch `last` and page backwards.
at the very least, `startIndex` as a property of OrderedCollectionPage makes **way** more sense with a forward chron presentation.
-
@evan @silverpill @erincandescent @julian just seems backwards to me, for no real reason. if you wanted reverse chron viewing of a forward chron collection, then it makes sense to fetch `last` and page backwards.
at the very least, `startIndex` as a property of OrderedCollectionPage makes **way** more sense with a forward chron presentation.
@trwnh @silverpill @erincandescent @julian
It's bad for caching to do forward chron, which is why we don't do it anywhere else.
Also, it does not help you build a tree structure; older nodes are not necessarily at the top of the tree.
