Existing implementations of Conversation Containers (#Streams and #Hubzilla) add a context property to top-level posts of conversations.
-
@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
-
silverpillreplied to infinite love ⴳ last edited by [email protected]
@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.
contextHistoryis a good name though -
@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...
-
@[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* "conversational contexts" is a working name... basically, the object collection.
-
@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
-
>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
-
@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)
-
@[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:contextresolves to.If it resolves to:
- an
OrderedCollectioncontaining 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.
- an
-
@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.
-
@[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
CreateorAdd" -
@[email protected] 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. -
@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.
