Existing implementations of Conversation Containers (#Streams and #Hubzilla) add a context property to top-level posts of conversations.

silverpill

I'm talking about two different collections:

- Collection of activities (conversation container, conversation context, thread context). I said that top-level post shouldn't be a part of this collection because it is not an activity.
- Collection of posts (conversation, thread). Top-level post certainly should be a part of this collection, but implementations of Conversation Containers currently don't publish this collection. I want to publish both collections.

infinite love ⴳ

@julian @jenniferplusplus @silverpill personally i'd mostly be interested in a collection of "posts" (including the first one) so i would probably back that interpretation as well, and i'd say that if the "first post" was *not* part of the collection, then there's probably something else going on -- maybe captured by a property like `comments`?

something like lemmy with its Page/Note split is more of an antipattern imo. then again, replies and comments are both subject to this bc topical drift.

infinite love ⴳ

@silverpill @jenniferplusplus @julian have you considered that maybe "posts" can have their own `context`, and "activities" can also have their own `context`?

silverpill

@trwnh @jenniferplusplus @julian Both collections are "contexts" in a sense that they represent groups of related entities. I refer to collection of posts as "thread" because this is what it is.

infinite love ⴳ

@silverpill @jenniferplusplus @julian

```yaml
id: x
context: thread-activities
actor: a
type: Create
object:
id: y
context: thread-posts
content: "foo"
```

thread-posts can contain your contentful objects, and thread-activities can contain everything even tangentially related to that conversation

silverpill

@trwnh @jenniferplusplus @julian Yes, that's exactly what I am proposing, two collections. I just find it confusing when both of them are "contexts"

infinite love ⴳ

@silverpill @jenniferplusplus @julian conceptually they still are both "contexts" in that they group things that belong together, but there's probably a missing piece somewhere to signal a more specific purpose, like some way to describe the implied relationship between some subject and all collection items (linked by some predicate)

this is a more general problem bc you don't know that a given collection is e.g. a followers collection or a replies collection.

silverpill

@trwnh @jenniferplusplus @julian

There should be a way to go directly from y to thread-activities:

id: x
context: thread-activities
actor: a
type: Create
object:
  id: y
  thread: thread-posts
  threadContext: thread-activities
  content: "foo"

infinite love ⴳ

@silverpill @jenniferplusplus @julian in other words something like

```yaml
id: some-collection
summary: "alice's followers"
type: Collection
items: [bob, charlie, david]
itemsObjectOf:
type: Relationship
subject: alice
relationship: IsFollowedBy
itemsSubjectOf:
type: Relationship
relationship: IsFollowing
object: alice
```

silverpill

@julian

Is it clearer now?

To re-iterate: root post is not excluded, I was talking about two different "contexts". With examples:

- NodeBB https://community.nodebb.org/post/102409 - context property is a pointer to a collection of posts
- Hubzilla https://hub.somaton.com/conversation/0145da10-b608-4b19-b1d5-89a461e473d0 - context property is a pointer to a collection of activities (conversation container)

If you're planning to implement Conversation Containers, you need a different property name for one of those collections

@trwnh @jenniferplusplus

infinite love ⴳ

@silverpill @jenniferplusplus @julian i don't understand why anyone would need to go directly from a single post to a collection of activities having to do with the thread. isn't it enough to pass through the thread itself first? e.g. take the Note.context.outbox for an "activity log", or if you're going to define a new property, then define it on the thread instead of on the post -- Note.context.history for example following https://w3id.org/fep/bad1

silverpill

@trwnh I want a direct link because I'm interested in all activities, not just posts. Going from Note to .context to .history requires additional HTTP request.
contextHistory is a good name though

@jenniferplusplus @julian

infinite love ⴳ

@silverpill @jenniferplusplus @julian it's at worst 1 extra request, but there are other reasons why that doesn't seem like a good idea. first of all, it's conceptually not a property of the post; it's a property of the *Create activity* et al. it's like asking for a property that goes directly on posts whose value is the outbox of its author, instead of simply following attributedTo.outbox as a property path...

julian

@[email protected] @[email protected] Yes, although I have not heard a convincing argument as to why both conversation containers and conversational contexts* cannot be referenced via as:context

cc @[email protected]

* "conversational contexts" is a working name... basically, the object collection.

infinite love ⴳ

@julian @silverpill @jenniferplusplus i'm still of the opinion that going directly from "post" to "conversation activities" without first passing through "conversation" doesn't make sense

silverpill

@julian

>why both conversation containers and conversational contexts* cannot be referenced via as:context

How would you do that? Two as:context properties on a single object?

Both collections should be discoverable via conversation root

@trwnh @jenniferplusplus

infinite love ⴳ

@silverpill @jenniferplusplus @julian

context on the object vs context on the activity?

the objects added into the conversation are the .items, and the activities related to the conversation can be put in the .outbox or .history or some other property of the conversation (not a property of the individual items)

julian

@[email protected] @[email protected] One or the other can be represented in as:context.

I am of the opinion that we ought to be flexible with what as:context resolves to.

If it resolves to:

an OrderedCollection containing objects
a 171b conversation container containing activities
the former but with full activity history via outbox

There is room for all of us; the concession is implementors need to be flexible enough to handle activities OR notes.

This is not a decision between 7888 XOR 171b, 171b can be 7888-compliant.

cc @[email protected]

infinite love ⴳ

@julian @silverpill @jenniferplusplus this is less about feps to me and more about being clear and correct with the statements and descriptions. it’s not just the property or the value. the current subject also matters.

the context binding several activities together is not the same as the context binding the objects of those activities. we shouldn’t semantically confuse the two.

julian

@[email protected] I know we had some discussions about what exactly a context collection should contain (plain objects vs. activities), but I don't actually see why the collection can't contain activities, at least from an implementor POV (which I'll wager @[email protected] is also of that camp).

There's the distinction that if an object references a collection then it should be a member of said collection, but when it comes down to it, I'm actually perfectly ok with "an object references a collection, and it is indirect contained in it via a Create or Add"

cc @[email protected]