FEP-7888 attempts to lay out clarifications for the use of the context property based on rationale and history, in which context is used primarily to logically group objects related by their “context”, or in other words, stating that some object “was created in relation to” another object, where the latter object denotes some purpose for the first object.
In response to FEP-7888, and motivated by the desire to backfill entire conversations, various softwares wishing to federate have chosen to directly represent context as a Collection of objects acknowledged to be “within” some canonical context collection. This FEP describes this approach, its usages, and some drawbacks.
FEP-7888 describes the concept of “Canonical collections of objects within an authoritative context” as a case where, if a context dereferences to some object, then the type of that resolved object can indicate a certain relation as representing the “canonical collection”. In the case of this FEP, the “canonical collection” is the Collection itself. This gives us the following normative description:
context property is dereferenceable to an object that is a Collection or OrderedCollection, the canonical context collection is id.(This section is non-normative.)
{
"@context": "https://www.w3.org/ns/activitystreams",
"id": "https://posts.example/1",
"type": "Note",
"context": {
"id": "https://conversation.example",
"type": "OrderedCollection",
"items": [
"https://posts.example/1",
"https://posts.example/2",
"https://posts.example/5"
]
}
}
(This section is non-normative.)
The context represented by a Collection can be processed (for example, for backfill purposes) by iteratively processing its items (or orderedItems if expressed using that JSON-LD term) and considering them to be logically grouped together.
(This section is non-normative.)
The protocol for becoming aware of or discovering objects claiming to be included within your context are out of scope for this FEP. However, if you encounter an object claiming your context, then it can be Added directly to the Collection.
(This section is non-normative.)
Using a Collection type forcibly opts that object into certain spec behaviors defined by ActivityPub. Namely, if you are using a context collection, and you wish to make your Collection followable, the naive approach is to make it into an ActivityPub actor by giving it an inbox that can at least respond to Follow activities with an Accept Follow. However, there is an issue with the outbox delivery algorithm defined in the ActivityPub client-to-server API, wherein the inbox discovery algorithm necessarily always attempts to iterate over every single item in the Collection, not just the Collection itself. This behavior is triggered whenever an ActivityPub outbox receives a payload with an addressing property such as to, cc, bto, bcc, or audience. For a context Collection that is also an AP actor, addressing this Collection can be unintentionally costly to the server performing delivery, as this server is expected to attempt iteration over potentially unbounded numerous items from the Collection.
For example, given the following activity:
{
"@context": "https://www.w3.org/ns/activitystreams",
"id": "https://activity.example",
"type": "Announce",
"object": "https://posts.example/7",
"to": "https://conversation.example"
}
The intention might be to only POST to the inbox of https://conversation.example (and thus notify the context Collection of https://posts.example/7 existing), but the outbox delivery algorithm as currently defined at the time of writing this FEP will instead attempt delivery to all of the following inbox properties it can find across the following objects:
https://conversation.example
https://posts.example/1https://posts.example/2https://posts.example/5There is no way to opt out of this “Collection expansion” behavior. Consequently, following a context Collection cannot be done via naive ActivityPub. See FEP-efda: Followable objects for a potential workaround, where the Follow activity is addressed to attributedTo and sent to attributedTo.inbox instead of being addressed directly to id and delivered to id.inbox.
This problem does not occur if the ActivityPub “POST to outbox” is not used, and instead the Follow activity is delivered directly with Linked Data Notifications “POST to inbox”.
When modeling explicit concepts such as a “conversation”, there is a difference between saying that “a conversation is a collection of posts”, versus saying that “a conversation has a collection of posts”. The former relation (“is a”) may be imprecise or may prevent declaring other relations in a way that makes sense. The latter relation (“has a”) allows for declaring properties of the Conversation that are not properties of the collection of posts instead.
CC0 1.0 Universal (CC0 1.0) Public Domain Dedication
To the extent possible under law, the authors of this Fediverse Enhancement Proposal have waived all copyright and related or neighboring rights to this work.