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

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

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

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

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

@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

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

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

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

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

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

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

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

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

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

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

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

@trwnh@mastodon.social @evan@cosocial.ca I have the feeling we're getting too into the woods about defining what exactly a thread or context ought to contain and specifying that those definitions need to persist across all implementations.

I don't think they have to.

NodeBB considers a conversational context as a "topic"/"thread". ForumWG decided to refer to these as "contexts" for ease of discussion, but other software need not follow that paradigm.

If one implementor decided to utilise context to contain only one specific line of objects (a "sacred timeline thread", if you will), I'd argue that's a perfectly valid use of context, and also fits into the definition of both of your FEPs. When they pull a NodeBB context they'll get what NodeBB thinks is a context (the entire reply tree), and that's okay too.

Basically, my argument is that yeah, as Evan said:

Anyway, I think we agree on more than we disagree on.

When we step back and think about what we want to achieve:

1. Ability to reliably backfill a conversational context
2. Declare a context owner that acts as a canonical source for context additions/removals (reply limiting and such)

Then what we're left with are three FEPs (7888, 171b, 763a) that all fit the bill but only differ in minor technical aspects.

If we're going to talk about favouring FEPs over minor technical aspects, need I remind you of the following from @jenniferplusplus@hachyderm.io:

I continue to feel that this general idea is in keeping with the as-written intent of the context property. Adding a new property is likely to make adoption slower and more complicated. Adding a new object type is also likely to make adoption slower and more complicated, but less so than the property.

The more complicated you make something, the fewer implementors you're going to get. I haven't thought about these concepts nearly as long as you two have, but especially when you're talking about volunteer developers who have to work with other volunteer developers, any stumbling blocks could become insurmountable.

Simply put: there's a reason when someone wants to use OAuth2 SSO on NodeBB it's a free plugin, and when they want to hook into their corporate SAML SSO I charge a rather hefty sum.

@trwnh@mastodon.social @evan@cosocial.ca

@julian How I view it is:

1. What information is being transmitted now?
2. What information do we want to have?

We will always have to deal with implementations that vary, and we sometimes will have to assume things because they did not send all of the information we need.

But, we can still say "we would prefer the information be sent in this format." especially if that format includes additional information that tells us how to render it properly.

So there is a difference between the minimum amount of information we need and what information we want to have.

Or put another way, we can provide a way in the spec to declare that something is a thread, but still be able to process the data without it (by making assumptions since we are missing some of the data).