FEP Convergence (400e, 7888, 171b/Conversation Containers, 76ea)

Scott M. Stolz

@infinite love ⴳ So, what happens if a post is part of a thread and a project? How do you know which context is the thread?

My point is that a post can have more than one context.

infinite love ⴳ

@scott Right, so, if you have a specific meaning of "thread" in mind, then you can define a property for that. Would you say that a post can be part of more than one thread, or are you assuming a functional (max 1) relationship?

Scott M. Stolz

@infinite love ⴳ Traditionally, a post can only reside in one thread. If you try to assign a post to more than one thread, it breaks a lot of things, like the access list (audience) for the thread, the "owner" of the thread, moderation by administrators, etc.

That is probably why many people, including myself, want to define a thread as something separate from a collection.

So, I would say that a post can only reside in one thread, but can reside in multiple collections and/or contexts.

infinite love ⴳ

@scott Even if you define a thread property, that alone doesn’t stop someone from being able to declare multiple threads. I’m not convinced anyone can define “thread” in a way that is unique or even distinct from what we already have. Access lists are per-object, regardless of whether that object is a post or a collection of posts. You may be able to see a thread, but not all posts in that thread. Conversely, you may be able to see a post, but not the thread(s) it’s a part of.

infinite love ⴳ

@scott In any case, being part of a collection isn’t the same as having some context. Being part of a thread *usually* maps onto the concept of having additional context, where the thread provides context for the post, and the post exists in context of that thread. The way you handle context is by using it to group things. That context MAY have an owner, and it MAY be a collection. IF it has an owner, it is common courtesy to send your object to them. IF it is a collection, they may Add it.

infinite love ⴳ

@scott You may separately enforce at a protocol level that a post may only have one thread or one context, just as we may implicitly enforce that posts only have one inReplyTo. But the data model has no such restrictions. It is possible to not only *express* multiple values, but we can also expand the protocol to *handle* multiple values, if we wanted to. Loop over ‘context’ and IF resolved to a collection, expose that collection as a “thread”. Maybe require a special type for it if you want.

infinite love ⴳ

@scott In UI, this would be shown to the user as: “This post is part of the following context(s):” and then list them. Kind of like a “view full thread” button on a single post’s permalink page.

infinite love ⴳ

@scott Just keep in mind that being part of a collection isn’t the same as nor is it sufficient to be declared as a context. Generally avoid declaring unnecessary contexts — if it doesn’t help you in understanding the object by indicating a purposeful grouping, then leave it out or use a different property.

Scott M. Stolz

@infinite love ⴳ Why does this have to be so complicated?

A thread has always been one thread per post since the beginning of emails, discussion groups, and forums. Even Facebook-style posts are threaded with a post only belonging to one thread.

We are trying to integrate forums into the fediverse.

You can flag posts as being part of contexts and collections as much as you want, but a thread is and always will be a maximum of one thread per post. If that is not the case, it is no longer a thread, and it is a collection or context instead.

Here's the thing. Mastodon and other Twitter-inspired derivatives that do not support threaded conversations will ignore whatever we put anyway, so why should we (forums and platforms that support threaded conversations) comply with how Mastodon and non-threaded platforms do things?

A thread is fundamentally different than a collection or context, and it has been that way since the internet started. If you want a different use case, then don't call it a thread. But let the platforms that have threads call it a thread if they want.

Scott M. Stolz

@infinite love ⴳ You also have to consider that a server may pull the same post for different users, and those posts may have different contexts or collection.

User A is following a project, so when the post is sent to the recipient, the context is marked as being the project.

User B is following a forum, and wants to see all posts related to the thread (conversation). So, depending on how we decide to label forum threads, this may come back a belonging to a thread, belonging to a context, or belonging to a collection.

One thread, multiple posts, but multiple collections or contexts?

Now the app needs to figure out who is the real Slim Shady. Which one is the thread and which one is a collection or context?

It would be a lot easier to manage incoming posts if you explicitly stated which thread the post belonged to.

Evan Prodromou

@trwnh @erincandescent @julian @mikedev @silverpill so, is the Forums WG for making a federated Discord? I thought it was for forums and threaded news.

I'm glad there are other interesting social systems to model. I think you are mistaken that one size will fit all.

Scott M. Stolz

@infinite love ⴳ Another thing to consider is that a thread is displayed differently than a collection or context.

A thread is always a parent post and its children (the comments).

Whereas, a collection or context could be a bunch of unrelated posts, and could even be a bunch of unrelated threads.

As such, they are not displayed the same in the UI. Display a collection like a thread would be confusing to users, and displaying a thread like a collection would also be confusing to users.

So a thread should be a thread, and collections and contexts should be something else.

Or if you insist in using collections, then somehow label the collection as being of type thread so the appropriate UI can be served.

infinite love ⴳ

@scott

> thread is always a parent post and its children (the comments).

I disagree with this definition, but if this is how you want to define it, then a specific property or type would be best.

> context could be a bunch of unrelated posts, and could even be a bunch of unrelated threads.

If they’re unrelated, then it shouldn’t be a context. Using context is for when your object is *purposefully* related to other objects.

infinite love ⴳ

@scott

> Displaying a collection like a thread [or] thread like a collection would be confusing to users.

What’s confusing about putting the “parent post” as the first item in a list, then its “children” in chronological order after it? This is no different than what’s already done.

> somehow label the collection as being of type thread so the appropriate UI can be served.

This intention can be hinted with a dedicated type, yes, but the “appropriate UI” is more flexible than you realize.

infinite love ⴳ

@scott It’s complicated because reality is complicated. If you want to enforce “one thread per post”, you have some options:

- Define in your protocol that only one context may be set, that it should/must have certain properties like attributedTo (the owner) and items (whatever the owner officially blessed to be in the thread). Maybe you also require a type of Thread or Conversation, whatever.

- Clearly define the semantic relationship between a “post” and a “thread” in a unique+specific way

infinite love ⴳ

@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 ⴳ

@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. Stolz

@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. Stolz

@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 ⴳ

@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).