@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 @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
@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
@evan @erincandescent @julian @mikedev @silverpill historical evidence that is also relevant here:
https://github.com/w3c/activitystreams/issues/300
https://github.com/w3c/activitystreams/issues/238#issuecomment-153408442
@evan @erincandescent @julian @mikedev @silverpill historical evidence that is also relevant here:
https://github.com/w3c/activitystreams/issues/300
https://github.com/w3c/activitystreams/issues/238#issuecomment-153408442
@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.
@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.
@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 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.
@trwnh @erincandescent @julian @mikedev @silverpill
> [...] unless you want everyone to manually join every single room one-at-a-time.
This has always been my experience with chat rooms. People join (or enter) the room, make posts to the room that are visible to everyone "in" the room, and some time -- maybe years later -- leave the room.
Regardless: groups and threads are not the same thing.
@trwnh @erincandescent @julian @mikedev @silverpill
> [...] unless you want everyone to manually join every single room one-at-a-time.
This has always been my experience with chat rooms. People join (or enter) the room, make posts to the room that are visible to everyone "in" the room, and some time -- maybe years later -- leave the room.
Regardless: groups and threads are not the same thing.
@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 @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.
@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.