Containers
An Introduction to Conversation Containers
A conversation is a collection of messages with a common context. The ActivityStreams specifications define both collections and contexts, but very little guidance is provided on how to use them effectively.
This document specifies an ActivityPub compatible model for managing conversations as Collection objects with a common context.
In ActivityPub messaging, an actor generally creates a note and their server delivers it to their followers. On the receiving side, the message is analysed, and if it is found to be acceptable, it is placed in the receiver's inbox - which is implemented as a collection.
The top level post of a conversation (often a Note object) is defined as an object without an inReplyto property.
Most existing ActivityPub compatible software adds a context element to this top level post object in order to associate it with a given conversation; and this context is typically added to all children of the conversation in order to indicate their association. Replies can nest to abitrary levels and form a conversation tree if objects within the same context set inReplyTo to a message other than the top-level post, for instance to another Note object within the same context which already has inReplyTo set to a different object.
The microblog ActivityPub conversation model, which is used by Mastodon (and some other ActivityPub software) is considered "unconstrained". In that model, members of the conversation are free to send their replies to any audience (typically but not limited to their own followers), and this may lead to fragmented conversations as each node of the conversation may be distributed to completely different audiences. The actor creating a reply is also generally unaware if the conversation creator accepted the comment into the original conversation thread and in turn published the comment to the original audience.
In the conversational model, the same basic steps occur, but respects the rights of the conversation creator, or the actor that created the initial "top level" post of a conversation thread. These conversations take place within a specific audience - and may be moderated. Conversations adopting this model of interaction are considered "constrained".
Creating a constrained conversation
A constrained conversation is implemented as a Collection.
FEP-400e provides a model for working with collections. In that proposal, ActivityPub objects which are created as part of a collection are indicated by a target "stub" property containing
- type -- (Collection or OrderedCollection)
- id -- a URL where this collection can be found
- attributedTo -- the id of the collection owner
In a constrained conversation, conforming implementations will implement FEP-400e with some very minor additions:
- In a constrained conversation, the target->id and the context are identical. This provides easy identification.
- In a constrained conversation, replies SHOULD only be addressed to the target->attributedTo actor.
- When receiving a correctly signed Add activity, checking that the id of the target is a collection owned by actor is slightly different from FEP-400e. This can be accomplished by fetching the Collection object and validating the attributedTo field.
Processing is otherwise identical. In the reference implementation of conversation containers currently under development in the streams repository, signed objects are often transmitted instead of just transmitting the ids, and these are signed using a combination of
FEP-521a and
FEP-8b32.
/https%3A%2F%2Ftf-cmsv2-smithsonianmag-media.s3.amazonaws.com%2Ffiler_public%2F71%2Fd5%2F71d5597a-5db4-4385-b17a-5bdad3d03247%2Fgettyimages-515402078.jpg "Image/photo")
;