FEP Convergence (400e, 7888, 171b/Conversation Containers, 76ea)
-
infinite love ⴳreplied to Scott M. Stolz last edited by
@scott The “thread” is whatever the object says. The object could say there are multiple “threads”, even if you use a different dedicated property for this.
-
infinite love ⴳreplied to Evan Prodromou last edited by
@evan @erincandescent @julian @mikedev @silverpill If we disagree, we disagree; but my understanding developed over the past several years of thinking about this is that generic data can be presented in multiple specific ways. The UI may change, but the semantics stay the same. There are already apps that will show you your timeline as a chat messenger UI, or your conversation as a flat chronological list instead of chopped-off reply tree branches. Are they wrong?
-
Scott M. Stolzreplied to infinite love ⴳ last edited by@infinite love ⴳ The concept of a thread is probably older than most people in this conversation. It is at least 40 to 50 years old now. I don't think we should change the definition that every email client, forum, and discussion group has used for decades.
Yes, I agree that on the backend, a lot of the stuff is the same but with a different UI. I get it. In fact, I am someone who frequently brings that up.
But there are some very practical considerations on why a thread should be treated differently than a context or collection. And that is mostly because the UI to display a conversation is different than the UI for displaying a collection.
So there needs to be some way to indicate where to retrieve the entire thread. -
Scott M. Stolzreplied to infinite love ⴳ last edited by@infinite love ⴳ Let's look at the practical aspects.
Most platforms that have threaded conversations have two different views: one for threads, and one for collections or lists.
For a blog it is usually presented as the blog post with comment (a thread) vs. a list of posts in a category or as search results (a collection).
For a forum, it is similar, with a top level post and its replies (a thread) vs. a list of posts in a category or as search results (a collection).
For a discussion group, it is the same as the forum, but the UI is different.
For email, you have a threaded conversation (an email and its replies) vs. a list of posts in a category or as search results (a collection).
Notice that they are all similar. Notice that they all have something in common. There are two views, and threads always only have one parent or top level post.
From a very practical developer perspective, I need to choose which view is used to present the posts. Threaded conversations get presented one way, and collections get presented another way.
It would be nice if ActivityPub actually told me whether this is a thread or a collection so I can choose the appropriate user interface. -
infinite love ⴳreplied to Scott M. Stolz last edited by
@scott Those are all just lists, though. If you needed more hinting as to what type of collection you're viewing, then you can declare types like Thread or SearchResults or MediaAlbum or whatever. But hardcoding a check for a specific type is fragile.
The only practical consideration is in knowing whether you can submit an object for inclusion (this is the missing bit, we need a property like "can participate"), and where to send it for consideration (attributedTo).
-
Scott M. Stolzreplied to infinite love ⴳ last edited by@infinite love ⴳ Yes, on the backend they are both lists.
But the UI is VERY different for conversations versus lists.
Since the UI is different for conversations and list, I need to know whether it is a thread or a list of random posts so that I can display it correctly. -
Evan Prodromoureplied to infinite love ⴳ last edited by
@trwnh @erincandescent @julian @mikedev @silverpill You haven't been thinking about this problem nearly as long as I have. Who do you think created `ostatus:conversation`?
Anyway, I think we agree on more than we disagree on. We both think `context` should be for general groupings.
We both think the thread identifier should be a dereferenceable collection, and that the original post creator should emit `Add` activities to show that it's been updated.
-
Evan Prodromoureplied to Evan Prodromou last edited by
@trwnh @erincandescent @julian @mikedev @silverpill I think the reply tree is essential and should have its own property so it's easy to find and use, rather than having to guess if what's in the `context` collection is a reply tree. You don't; that's too bad.
-
infinite love ⴳreplied to Evan Prodromou last edited by
@evan @erincandescent @julian @mikedev @silverpill It’s not about how long one thinks about it, moreso that this idea of “generic data with specific presentations” didn’t come out of nowhere overnight. We shouldn’t overfit our data model to any specific presentation. It would be a great shame to continue privileging inReplyTo above other metadata; it represents a form of context collapse, because responding to something shouldn’t be a stand-in for an actual conversation.
-
infinite love ⴳreplied to infinite love ⴳ last edited by
@evan @erincandescent @julian @mikedev @silverpill Basically, I’ve seen and directly experienced so many cases where a conversation is not and should not be the same as a reply tree, and where conflating the two has created problems on conceptual, technical, and social layers. They exist separately, and have different semantic properties. Consider that someone making a post inReplyTo something else may not actually be participating in the same conversation, or any at all!
-
Scott M. Stolzreplied to infinite love ⴳ last edited by@infinite love ⴳ @Evan Prodromou This is exactly why platforms that have threads should declare that it is a thread. The reply tree does not always indicate whether it is a thread.
If the reply belongs in a conversation container, the container should be mentioned via ActivityPub. That way the receiving platform can display it properly.
(Thread = Conversation = Conversation Container & its Posts)