zap Documentation

Collections


Applications:


public groups, private groups, rooms, boards, forums, "mailing lists" (aka circles/aspects), "Facebook wall" emulation, photo albums, event calendars, any conversation requiring a built-in moderation workflow, any conversation desiring the application of established rules of order, "primary source" conversation back-filling that you're unlikely to ever need.

An Introduction to providing and interacting with Collections in ActivityPub


Definitions:


Collection Operation
Activities with both an object AND a target element.

Root
An ActivityPub object with no inReplyTo field.

Collection Owner
The actor that Adds the Root object to the Collection, which SHOULD be identical to
target->attributedTo.

Descendants
An ActivityPub object containing an inReplyTo field and is either a Collection OR at minimum contains an identical context with the activity that Adds the root object to the target collection.

Participant
Anybody who plays by the rules when encountering a Collection Operation.

The code is more what you'd call 'guidelines' than actual rules.


The rules:


  1. All associated objects and their activity wrappers SHOULD be signed with FEP-8b32 Object Proofs
  2. The Collection Owner SHOULD be the sole to recipient of replies generated by any Descendant in a Collection.
  3. Descendants SHOULD NOT generate additional deliveries to "mentioned" actors or any other recipients when replying to a Collection.
  4. Descendants SHOULD quietly ignore any Descendant object that was not sent by the Collection Owner via an Add or Remove of that object to the Collection target OR is a locally generated activity which is being sent to the Collection Owner for the purpose of requesting inclusion in the Collection.
  5. The Collection Owner MAY accept activities of any type from any Descendants and  MAY Add them to the Collection. This Add activity wraps the incoming signed activity as its object and this SHOULD be relayed to all Participants through unwrapping the embedded object - after verification. The Collection Owner also SHOULD send an associated Remove if the object is ever removed from the Collection.
  6. Participants MAY provide a Collection identifier in a context or contextHistory element or both. The contents of that collection are undefined.
  7. Participants MAY provide a replyTo field in their activities set to the Collection Owner.
  8. Participants MIGHT WANT to ensure their same-origin policy implementation allows the import of embedded third-party signed objects via Adding to Collections with different owners.