@trwnh @erincandescent @julian @mikedev @silverpill yes, `scope` became `audience` and was (incorrectly, I think) made into an addressing property in AP.

@evan @erincandescent @julian @mikedev @silverpill Joining a Discord guild (the Group, loosely) gives you access to multiple rooms/channels (a bunch of Collections) all at the same time. Each channel could be rendered as a chat room or as a forum thread or however you want to display a collection of objects.

Essentially, `audience` and `context` are converse properties. In many cases, the "group" is the `audience` and the "thread" is the `context`. This is emergent behavior in NodeBB/Discourse.

@evan @erincandescent @julian @mikedev @silverpill I suppose it could be complicated a bit when you start to consider rooms/channels/threads/topics/etc that are limited to a subset of the group/audience, for example via a roles system. But that's something I don't want to think about yet; at least not until we have a foundation that works for representing posts and contexts and audiences

@Evan Prodromou To put it another way, there are several levels.

1. Things you can join and follow, such as chat rooms, discussion groups, and forums. It has a membership, and the administrator controls who is a member and who is not. When you join, you automatically follow it.

2. Categorization and curation, such as tags, categories, lists, etc. This can be filtered against by the recipient. Or, if offered, can be followed.

3: Specific conversations, which can include forum threads, Facebook-style threads, direct message conversations, etc. This keeps conversations in a container so they are easier to read.

@infinite love ⴳ You cannot assume the audience is the same as the category, context, forum, or sender. Some software, such as Hubzilla, has access control. You can set the audience for each individual thread.

Also, what happens when a post has multiple contexts? It is part of a category that you can follow. It was placed in a curated list of posts that you can follow. And it is also part of a thread that is in a forum you can follow. You have three contexts and three actors for the same post.

If you are displaying posts (notes, articles, whatever) as part of a conversation, then knowing which one of those is the thread would be useful.

@scott objects can exist in multiple contexts, same as how an object can be in reply to multiple objects.

The part where I disagree is that not everything needs to be a `context`. A "category" is just a taxonomy, like any tag; the posts exist separately from that taxonomy. A "curated list of posts" is just a Collection, and the posts exist separately from that curated collection.

To figure out what is a context, ask: "does this post make sense on its own?" if no, it exists in some context.

@scott That is to say, the audience/category/context/forum/sender are all separate concepts. It's fine to set an audience for each thread separately. It's also fine to set an audience for each post separately. But if the post is meant to be viewed in the thread, then that thread is serving as a context. "Context" is loosely something that provides reason, purpose, understanding. It's got nothing to do with being in a collection or being followable (although a context MAY be those things.)

@infinite love ⴳ So, does that mean that context = thread, and nothing else can be a context?

@scott No, a thread is only a context if it's declared as an object's context. The context for an object should be something that gives it reason or purpose for existing; processing an object without its context means you aren't fully understanding the object. The context helps you understand that object.

This is generally a "conversation" but not always. Other examples of contextual grouping include a "project" or an "environment".

@scott Also note that a context doesn't have to be a Collection. You can group by anything. You could set `context` to a Person or Note or Event or whatever you want, if it helped you understand the current object, and if you grouped all objects that shared the same `context` (in a task list, for example). So it's like a tag, but with purpose. If there isn't a purpose, consider using a basic tag.

For "post" objects, it generally makes sense to use a Collection representing the "conversation".

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

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

@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, moderation by administrators, etc. The "owner" of the thread (conversation container) becomes unclear if a post belongs to more than on thread.

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.

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

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

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

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

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

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

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