1.1 Social Web Working Group

2.1 Specification Profiles

This specification defines two closely related and interacting protocols:

A client to server protocol, or "Social API"

This protocol permits a client to act on behalf of a user. For example, this protocol is used by a mobile phone application to interact with the user's social stream.

A server to server protocol, or "Federation Protocol"

This protocol is used to distribute activities between users on different servers, tying them into one social graph.

All servers claiming conformance to this specification are required to implement the former protocol, and may optionally implement the latter. This gives three conformance classes:

ActivityPub conformant Client

This designation applies to any implementation of the entirety of the client portion of the client to server protocol.

ActivityPub conformant Server

This designation applies to any implementation of the entirety of the server portion of the client to server protocol.

ActivityPub conformant Federated Server

This designation applies to any implementation of the entirety of the server portion of both the client to server and federation protocols.

It is called out whenever a portion of the specification only applies to implementation of the federation protocol. In addition, whenever requirements are specified, it is called out whether they apply to the client or server (for the client-to-server protocol) or which of a pair of servers in the server-to-server protocol.

2.2 Candidate Recommendation Exit Criteria

For this specification to advance to Proposed Recommendation, there must be at least two independent, interoperable implementations of each feature. Each feature may be implemented by a different set of products. There is no requirement that all features be implemented by a single product.

• Independent implementations are developed by different parties and cannot share, reuse or derive form another qualifying implementation code which is directly pertinent to the implementation of this specification.
• Interoperability occurs between clients and servers, or between servers and other servers, when the client/server makes a request to the targeted server, and the targeted server sends the expected response, as defined by this specification.
• An implementation is an ActivityPub client, server or federated server which implements the corresponding conformance class of the specification.

For the purposes of evaluating exit criteria, each of the following is considered a feature:

• Discovering an actor's profile based on their URI.
• A client receiving authorization and subsequently submitting an activity to the authenticated actor's outbox.
• A server handling an activity submitted by an authenticated actor to their outbox and handling side client to server interaction effects appropriately.
• A federated server delivering an activity posted by a local actor to the inbox endpoints of all recipients specified in the activity, including those on other remote federated servers.
• A federated server receiving an activity to its actor's inbox, validating that the activity and any nested objects were created by their respective actors, and handling server to server side effects appropriately.

2.3 At Risk features

The Working Group has marked the following features as At Risk and may seek to advance the specification with the removal of these features if insufficient implementation experience can be gathered.

• 6. Binary Data and its associated endpoint.
• 3.3 The source property.

3.1 Object Identifiers

All Objects in [ActivityStreams] should have unique global identifiers. ActivityPub extends this requirement; all objects distributed by the ActivityPub protocol MUST have unique global identifiers; these identifiers must fall into one of the following groups:

1. Publicly dereferencable URIs, such as HTTPS URIs, with their authority belonging to that of their originating server. (Publicly facing content SHOULD use HTTPS URIs.)
2. An ID explicitly specified as the JSON null object, which implies an anonymous object (a part of its parent context)

Identifiers MUST be provided for activities posted in server to server communication. However, for client to server communication, a server receiving an object with no specified id SHOULD allocate an object ID in the user's namespace and attach it to the posted object.

All objects must have the following properties:

id

The object's unique global identifier

type

The type of the object

3.2 Methods on objects

The HTTP GET method may be dereferenced against an object's id property to retrieve the activity. Servers MAY use HTTP content negotiation as defined in [RFC7231] to select the type of data to return in response to a request, but MUST present the ActivityStreams object representation in response to application/ld+json; profile="https://www.w3.org/ns/activitystreams#", and SHOULD also present the ActivityStreams representation in response to application/activity+json as well. The client MUST specify an Accept header with the application/ld+json; profile="https://www.w3.org/ns/activitystreams#" media type in order to retrieve the activity.

Servers MAY implement other behavior for requests which do not comply with the above requirement. (For example, servers may implement additional legacy protocols, or may use the same URI for both HTML and ActivityStreams representations of a resource)

Servers MAY require authorization as specified in 9. Authentication and Authorization, and may additionally implement their own authorization rules. Servers SHOULD fail requests which do not pass their authorization checks with the appropriate HTTP error code, or the 404 Not Found error code where the existence of the object is considered private.

3.3 The source property

In addition to all the properties defined by the ActivityStreams Vocabulary, ActivityPub extends the Object by supplying the source property. The source property is intended to convey some sort of source from which the content markup was derived, as a form of provenance, or to support future editing by clients. In general, clients do the conversion from source to content, not the other way around.

The value of source is itself an object which uses its own content and mediaType fields to supply source information.

{
  "@context": "https://www.w3.org/ns/activitypub",
  "object": "Note",
  "id": "http://postparty.example/p/2415",
  "content": "<p>I <em>really</em> like strawberries!</p>",
  "source": {
    "content": "I *really* like strawberries!",
    "mediaType": "text/markdown"},
}

4.1 Actor objects

Actor objects are ActivityStreams objects which are subclasses of the Actor type. Actor objects MUST have, in addition to the properties mandated by 3.1 Object Identifiers, the following properties:

inbox

A reference to an [ActivityStreams] collection comprising of all the messages received by the actor; see 5.5 Inbox.

outbox

An [ActivityStreams] collection comprising of all the messages produced by the actor; see 5.4 Outbox.

Implementations SHOULD, in addition, provide the following properties:

url

A link to the actor's "profile web page", if it is not equal to the value of id.

following

An [ActivityStreams] collection of the actors that this actor is following.

followers

An [ActivityStreams] collection of the actors that follow this actor.

name

The preferred "nickname" or "display name" of the actor.

{
  "@context": "https://www.w3.org/ns/activitypub",
  "type": "Person",
  "id": "https://johnsmith.example.com/",
  "following": "https://johnsmith.example.com/following.json",
  "followers": "https://johnsmith.example.com/followers.json",
  "inbox": "https://johnsmith.example.com/inbox.json",
  "outbox": "https://johnsmith.example.com/feed.json",
  "preferredUsername": "johnsmith",
  "name": "John Smith",
  "summary": "Just an example guy",
  "icon": [
    "https://johnsmith.example.com/image/165987aklre4"
  ]
}

Implementations MAY, in addition, provide the following properties:

streams

A list of supplementary Collections which may be of interest.

preferredUsername

A short username which may be used to refer to the actor, with no uniqueness guarantees.

summary

A quick summary or bio by the user about themselves.

icon

A media link to the user's profile picture (this may be a thumbnail).

endpoints

A mapping of additional endpoints which may be useful either for this actor or someone referencing this actor.

The endpoints mapping MAY include the following properties:

uploadMedia

Upload endpoint URI for this user for binary data.

proxyUrl

Endpoint URI so this actor's clients may access remote ActivityStreams objects which require authentication to access.

oauthClientAuthorize

If OAuth 2.0 bearer tokens are being used for authenticating client to server interactions, this endpoint specifies a URI at which a browser-authenticated user may obtain a new access token.

provideClientKey

If Linked Data Signatures and HTTP Signatures are being used for authentication and authorization, this endpoint specifies a URI at which browser-authenticated users may authorize a client's public key for client to server interactions.

signClientKey

If Linked Data Signatures and HTTP Signatures are being used for authentication and authorization, this endpoint specifies a URI at which a client key may be signed by the actor's key for a time window to act on behalf of the actor in interacting with foreign servers.

5.1 Followers Collection

Every actor SHOULD have a followers collection. This is a list of everyone who has sent a Follow activity for the user, added as a side effect. This is where one would find a list of all the users that are following the actor. The followers collection MUST be either an OrderedCollection or a Collection.

5.2 Following Collection

Every actor MAY have a Following collection. This is a list of everybody that the actor has followed, added as a side effect. The following collection MUST be either an OrderedCollection or a Collection.

5.3 Likes Collection

Every actor MAY have a Likes collection. This is a list of every object from all of the actor's Like activities, added as a side effect. The following collection MUST be either an OrderedCollection or a Collection.

5.4 Outbox

The outbox is discovered through the outbox property of an actor's profile. The outbox MUST be an OrderedCollection.

The outbox stream contains objects the user has published, subject to the ability of the requestor to retrieve the object (that is, the contents of the outbox are filtered by the permissions of the person reading it). If a user submits a request without Authorization the server should respond with all of the Public posts. This could potentially be all relevant objects published by the user, though the number of available items is left to the discretion of those implementing and deploying the server.

The outbox accepts HTTP POST requests, with behaviour described in Client to Server Interactions.

5.5 Inbox

The inbox is discovered through the inbox property of an actor's profile. The inbox MUST be an OrderedCollection.

The inbox stream contains all objects received by the user. The server SHOULD filter content according to the requester's permission. In general, the owner of an inbox is likely to be able to access all of their inbox contents. Depending on access control, some other content may be public, whereas other content may require authentication for non-owner users, if they can access the inbox at all.

The server MUST perform de-duplication of activities returned by the inbox. Duplication can occur if an activity is addressed both to a user's followers, and a specific user who also follows the recipient user, and the server has failed to de-duplicate the recipients list. Such deduplication MUST be performed by comparing the id of the activities and dropping any activities already seen.

The inbox accepts HTTP POST requests, with behaviour described in Delivery.

5.6 Public Addressing

In addition to [ActivityStreams] collections and objects, Activities may additionally be addressed to the special "public" collection denoted by:

{
  "@context": "https://www.w3.org/ns/activitypub",
  "id": "https://www.w3.org/ns/activitypub/Public",
  "type": "Collection"
}

Activities addressed to this special URI shall be accessible to all users, without authentication.

7.1 Create Activity

The Create activity is used to when posting a new object. This has the side effect that the object embedded within the Activity (in the object property) is created.

When a Create activity is posted, the actor of the activity SHOULD be copied onto the object's attributedTo field.

A mismatch between addressing of the Create activity and its object is likely to lead to confusion. As such, a server SHOULD copy any recipients of the Create activity to its object upon initial distribution, and likewise with copying recipients from the object to the wrapping Create activity. Note that it is acceptable for the object's addressing may be changed later without changing the Create's addressing (for example via an Update activity).

{
  "@context": "https://www.w3.org/ns/activitypub",
  "type": "Note",
  "content": "This is a note",
  "published": "2015-02-10T15:04:55Z",
  "to": ["https://example.org/~john/"],
  "cc": ["https://example.com/~erik/followers"]
}

{
  "@context": "https://www.w3.org/ns/activitypub",
  "type": "Create"
  "id": "https://example.net/~mallory/87374"
  "actor": "https://example.net/~mallory",
  "object": {
    "id": "https://example.com/~mallory/note/72",
    "type": "Note",
    "attributedTo": "https://example.net/~mallory",
    "content": "This is a note",
    "published": "2015-02-10T15:04:55Z",
    "to": ["https://example.org/~john/"],
    "cc": ["https://example.com/~erik/followers"]
  },
  "published": "2015-02-10T15:04:55Z",
  "to": ["https://example.org/~john/"],
  "cc": ["https://example.com/~erik/followers"]
}

7.2 Update Activity

The Update activity is used when updating an already existing object. The side effect of this is that the object MUST be modified to reflect the new structure as defined in the update activity, assuming the actor has permission to update this object. For client to server interactions, updates are partial; rather than updating the document all at once, any key value pair supplied is used to replace the existing value with the new value. A special exception is for when the value is the json null type; this means that this field should be removed from the server's representation of the object.

Note that this behavior is for client to server interaction where the client is posting to the server only. Server to server interaction and updates from the server to the client should contain the entire new representation of the object, after the partial update application has been applied. See the description of the Update activity for server to server interactions for more details.

7.3 Delete Activity

The Delete activity is used to delete an already existing object. The side effect of this is that the server MAY replace the object with a Tombstone of the object that will be displayed in activities which reference the deleted object. If the deleted object is requested the server SHOULD respond with either the HTTP 410 Gone status code if a Tombstone is used, otherwise respond with a HTTP 404 Not Found.

A deleted object:

{
  "@context": "https://www.w3.org/ns/activitypub",
  "id": "https://example.com/~alice/note/72",
  "type": "Tombstone",
  "published": "2015-02-10T15:04:55Z",
  "updated": "2015-02-10T15:04:55Z",
  "deleted": "2015-02-10T15:04:55Z",
}

7.4 Follow Activity

The Follow activity is used to subscribe to the activities of another user.

The side effect of receiving this in an outbox is that the server SHOULD add the object to the actor's Following Collection.

7.5 Add Activity

Upon receipt of an Add activity into the outbox, the server SHOULD add the object to the collection specified in the target property, unless:

• the target is not owned by the receiving user, and thus they can't update it.
• the object is not allowed to be added to the target collection for some other reason, at the receiver's discretion.

7.6 Remove Activity

Upon receipt of a Remove activity into the outbox, the server SHOULD remove the object from the collection specified in the target property, unless:

• the target is not owned by the receiving server, and thus they can't update it.
• the object is not allowed to be added to the target collection for some other reason, at the receiver's discretion.

7.7 Like Activity

The Like activity indicates the actor likes the object.

The side effect of receiving this in an outbox is that the server MAY add the object to the actor's Likes Collection.

7.8 Block Activity

The Block activity is used to indicate that the actor does not want a user (defined in the object property) to be able to interact with objects posted by the user. The server SHOULD prevent the user from interacting with any object posted by the actor.

Servers SHOULD NOT deliver Block Activities to their object.

7.9 Undo Activity

The Undo activity is used to undo a previous activity. For example, Undo may be used to undo a previous Like or Follow. The undo activity and the activity being undone MUST both have the same author. Side effects (such as adding activities to a user's inbox after a Follow) should be undone, to the extent possible.

There are some exceptions where there is an existing and explicit "inverse activity" which should be used instead. Create based activities should instead use Delete, and Add activities should use Remove.

7.10 Delivery

Federated servers MUST perform delivery on all Activities posted to the outbox according to outbox delivery.

8.1 Targeting

Primary targeting is per the audience targeting properties from the [ ActivityStreams] specification. Notification targeting ensures the owners of all linked objects are notified of a new Activity that relates to them. Thus, the target(s) for delivery of an Activity may be:

• Primary targeting: the values of the to, cc or bcc fields (likely to include the followers collection)
• Notification targeting: the actors for all objects in the object, target, inReplyTo or tag fields

If the entry is a collection, then the server MUST dereference the collection (with the user's credentials) and discover inboxes for each item in the collection. Servers MUST limit the number of layers of indirections through collections which will be performed, which MAY be one.

Servers MUST de-duplicate the final recipient list. Servers MUST also exclude actors from the list which are the same as the actor of the Activity being notified about.

8.2 Delivery

Once the target(s) for delivery have been determined, discovery of the recipient inbox(es), and delivery, are performed according to [LDN].

In summary, the inbox is determined through the inbox property in the actor's profile. An HTTP POST request (with authorization of the submitting user) is then made to to the inbox, with the Activity as the body of the request. This Activity is added by the receiver as an item in the inbox OrderedCollection.

For federated servers performing delivery to a 3rd party server, delivery SHOULD be performed asynchronously to completion of the original activity submission request, and SHOULD additionally retry delivery to recipients if it fails due to network error.

8.3 Follow Activity

The side effect of receving this in an inbox is that the server SHOULD add the actor to the object user's Followers Collection.

8.4 Like Activity

The side effect of receving this in an inbox is that the server MAY increment the object's count of likes.

8.5 Add Activity

Upon receipt of an Add activity into the inbox, the server SHOULD add the object to the collection specified in the target property, unless:

• the target is not owned by the receiving server, and thus they can't update it.
• the object is not allowed to be added to the target collection for some other reason, at the receiver's discretion.

8.6 Remove Activity

Upon receipt of a Remove activity into the inbox, the server SHOULD remove the object from the collection specified in the target property, unless:

• the target is not owned by the receiving server, and thus they can't update it.
• the object is not allowed to be added to the target collection for some other reason, at the receiver's discretion.

8.7 Update Activity

For server to server interactions, an Update activity means that the receiving server SHOULD update its copy of the object of the same id to the copy supplied in the Update activity. Unlike the client to server handling of the Update activity, this is not a partial update but a complete replacement of the object.

The receiving server MUST take care to be sure that the Update is authorized to modify its object. At minimum, this may be done by ensuring that the Update and its object are of same origin.