Conversations

This document supercedes "Conversation Containers".

An Introduction to providing and interacting with Conversations in ActivityPub

Definitions:

Conversation
    Activities sharing a "context" element AND a "target" element AND where (context == target).

Root
    An ActivityPub object with no "inReplyTo" field.

Conversation Owner
    The 'actor' that Adds the Root object to the Conversation.

Descendants
    An ActivityPub containing an "inReplyTo" field and is a Conversation.

Participant:
    Anybody who plays by the rules when encountering a Conversation.


Participants MUST conform to the following rules, or their activities MAY be rejected by the Conversation Owner from the Conversation.


The rules:

1. All associated objects and their activity wrappers MUST be signed with FEP-8b32 Object Proofs
2. The Conversation Owner is the sole to recipient of replies generated by any Descendant.
3. Descendants MUST NOT generate additional deliveries to "mentioned" actors or any other recipients when replying to a Conversation.
4. Descendants MUST reject any Descendant object that was not sent by the Conversation Owner via an Add or Remove of that object to the Conversation target.
5. The Conversation Owner MAY accept or reject any activities with a common context element and MAY Add them to the Conversation, This Add activity is relayed to all Participants. The Conversation Owner also SHOULD send an associated Remove if the object is ever removed from the Conversation.
6. Participants MUST ensure their same-origin policy implementation allows the import of third-party signed objects via Adding to Collections with different owners.

Discussion:

Implementations often will not allow direct access to the original object in restricted audience situations, as the Descendants have a relationship with the Conversation Owner, but not necessarily have any direct relationship with other Descendants.

The Conversation is effectively being relayed to all Participants through the Conversation Owner; which is the only true source of knowledge of the exact Participants and is the ultimate moderator of the Conversation.

Additional moderation workflows and implementation details are outside the scope of this specification.

Nothing precludes the use of Conversations with public audiences, and especially as a more natural way to implement groups. The same basic mechanism has many uses and advantages in decentralised communication stacks and applications.

Nothing precludes implementations from accepting alternate signature mechanisms in lieu of FEP-8b32, and each Participant platform is free to accept or reject any Descendant if it fails to match local policy. Requiring FEP-8b32 provides a baseline for object provenance that will hopefully work well into the future.

Differences from Conversation Containers:
In Conversation Containers, matching the target and context is performed using a partial object, and the Conversation Owner extracted from that partial object rather than from the Root. Other than that, I don't think there are any real differences code wise. Should be fairly easy to accept both. This is just more concise.

Discussion:
It's harder for implementors if they don't have the root, but that is where the conversation begins. Providing one true source of a conversation and all of its descendants from the viewpoint of the conversation creator and automatically providing moderation workflow isn't really outside the scope of this specification, it's the entire purpose.