ActivityPub/Primer/Threading

Activity Streams 2.0 supports threading of conversations.

original post

An original post can be any type of object, even activities or extension object.

However, the most typical types of objects to have a thread include resources such as `Document`, `Page`, `Note`, `Article`, `Image`, `Video`, `Audio`. These are often called "posts".

Generally, a "post" will have at least content. It can also have summary and name. These properties are considered "natural language properties" and can be used to generate a text representation of any object: https://www.w3.org/TR/activitystreams-core/#text-representations

threading conversations via a chain of replies

the `inReplyTo` property

It's possible to post a reply to an original post. There is no specified type for a "comment", but these are often represented as a `Note`.

The inReplyTo property marks the reply. It refers to the original post by ID.

In order to let the original post's server track replies, reply posts should address the original author with `to`, `cc`, `bto`, `bcc`, etc. even if not mentioned. (?)

the `replies` collection

When the server of the original post receives a reply post, it may add that reply post to the original posts `replies` property. This makes it possible to track direct responses, and it is possible to recursively crawl through `replies` collections to arbitrary depths.

The server can receive the reply post as a Create activity with an object that has the inReplyTo property.

The server can receive the reply post either via client-to-server or server-to-server.

There are many reasons a server may not add the reply post, and it's at the author's and server's discretion.

Some reasons not to add the reply:

Spam filtering
Author is curating replies
Author has closed the post to new replies

Note that there is no current standard mechanism for expressing or hinting at these policies in the original post.

the reply tree

It's possible to identify replies to an original post, and replies to its replies, by getting the post's `replies` property, and then recursing through the `replies` collection of each of the objects in the collection.

There is not a standard property used for identifying the reply tree an object belongs to. FEP 76EA proposes the thread property for this purpose.

There is not a standard way to get all the objects that are part of a reply tree. FEP 76EA proposes the thread property which is a collection of all objects in the reply tree.

grouping posts into conversations

the `context` property

Activity Streams 2.0 also defines a context property that is intended to group related objects together.

Note: Mastodon uses ostatus:conversation for this same use-case.

A reply tree can be constructed using exclusively posts sharing the same context, although the reply tree may extend outside of or across contexts. For example, it is possible to "fork" a conversation by declaring a new context.

representing conversations as reified objects

https://w3id.org/fep/7888 proposes using context to refer to an object which may have a canonical collection associated with it. This canonical collection can contain posts within the same Conversation or Thread. This allows fetching all posts within a given thread, as well as allowing the thread or conversation to have its own metadata -- such as its own title, audience, moderator/owner, and so on.

Outside of Create

Tracing conversation threads isn't strictly limited to the processing of the Create activity, and it can happen whenever a server processes a post. This may be due to a Create, an Add, a manual fetch, or other processing where an object is first encountered.