@trwnh @erincandescent @julian @mikedev @silverpill I have an example of a reply to multiple things in the FEP.

"Comment but don't participate in thread" is a quote boost. It also works for forking to a new thread.

So, that's what `Announce` has to do with it.

Conversation threads are *usually* reply trees, and we should optimize for that easy base case. The advanced tree-pruning and -grafting you describe are possible with a reply tree.

@evan @erincandescent @julian @mikedev @silverpill

> Conversation threads are *usually* reply trees

this is an anti-pattern. conversations are only represented by reply trees when there isn't an actual conversation. reply trees are a poor substitute for that.

> "Comment but don't participate in thread" is a quote boost.

i'm talking about participating in a thread without responding explicitly to anything. or responding to something, but in a different thread. no one is boosting anything.

@evan @erincandescent @julian @mikedev @silverpill boosting, replying, and grouping are three completely separate functions. the Announce could have its own inReplyTo and/or context.

@trwnh @erincandescent @julian @mikedev @silverpill

Maybe we need to agree that these two properties are different.

I agree that `context` is great for a related collection of objects, including for a project or event, as defined in AV.

For the specific collection of objects that are members of the same reply tree, we can use `thread`.

If it doesn't matter to specify that it's a thread, you can link to the exact same collection with `context`. It is, after all, also a related collection.

@scott yes, this can generally be accomplished by defining vocab terms for each type of collection, representing its purpose or classification -- for example, Context / Conversation / MediaAlbum / CuratedMoment / whatever. these are moreso progressive enhancements, though -- if you follow a link, then the link relation is usually enough information to know where you're going, if not necessarily enough to know what you've arrived at. a category is not always a context; context implies purpose.

@scott for example, a blog post is in one or more categories/tags/taxonomies, but the blog post does not exist purely within any of those groupings. generally if something exists in a context, you are less interested in that thing and more interested in the context in which it exists. the context provides a reason or purpose for that object; you can group all objects that share the same context and end up with some cohesive understanding of something.

@evan @erincandescent @julian @mikedev @silverpill Sure, it's possible to declare both a `context` being whatever grouping, and a `thread` being specifically a reply tree. (Perhaps `thread` should be renamed to `replyTree`, and `root` should be renamed to `replyTreeRoot`?)

I'm specifically against conflating the two concepts, though. I also would prefer to not give `inReplyTo` any undue deference beyond simply being metadata. For as many systems that rely on it, there are systems that don't.

@evan @erincandescent @julian @mikedev @silverpill For example, replying to a message is something that the user *explicitly chooses* to do when in the context of image boards or chat rooms. If you've ever used Discord, then you can see how in that system, it wouldn't make any sense to say that every message in a channel necessarily must be inReplyTo some other message in the channel (or anything at all). The room is a bound context.

@trwnh @erincandescent @julian @mikedev @silverpill sounds great.

I'm going to stick with `thread` and `root`.

They're already namespaced, and these are clear terms for these concepts.

Thanks for the help with additional use cases on forking and grafting. I'm going to add some explicit user stories to the FEP and show how each one can be handled.

@trwnh @erincandescent @julian @mikedev @silverpill yes, I absolutely agree that a chat room is topologically different from a forum thread, a Reddit post, or a social network.

@trwnh @erincandescent @julian @mikedev @silverpill I would represent a chat room as a `Group`.

@evan @erincandescent @julian @mikedev @silverpill One thing to note: If the AS2 context extension policy ever gets adopted and these terms likewise get adopted into the w3.org/ns/activitystreams context document via that process (or any other process), then this creates an issue for any other case where someone wants to use the plain-JSON keys `thread` and `root`.

@evan @erincandescent @julian @mikedev @silverpill

1) I disagree; chat rooms, forum threads, comments sections, etc. are all just different presentations of the same generic data structure (objects in collections). I could pull the AS2 data for this entire chain of replies and render it as a chat room, or as a messenger, or however I wanted to -- flat chronological list or otherwise.

2) I would use `Group` to represent an actual group of agents. For a group of posts, I would use Collection.

@trwnh @evan @erincandescent @julian @mikedev @silverpill
This conversation is hard to follow, since Evan blocked me for some reason. It makes this a notably bad venue to have these technical discussions with him.

But for what it's worth, I agree with all of your analysis and conclusions on this topic.

@trwnh @erincandescent @julian @mikedev @silverpill yes. The members of the chat room are the group. Posting to the group shares to everyone. There's a concept of joining and leaving the group.

@evan @erincandescent @julian @mikedev @silverpill Multiple collections (or any object type) can exist while sharing the same group of agents (or any other non-group set of agents) as an audience. It's not correct to say that a room "is" the group, unless you want everyone to manually join every single room one-at-a-time. The audience is the scope to which the posts (or collection of posts) are relevant, similar to how the context is the grouping. https://www.w3.org/TR/activitystreams-vocabulary/#audience-and-context

@infinite love ⴳ Being able to filter incoming content is just as important as being able to receive it. Providing the categories and the thread would be useful for filtering.

For example, you might have a situation where a particular post may have the following information:

Owner = example.com/@forum
Author (of the post) = example.social/@user
Category = example.com/forum/category/activitypub
Thread = example.com/forum/post/12345

With this information, an inbox can be set up to show threads that are a specific category and ignore the rest. Or ignore certain authors without unfollowing the thread.

In this scenario, you would need to specify which is the thread and which is the category, because the conversation can be pulled from the thread, but not the category.

You can do the same thing with blog posts. Follow a blog, but only see blog posts with specific categories.

@evan @erincandescent @julian @mikedev @silverpill historical evidence that is also relevant here:

@scott Yes, correct. I think that the link relation (or semantic property relation) is what lets you do that. Imagine if instead of context/audience/tag/etc we just had a single property `itemOf` and it was just a grab-bag of every single collection that contained the current object. That wouldn't be very useful! So we use the semantic properties and we can filter against the semantic properties. Simply being in a collection is usually insufficiently semantic -- we need to specify how/why.

@scott Which is to say, an object can have:

- a `context` in which it exists and by which it should be grouped,
- an `audience` to which it is scoped and for which it can be considered relevant
- some `tag` to which it refers

The question is, what does a "category" represent semantically? If the "category" is an actor, then perhaps it is appropriate to say it is part of the `audience`. Otherwise, you might `tag` the "category" instead. Or you might define some other relation.