ActivityPub/Primer/Referring to activities

Certain activity types use another activity as their object. In the Activity Vocabulary, there are at least these types:

• Undo
• Accept
• Reject
• Share

It is helpful to have an id property for these referred activities, but not all systems will store the activity ids over time. This can make it difficult to refer to those activities later.

However, some activities might be uniquely defined based on other properties. For example, an Object is only created once, so referring to the activity without an id, but using the object's id, should uniquely define that Create.

{
   "@context": "https://www.w3.org/ns/activitystreams",
   "type": "Announce",
   "object": {
       "type": "Create",
       "object": {
            "id": "https://example.com/notes/1",
            "type": "Note",
            "contentMap": {
                "en": "Hello, World!"
            }
       }
    }
}

Referring to activities without an id lowers the requirements for publishers, since they don't have to store or lookup activity ids over long periods of time. However, it pushes that work onto the consumer, since the consumer will be doing that lookup, verification and validation.

Client-to-server

An area of particular concern is for ActivityPub API clients. A client that wants to let a user undo a follow needs to first find the object in following, then scroll through the outbox until they find a matching Follow activity. That might require many, many CollectionPages to be loaded. Given that the server has all the information locally, it seems easier for all parties to leave it up to the server to determine which activity to Undo.

Guidelines

For these reasons, the Postel principle suggests the following guidelines for publishers and consumers:

• Publishers should include an id for referring to activities if possible. This might require storing the activity ids for activities that make change of state, even over long periods of time.
• Publishers that do not have access to the id of the activity they are referring to should not include any id at all. Using a new or constructed id that does not match the id that consumers may have received will be difficult for those consumers to identify and ignore.
• Consumers should make an effort to process activities without an id if those activities can be identified uniquely by other properties. See below for some ways to identify different types of activities.
• Consumers may make an effort to process activities with an id that they dosn't recognize if those activities can be identified uniquely by other properties. See below for some ways to identify different types of activities.

Heuristics for identifying activities uniquely

• Like: Typically, an actor can only like one object one time. So, the actor id and object id should uniquely identify the Like activity. If there have been multiple Like/Undo Like pairs, the most recent Like is probably the one being referred to. In addition, the likes collection of the object should include at most one activity matching this actor id.
• Follow: Typically, an actor can only follow one other actor one time. So, the actor id and object id should uniquely identify the Follow activity. If there have been multiple Follow/Undo Follow pairs, the most recent Follow is probably the one being referred to.
• Block: Typically, an actor can only block one other actor one time. So, the actor id and object id should uniquely identify the Block activity. If there have been multiple Block/Undo Block pairs, the most recent Block is probably the one being referred to.