Related to the ForumWG topic of resolvable context collections, there are four FEPs that are currently in consideration:
- FEP-7888: Demystifying the context property
- FEP-400e: Publicly-appendable ActivityPub collections
- Draft FEP-171b: Conversation Containers, an evolution of Conversation Containers
- FEP-76ea: Conversation Threads
@[email protected] made a suggestion last month to hopefully reduce the number of moving parts:
- Both FEP-400e and FEP-1b12 implementations: support FEP-7888 (context collection)
- FEP-400e implementations: upgrade to Conversation Containers
- FEP-1b12 implementations: add target property to Announce activity that points to context collection.
This takes FEP 400e out of the running (potentially). But the day after that last meeting, @[email protected] put together FEP 76ea, and now we're back to three.
My concern is that all three FEPs (7888, 171b, and 76ea) all share these distinct qualities:
- They establish a conversational context for a given object
- They federate out an
Add on collection addition. (76ea also sends Remove)
- They contain some concept of a context owner (
attributedTo)
They differ on the following qualities:
- 7888/171b use
context whereas 76ea uses a new property thr:thread
- 171b specifies a new object type
Context
- Collection items:
- 7888 sends objects in chronological order
- 171b sends activities in chronological order
- 76ea sends objects in reverse chronological order
In the lead up to the November WG meeting I'd like to address those differences. All three FEPs are in pre-draft or draft stages, and so I am hoping we can find some common ground and compromise.
Pinging interested parties (who were not already mentioned above) for comment:
@[email protected] @[email protected] @[email protected] @[email protected]
@julian @evan @jenniferplusplus @mikedev @erincandescent @evan @trwnh
>7888/171b use context whereas 76ea uses a new property thr:thread
I think
contextis good enough. Streams and NodeBB already provide this collection and Mitra will too.>171b specifies a new object type Context
It is for easier identification of conversation-Add activities. My server may receive many different kinds of Add activities, and it would be nice to have some indication of what collection is being modified.
This is just an idea though. Streams uses
Collectiontype>Collection items:
My use case requires items to be activities, but I can support both variants of
contextcollection. Conversation activities can be also put into a different collection.@[email protected] @[email protected] @[email protected] @[email protected] @[email protected] @[email protected] @[email protected]
My plan is to bring Akkoma into conformance with FEP-7888.
Contexts (as they implicitly exist) containObjects in Akkoma today, and my plan is to make that collection dereferencable.At the moment I have no plan to implement sending of
Addactivities though that could come in the future.Regarding FEP-171B's use of the
Contextobject type, I am ambivalent. We will likely expose an (Ordered?) collection at first.FEP-76EA's definition of
thr:threaddoesn't match how Akkoma maintains or interprets theContexttoday. My opinion is that I would only invest time in implementing it if implemetations actually coalesced around it; it doesn't suit our needs. In particular the requirement "The tree structure of the thread should be maintained; every object in the thread collection, except the root, should have an inReplyTo property that matches the id of another object in the collection." does not match how Akkoma handles quote posts (it places them in the same Context).