from silverpill@mitra.social to swicg-threadiverse-wg@community.nodebb.org on 23 Dec 15:13
https://mitra.social/objects/0193f414-c426-5c46-8ddb-a168fba2fe80
Existing implementations of Conversation Containers (#Streams and #Hubzilla) add a context property to top-level posts of conversations. This is also what FEP-171b currently prescribes.
However, as I noted in the FEP, this is not consistent with FEP-7888 recommendations.context property is supposed to be used for grouping objects, and in Conversation Containers we have a collection of conversation activities, not posts.
A property that links top-level post to its conversation container should be called differently. For example, threadContext or conversationContext
Note.threadContext == Add.target.id
context can still be used, but for linking to the collection of posts (although I would prefer to use thread for that purpose).
#fep_171b #ConversationContainers
#conversationcontainers #fep_171b #hubzilla #streams #swicg-threadiverse-wg
threaded - newest
@silverpill@mitra.social I would think that FEP-7888 merely suggests that
as:contextbe used to group objects, although I think an implementation using it to group activities would be considered compliant. (@trwnh@mastodon.social to comment?)I don't see why a top-level post linking to its conversation container would need to use a property separate from
as:context. It sounds like you consider the conversation container and the collection of posts to be separate entities, but that needn't be the case, they can be one and the same, unless I am misunderstanding.Last time ForumWG met we voted to recommend that individual objects use
as:context. There is no additional guidance at this time as to what it points to or whether it should resolve (although that would be a logical next step).@julian @trwnh
>It sounds like you consider the conversation container and the collection of posts to be separate entities, but that needn't be the case, they can be one and the same, unless I am misunderstanding.
Yes, conversation container is separate from collection of posts. Container contains activities (in the original implementation, it is a collection of
Addactivities). Top-level post is not part of that collection, and therefore shouldn't have it ascontext.@silverpill @trwnh @julian
why would a top level post not be part of its own context?
@jenniferplusplus In our case, conversation context is a collection of activities. If we add top-level post (Note) to that collection, it becomes a mixed bag. It's harder to parse, and generally doesn't feel right to me.
So I want to have two collections, one with activities and one with posts, and use two different properties:
1.
Note.threadContext(orNote.conversationContext) - points to a collection of activities.2.
Note.thread(orNote.context) - points to a collection of posts.@trwnh @julian
@silverpill @trwnh @julian
Yes, I get that you want a collection of activities. But that's not what I asked. You said the top level post should not be part of it's own context collection. Why not?
@jenniferplusplus @silverpill @julian my read of the topic so far (if i understand correctly) is that there's confusion on a context being bound by "posts" or "activities". imo it can be whatever -- participants optionally declare a context they consider their objects created within, but moderators then optionally add what they want (since it's a collection they own). the "next step" would be to signal the moderator's criteria for what might get added, but there are no hard-and-fast rules in AP,
@jenniferplusplus @silverpill @julian ...so it's anyone's opinion on what should end up in any collection
personally i still think the `outbox` is the most natural place to put activities. especially if they're Add activities. in its simplest form, consider such an `outbox` to basically be an append-only log of Add and Remove activities. this logically implies that the collection contains the objects of the Add/Remove
this can be more or less automated by making the collection Add to itself
@trwnh @silverpill @julian
No, that is not the confusion.
silverpill said:
> Yes, conversation container is separate from collection of posts.
Cool
> Container contains activities (in the original implementation, it is a collection of Add activities).
I can live with this
> Top-level post is not part of that collection, and therefore shouldn't have it as context.
Why? This makes no sense. Why is the first post in a thread not part of the context?
@jenniferplusplus @silverpill @julian i'm not really happy with this 100% but there's no getting around the difference in implementations because it really stems from a more fundamental issue -- that of the "fediverse" not actually being a single replicated network, but really an ersatz way to publish resources to the Web that describe more or less the same end result but in multiple possible (and logically equivalent) forms
@trwnh@mastodon.social @jenniferplusplus@hachyderm.io @silverpill@mitra.social I think that makes sense considering that outboxes already do contain activities, so it's not a stretch from prior art.
I'd also like to know the thinking behind excluding root-level post from the context collection. I think it belongs within, but other software may consider root level objects to be like "topics", and so would be on a separate level from replies. The easiest example I can think of right now is Lemmy, which is how it handles posts.
@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.
@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 -
contextproperty is a pointer to a collection of posts- Hubzilla https://hub.somaton.com/conversation/0145da10-b608-4b19-b1d5-89a461e473d0 -
contextproperty 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
@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
@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 requests.
contextHistoryis a good name though@jenniferplusplus @julian
@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...
@silverpill@mitra.social @trwnh@mastodon.social Yes, although I have not heard a convincing argument as to why both conversation containers and conversational contexts*
cc @jenniferplusplus@hachyderm.io
@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
@julian
>why both conversation containers and conversational contexts* cannot be referenced via as:context
How would you do that? Two
as:contextproperties on a single object?Both collections should be discoverable via conversation root
@trwnh @jenniferplusplus
@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)
@trwnh@mastodon.social @silverpill@mitra.social One or the other can be represented in
as:context.I am of the opinion that we ought to be flexible with what
as:contextresolves to.If it resolves to:
OrderedCollectioncontaining objects :heavy_check_mark:outbox:heavy_check_mark: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 @jenniferplusplus@hachyderm.io
@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.
@trwnh@mastodon.social 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 @silverpill@mitra.social 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
CreateorAdd"cc @jenniferplusplus@hachyderm.io
@trwnh@mastodon.social the more I mull it over, the more appealing it is to have access to the entire activity history so one can "replay" the activities to do more than backfill objects.
I'd be equally happy reading it via
outboxthough. I'm pretty flexible.cc @jenniferplusplus@hachyderm.io @silverpill@mitra.social
@julian @jenniferplusplus @silverpill sure, but the set of instructions to replay is not the same as the final resulting state to be displayed. they are (or should be) distinct concepts
i’m not against exposing both, i’m just against exposing the activity log as the context for non-activity objects. doing that would be inaccurate or imprecise (you’d be collapsing the two contexts together)
of course there’s still flexibility where an activity may belong to both contexts
@julian @jenniferplusplus @silverpill for example, if you intend to have a Move activity show up in the displayed conversation, it would in theory have two contexts: one context binds the activity log, and the other context binds the current conversation items
if both are declared explicitly, then the way you’d tell the two apart is by some heuristic (probably using new types or properties). but the activity log context may be implicit by way of the outbox.
@jenniferplusplus @trwnh @julian
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.
@silverpill @jenniferplusplus @julian have you considered that maybe "posts" can have their own `context`, and "activities" can also have their own `context`?
@trwnh @jenniferplusplus @julian Yes, that's exactly what I am proposing, two collections. I just find it confusing when both of them are "contexts"
@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 @jenniferplusplus @julian in other words something like
id: some-collection
summary: "alice's followers"
type: Collection
items: [bob, charlie, david]
impliedObjectOf:
type: Relationship
subject: alice
relationship: IsFollowedBy
impliedSubjectOf:
type: Relationship
relationship: IsFollowing
object: alice
@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.
@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
@trwnh @jenniferplusplus @julian
There should be a way to go directly from
ytothread-activities: