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
@silverpill@mitra.social 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, @evan@cosocial.ca 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
Addon collection addition. (76ea also sendsRemove) - They contain some concept of a context owner (
attributedTo)
They differ on the following qualities:
- 7888/171b use
contextwhereas 76ea uses a new propertythr: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:
@trwnh@socialhub.activitypub.rocks @erincandescent@akko.erincandescent.net @mikedev@fediversity.site @jenniferplusplus@hachyderm.io
If you've fetched a conversation collection, it would be most common to do so in order to cache the conversation locally. In this case storing under local entities is going to be much more efficient if parents are stored before their children, so the InReplyTo can be pointed to an existing stored entity. If you do it backward, it's kind of awkward.
That said, our implementation of Collection objects has a flag to reverse the returned item order. So as long as the order is defined and isn't going to change, I don't actually care what it is; beyond the storage efficiency mentioned above. We need to sort it how we want after fetch anyway, because that's just basic input sanitisation.
It would seem most natural to me to send the collection in "thread" order - start from the root and recursively traverse every branch/leaf encountered. I'll mention this for consideration -- but again I really don't care.
@mikedev @julian you shouldn't have to send a Remove if you never Added it.
i also agree that the order should generally be forward-chrono because fetching the context in a linked data browser should render the context in the same way that the HTML view would render it by default. i don't know anyone who reads threads backwards.
in any case i recently submitted https://w3id.org/fep/1985 for explicitly declaring an `orderType` for OrderedCollection
@mikedev @julian i am also thinking about extended OrderedCollection to specifically represent *sorted* sets and not just *ordered* sets. that fep would define `sortedBy` pointing to a vocab term, as well as `sortType` being either `Ascending` or `Descending`. the only thing that gives me pause is that people can lie about the value of their object's sorting property, for example setting an as:published in the distant past to be pinned to the beginning of the SortedCollection.
@trwnh@mastodon.social @mikedev@fediversity.site I think end of the day it's an implementation detail that is of minimal significance. When I fetch the collection pages I don't trust the order anyway, I reorder them all by date once I have them all anyways.
@silverpill@mitra.social said that reverse chrono for activities is preferable, and that makes sense if you want to sync up. Just retrieve activities until you reach one you've seen and you're caught up.
@julian @mikedev @silverpill i generally agree that seeing newest activities is usually preferable , but you could just as easily traverse as:last/as:prev* and stop when you reach something you've already seen, instead of traversing as:first/as:next* and likewise stopping when you reach something you've already seen. it's never made sense to me to mandate reversed order when it should just be the "recommended default". i think the real issue is that OrderedCollection doesn't imply any real order
