indymedia
/
epicyon
mirror of https://gitlab.com/bashrc2/epicyon
7
4
Fork 1
Code Issues 14 Releases Wiki Activity

Remove lines

merge-requests/30/head
Bob Mottram 2022-06-27 23:16:56 +01:00
parent db2de66cc6
commit 965d666f38
1 changed files with 1 additions and 68 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

69
specification/activitypub.md
View File

@ -1,15 +1,11 @@
# ActivityPub Protocol Specification
## Abstract
The ActivityPub protocol is a decentralized social networking protocol based upon the [ActivityStreams 2.0](https://www.w3.org/TR/activitystreams-core) data format. It provides a client to server API for creating, updating and deleting content, as well as a federated server to server API for delivering notifications and content.
## Status of This Document
*This document is based upon the 2018 version of the [W3C ActivityPub specification](https://www.w3.org/TR/activitypub). Any alterations are for the purposes of more accurately reflecting the actual use of the protocol, with the aim of creating less confusion for new implementors.*
# 1. Overview
ActivityPub provides two layers:
* **A server to server federation protocol** (so decentralized websites can share information)
@ -235,17 +231,14 @@ Feeling happy about things, she decides to post a public message to her follower
```
### 1.1 Social Web Working Group
ActivityPub is one of several related specifications being produced by the Social Web Working Group. Implementers interested in alternative approaches and complementary protocols should review Micropub and the overview document Social-Web-Protocols.
## 2. Conformance
As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.
The key words *MAY*, *MUST*, *MUST NOT*, *SHOULD*, and *SHOULD NOT* are to be interpreted as described in [RFC2119](https://datatracker.ietf.org/doc/html/rfc2119).
### 2.1 Specification Profiles
This specification defines two closely related and interacting protocols:
**A client to server protocol, or "Social API"**
@ -268,7 +261,6 @@ This designation applies to any implementation of the entirety of the federation
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 whether referring to a sending or receiving server in the server-to-server protocol.
## 3. Objects
Objects are the core concept around which both [ActivityStreams](https://www.w3.org/TR/activitystreams-core) and ActivityPub are built. Objects are often wrapped in Activities and are contained in streams of Collections, which are themselves subclasses of Objects. See the Activity-Vocabulary document, particularly the [Core Classes](https://www.w3.org/TR/activitystreams-vocabulary/#types); ActivityPub follows the mapping of this vocabulary very closely.
ActivityPub defines some terms in addition to those provided by [ActivityStreams](https://www.w3.org/TR/activitystreams-core). These terms are provided in the ActivityPub [JSON-LD context](http://www.w3.org/TR/json-ld/#the-context) at `https://www.w3.org/ns/activitystreams`. Implementers *SHOULD* include the ActivityPub context in their object definitions. Implementers *MAY* include additional context as appropriate.
@ -301,7 +293,6 @@ As an example, if example.com receives the activity
it should dereference the `id` both to ensure that it exists and is a valid object, and that it is not misrepresenting the object. (In this example, Mallory could be spoofing an object allegedly posted by Alice).
### 3.1 Object Identifiers
All Objects in [ActivityStreams](https://www.w3.org/TR/activitystreams-core) should have unique global identifiers. ActivityPub extends this requirement; all objects distributed by the ActivityPub protocol *MUST* have unique global identifiers, unless they are intentionally transient (short lived activities that are not intended to be able to be looked up, such as some kinds of chat messages or game notifications). These identifiers must fall into one of the following groups:
* Publicly dereferencable URIs, such as HTTPS URIs, with their authority belonging to that of their originating server. (Publicly facing content *SHOULD* use HTTPS URIs if the network being used does not have integrated transport security).
@ -318,7 +309,6 @@ The object's unique global identifier (unless the object is transient, in which
The type of the object.
### 3.2 Retrieving 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](https://datatracker.ietf.org/doc/html/rfc7231) to select the type of data to return in response to a request, but *MUST* present the [ActivityStreams](https://www.w3.org/TR/activitystreams-core) object representation in response to `application/ld+json; profile="https://www.w3.org/ns/activitystreams"`, and *SHOULD* also present the [ActivityStreams](https://www.w3.org/TR/activitystreams-core) 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](https://www.w3.org/TR/activitystreams-core) representations of a resource).
@ -326,7 +316,6 @@ Servers *MAY* implement other behavior for requests which do not comply with the
Servers *MAY* require authorization as specified in section B.1 Authentication and Authorization, and may additionally implement their own authorization rules, such as **authorized fetch**. Servers *SHOULD* fail requests which do not pass their authorization checks with the appropriate [HTTP error code](https://en.wikipedia.org/wiki/List_of_HTTP_status_codes), or the **403 Forbidden** error code where the existence of the object is considered private. An origin server which does not wish to disclose the existence of a private target *MAY* instead respond with a status code of **404 Not Found**.
### 3.3 The source property
In addition to all the properties defined by the [Activity Vocabulary](https://www.w3.org/TR/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.
@ -354,7 +343,6 @@ In general, it's best to let a user edit their original post in the same source
For example, Alyssa P. Hacker likes to post to her ActivityPub powered blog via an Emacs client she has written, leveraging [Org mode](http://orgmode.org). Later she switches to editing on her phone's client, which has no idea what `text/x-org` is or how to render it to HTML, so it provides a text box to edit the original `content` instead. A helpful warning displays above the edit area saying, "This was originally written in another markup language we don't know how to handle. If you edit, you'll lose your original source!" Alyssa decides the small typo fix isn't worth losing her nice org-mode markup and decides to make the update when she gets home.
## 4. Actors
ActivityPub actors are generally one of the [ActivityStreams Actor Types](https://www.w3.org/TR/activitystreams-vocabulary/#actor-types), but they don't have to be. For example, a [Profile](https://www.w3.org/TR/activitystreams-vocabulary/#dfn-profile) object might be used as an actor, or a type from an [ActivityStreams](https://www.w3.org/TR/activitystreams-core) extension. Actors are retrieved like any other Object in ActivityPub. Like other [ActivityStreams objects](https://www.w3.org/TR/activitystreams-vocabulary/#object-types), actors have an `id`, which is a URI. When entered directly into a user interface (for example on a login form), it is desirable to support simplified naming. For this purpose, ID normalization *SHOULD* be performed as follows:
* If the entered ID is a valid URI, then it is to be used directly.
@ -368,7 +356,6 @@ Once the actor's URI has been identified, it should be dereferenced.
ActivityPub does not dictate a specific relationship between "users" and Actors; many configurations are possible. There may be multiple human users or organizations controlling an Actor, or likewise one human or organization may control multiple Actors. Similarly, an Actor may represent a piece of software, like a bot, or an automated process. More detailed "user" modelling, for example linking together of Actors which are controlled by the same entity, or allowing one Actor to be presented through multiple alternate profiles or aspects, are at the discretion of the implementation.
### 4.1 *Actor* objects
Actor objects *MUST* have, in addition to the properties mandated by section 3.1 Object Identifiers, the following properties:
#### 4.1.1 inbox
@ -533,7 +520,6 @@ Describes an image which represents the user's profile picture (this may be a th
Describes the profile page background banner for this person.
## 5. Collections
ActivityStreams defines the collection concept; ActivityPub defines several collections with special behavior. Note that ActivityPub makes use of [ActivityStreams paging](https://www.w3.org/TR/activitystreams-core/#paging) to traverse large sets of objects.
Note that some of these collections are specified to be of type [`OrderedCollection`](https://www.w3.org/TR/activitystreams-vocabulary/#dfn-orderedcollection) specifically, while others are permitted to be either a [`Collection`](https://www.w3.org/TR/activitystreams-vocabulary/#dfn-collection) or an [`OrderedCollection`](https://www.w3.org/TR/activitystreams-vocabulary/#dfn-orderedcollection).
@ -545,7 +531,6 @@ An [`OrderedCollection`](https://www.w3.org/TR/activitystreams-vocabulary/#dfn-o
What property is used to determine the reverse chronological order is intentionally left as an implementation detail. For example, many SQL-style databases use an incrementing integer as an identifier, which can be reasonably used for handling insertion order in most cases. In other databases, an insertion time timestamp may be preferred. What is used isn't important, but the ordering of elements must remain intact, with newer items first. A property which changes regularly, such a "last updated" timestamp, should not be used.
### 5.1 Outbox
The outbox is discovered through the `outbox` property of an actor's profile. The `outbox` *MUST* be an [`OrderedCollection`](https://www.w3.org/TR/activitystreams-vocabulary/#dfn-orderedcollection).
The outbox stream contains activities the user has published, subject to the ability of the requestor to retrieve the activity (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.
@ -553,7 +538,6 @@ The outbox stream contains activities the user has published, subject to the abi
The outbox accepts HTTP POST requests, with behaviour described in Client to Server Interactions.
### 5.2 Inbox
The inbox is discovered through the `inbox` property of an actor's profile. The `inbox` *MUST* be an [`OrderedCollection`](https://www.w3.org/TR/activitystreams-vocabulary/#dfn-orderedcollection).
The inbox stream contains all activities received by the actor. 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.
@ -563,7 +547,6 @@ The server *MUST* perform de-duplication of activities returned by the inbox. Du
The inboxes of actors on federated servers accepts HTTP POST requests, with behaviour described in Delivery. Non-federated servers *SHOULD* return a 405 Method Not Allowed upon receipt of a POST request.
### 5.3 Followers Collection
Every actor *SHOULD* have a `followers` collection. This is a list of everyone who has sent a [Follow](https://www.w3.org/TR/activitystreams-vocabulary/#dfn-follow) activity for the actor, added as a side effect. This is where one would find a list of all the actors that are following the actor. The `followers` collection *MUST* be either an [`OrderedCollection`](https://www.w3.org/TR/activitystreams-vocabulary/#dfn-orderedcollection) or a [`Collection`](https://www.w3.org/TR/activitystreams-vocabulary/#dfn-collection) and *MAY* be filtered on privileges of an authenticated user or as appropriate when no authentication is given.
**Note: Default for notification targeting**
@ -571,15 +554,12 @@ Every actor *SHOULD* have a `followers` collection. This is a list of everyone w
The follow activity generally is a request to see the objects an actor creates. This makes the Followers collection an appropriate default target for delivery of notifications.
### 5.4 Following Collection
Every actor *SHOULD* 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`](https://www.w3.org/TR/activitystreams-vocabulary/#dfn-orderedcollection) or a [`Collection`](https://www.w3.org/TR/activitystreams-vocabulary/#dfn-collection) and *MAY* be filtered on privileges of an authenticated user or as appropriate when no authentication is given.
### 5.5 Liked Collection
Every actor *MAY* have a `liked` collection. This is a list of every object from all of the actor's `Like` activities, added as a side effect. The `liked` collection *MUST* be either an [`OrderedCollection`](https://www.w3.org/TR/activitystreams-vocabulary/#dfn-orderedcollection) or a [`Collection`](https://www.w3.org/TR/activitystreams-vocabulary/#dfn-collection) and *MAY* be filtered on privileges of an authenticated user or as appropriate when no authentication is given.
### 5.6 Public Addressing
In addition to ActivityStreams collections and objects, Activities may additionally be addressed to the special "public" collection, with the identifier `https://www.w3.org/ns/activitystreams#Public`. For example:
### Example 10
@ -598,7 +578,6 @@ Activities addressed to this special URI shall be accessible to all users, witho
Compacting an ActivityStreams object using the ActivityStreams JSON-LD context might result in `https://www.w3.org/ns/activitystreams#Public` being represented as simply `Public` or `as:Public` which are valid representations of the Public collection. Implementations which treat ActivityStreams objects as simply JSON rather than converting an incoming activity over to a local context using JSON-LD tooling should be aware of this and should be prepared to accept all three representations.
### 5.7 Likes Collection
Every object *MAY* have a `likes` collection. This is a list of all `Like` activities with this object as the `object` property, added as a side effect. The `likes` collection *MUST* be either an [`OrderedCollection`](https://www.w3.org/TR/activitystreams-vocabulary/#dfn-orderedcollection) or a [`Collection`](https://www.w3.org/TR/activitystreams-vocabulary/#dfn-collection) and *MAY* be filtered on privileges of an authenticated user or as appropriate when no authentication is given.
**Note**
@ -609,11 +588,9 @@ Care should be taken to not confuse the the `likes` collection with the similarl
* **likes:** May be a property of any object. This is a collection of `Like` activities referencing this object, added to the collection as a side effect of delivery to the inbox.
### 5.8 Shares/Boosts Collection
Every object *MAY* have a `shares` collection, otherwise known as `boosts` or `repeats`. This is a list of all `Announce` activities with this object as the `object` property, added as a side effect. The `shares` collection *MUST* be either an [`OrderedCollection`](https://www.w3.org/TR/activitystreams-vocabulary/#dfn-orderedcollection) or a [`Collection`](https://www.w3.org/TR/activitystreams-vocabulary/#dfn-collection) and *MAY* be filtered on privileges of an authenticated user or as appropriate when no authentication is given.
## 6. Client to Server Interactions
Activities as defined by ActivityStreams are the core mechanism for creating, modifying and sharing content within the social graph.
Client to server interaction takes place through clients posting Activities to an actor's outbox. To do this, clients *MUST* discover the URL of the actor's outbox from their profile and then *MUST* make an HTTP POST request to this URL with the Content-Type of `application/ld+json; profile="https://www.w3.org/ns/activitystreams"`. Servers *MAY* interpret a Content-Type or Accept header of `application/activity+json` as equivalent to `application/ld+json; profile="https://www.w3.org/ns/activitystreams"` for client-to-server interactions. The request *MUST* be authenticated with the credentials of the user to whom the outbox belongs. The body of the `POST` request *MUST* contain a single Activity (which *MAY* contain embedded objects), or a single non-Activity object which will be wrapped in a Create activity by the server.
@ -654,7 +631,6 @@ Attempts to submit objects to servers not implementing client to server support
HTTP caching mechanisms [RFC7234](https://datatracker.ietf.org/doc/html/rfc7234) *SHOULD* be respected when appropriate, both in clients receiving responses from servers as well as servers sending responses to clients.
### 6.1 Client Addressing
**Clients** are responsible for addressing new Activities appropriately. To some extent, this is dependent upon the particular client implementation, but clients must be aware that the server will only forward new Activities to addressees in the `to`, `bto`, `cc`, `bcc`, and `audience` fields.
The Followers Collection and/or the Public Collection are good choices for the default addressing of new Activities.
@ -702,7 +678,6 @@ The receiving outbox can then perform delivery to not only the followers of Chri
Clients submitting the following activities to an `outbox` *MUST* provide the `object` property in the activity: `Create`, `Update`, `Delete`, `Follow`, `Add`, `Remove`, `Like`, `Block`, `Undo`. Additionally, clients submitting the following activities to an outbox *MUST* also provide the `target` property: `Add`, `Remove`.
### 6.2 Create Activity
The `Create` activity is used 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.
@ -710,7 +685,6 @@ When a `Create` activity is posted, the `actor` of the activity *SHOULD* be copi
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 to be changed later without changing the `Create`'s addressing (for example via an `Update` activity).
#### 6.2.1 Object creation without a Create Activity
For client to server posting, it is possible to submit an object for creation without a surrounding activity. The server *MUST* accept a valid ActivityStreams object that isn't a subtype of `Activity` in the POST request to the outbox. The server then *MUST* attach this object as the `object` of a Create Activity. For non-transient objects, the server *MUST* attach an `id` to both the wrapping `Create` and its wrapped `Object`.
**Note**
@ -759,17 +733,14 @@ The above example could be converted to this:
```
### 6.3 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.
#### 6.3.1 Partial Updates
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. This only applies to the top-level fields of the updated object. 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.
### 6.4 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` object is presented as the response body, otherwise respond with a HTTP 404 Not Found.
A deleted object:
@ -787,55 +758,46 @@ A deleted object:
```
### 6.5 Follow Activity
The `Follow` activity is used to subscribe to the activities of another actor.
The side effect of receiving this in an **outbox** is that the server *SHOULD* add the `object` to the `actor`'s `following` Collection when and only if an `Accept` activity is subsequently received with this `Follow` activity as its object.
### 6.6 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 server, and thus they are not authorized to update it.
* the `object` is not allowed to be added to the `target` collection for some other reason, at the receiving server's discretion.
### 6.7 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 are not authorized to update it.
* the `object` is not allowed to be removed from the `target` collection for some other reason, at the receiving server's discretion.
### 6.8 Like Activity
The `Like` activity indicates the `actor` likes the `object`.
The side effect of receiving this in an **outbox** is that the server *SHOULD* add the `object` to the `actor`'s `liked` Collection.
### 6.9 Block Activity
The `Block` activity is used to indicate that the posting actor does not want another actor (defined in the `object` property) to be able to interact with objects posted by the actor posting the `Block` activity. The server *SHOULD* prevent the blocked user from interacting with any object posted by the actor.
Servers *SHOULD NOT* deliver Block Activities to their `object`.
### 6.10 Undo Activity
The `Undo` activity is used to undo a previous activity. See the Activity Vocabulary documentation on [Inverse Activities and "Undo"](https://www.w3.org/TR/activitystreams-vocabulary/#inverse). For example, `Undo` may be used to undo a previous `Like`, `Follow`, or `Block`. The undo activity and the activity being undone *MUST* both have the same actor. Side effects should be undone, to the extent possible. For example, if undoing a `Like`, any counter that had been incremented previously should be decremented appropriately.
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`.
### 6.11 Delivery
Federated servers *MUST* perform delivery on all Activities posted to the **outbox** according to outbox delivery.
### 6.12 Uploading Media
*This section is non-normative.*
Servers *MAY* support uploading document types to be referenced in activites, such as images, video or other binary data, but the precise mechanism is out of scope for this version of ActivityPub. The Social Web Community Group is refining the protocol in the [ActivityPub Media Upload report](https://www.w3.org/wiki/SocialCG/ActivityPub/MediaUpload).
## 7. Server to Server Interactions
Servers communicate with other servers and propagate information across the social graph by posting activities to actors' inbox endpoints. An Activity sent over the network *SHOULD* have an `id`, unless it is intended to be transient (in which case it *MAY* omit the `id`).
**POST** requests (eg. to the inbox) *MUST** be made with a Content-Type of `application/ld+json; profile="https://www.w3.org/ns/activitystreams"` and `GET` requests (see also section 3.2 Retrieving objects) with an Accept header of `application/ld+json; profile="https://www.w3.org/ns/activitystreams"`. Servers *SHOULD* interpret a Content-Type or Accept header of `application/activity+json` as equivalent to `application/ld+json; profile="https://www.w3.org/ns/activitystreams"` for server-to-server interactions.
@ -857,7 +819,6 @@ Servers performing delivery to the `inbox` or `sharedInbox` properties of actors
HTTP caching mechanisms [RFC7234](https://datatracker.ietf.org/doc/html/rfc7234) *SHOULD* be respected when appropriate, both when receiving responses from other servers as well as sending responses to other servers.
### 7.1 Delivery
*The following is required by federated servers communicating with other federated servers only.*
An activity is delivered to its targets (which are actors) by first looking up the targets' inboxes and then posting the activity to those inboxes. Targets for delivery are determined by checking the [ActivityStreams audience targeting](https://www.w3.org/TR/activitystreams-vocabulary/#audienceTargeting); namely, the `to`, `bto`, `cc`, `bcc`, and `audience` fields of the activity.
@ -881,7 +842,6 @@ For federated servers performing delivery to a third party server, delivery *SHO
While it is not required reading to understand this specification, it is worth noting that ActivityPub's targeting and delivery mechanism overlaps with the [Linked Data Notifications](https://www.w3.org/TR/ldn/) specification, and the two specifications may interoperably combined. In particular, the `inbox` property is the same between ActivityPub and Linked Data Notifications, and the targeting and delivery systems described in this document are supported by Linked Data Notifications. In addition to JSON-LD compacted ActivityStreams documents, Linked Data Notifications also supports a number of RDF serializations which are not required for ActivityPub implementations. However, ActivityPub implementations which wish to be more broadly compatible with Linked Data Notifications implementations may wish to support other RDF representations.
#### 7.1.1 Outbox Delivery Requirements for Server to Server
When objects are received in the outbox (for servers which support both Client to Server interactions and Server to Server Interactions), the server *MUST* target and deliver to:
* The `to`, `bto`, `cc`, `bcc` or `audience` fields if their values are individuals or Collections owned by the actor.
@ -889,7 +849,6 @@ When objects are received in the outbox (for servers which support both Client t
These fields will have been populated appropriately by the client which posted the Activity to the outbox.
#### 7.1.2 Forwarding from Inbox
**Note**: Forwarding to avoid the ghost replies problem
The following section is to mitigate the "ghost replies" problem which occasionally causes problems on federated networks. This problem is best demonstrated with an example.
@ -905,7 +864,6 @@ When Activities are received in the inbox, the server needs to forward these to
The server *MAY* filter its delivery targets according to implementation-specific rules (for example, spam filtering).
#### 7.1.3 Shared Inbox Delivery
For servers hosting many actors, delivery to all followers can result in an overwhelming number of messages sent. Some servers would also like to display a list of all messages posted publicly to the "known network". Thus ActivityPub provides an optional mechanism for serving these two use cases.
When an object is being delivered to the originating actor's followers, a server *MAY* reduce the number of receiving actors delivered to by identifying all followers which share the same sharedInbox who would otherwise be individual recipients and instead deliver objects to said `sharedInbox`. Thus in this scenario, the remote/receiving server participates in determining targeting and performing delivery to specific inboxes.
@ -915,23 +873,19 @@ Additionally, if an object is addressed to the Public special collection, a serv
Origin servers sending publicly addressed activities to `sharedInbox` endpoints *MUST* still deliver to actors and collections otherwise addressed (through `to`, `bto`, `cc`, `bcc`, and `audience`) which do not have a `sharedInbox` and would not otherwise receive the activity through the `sharedInbox` mechanism.
### 7.2 Create Activity
Receiving a `Create` activity in an `inbox` has surprisingly few side effects; the activity should appear in the actor's `inbox` and it is likely that the server will want to locally store a representation of this activity and its accompanying object. However, this mostly happens in general with processing activities delivered to an `inbox` anyway.
### 7.3 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.
### 7.4 Delete Activity
The side effect of receiving this is that (assuming the `object` is owned by the sending actor / server) the server receiving the delete activity *SHOULD* remove its representation of the `object` with the same `id`, and *MAY* replace that representation with a `Tombstone` object.
(Note that after an activity has been transmitted from an origin server to a remote server, there is nothing in the ActivityPub protocol that can *enforce* remote deletion of an object's representation).
### 7.5 Follow Activity
The side effect of receiving this in an **inbox** is that the server *SHOULD* generate either an `Accept` or `Reject` activity with the Follow as the `object` and deliver it to the `actor` of the Follow. The `Accept` or `Reject` *MAY* be generated automatically, or *MAY* be the result of user input (possibly after some delay in which the user reviews). Servers *MAY* choose to not explicitly send a `Reject` in response to a `Follow`, though implementors ought to be aware that the server sending the request could be left in an intermediate state. For example, a server might not send a `Reject` to protect a user's privacy.
In the case of receiving an `Accept` referencing this `Follow` as the object, the server *SHOULD* add the `actor` to the object actor's Followers Collection. In the case of a `Reject`, the server *MUST NOT* add the actor to the object actor's Followers Collection.
@ -941,26 +895,22 @@ In the case of receiving an `Accept` referencing this `Follow` as the object, th
Sometimes a successful `Follow` subscription may occur but at some future point delivery to the follower fails for an extended period of time. Implementations should be aware that there is no guarantee that actors on the network will remain reachable and should implement accordingly. For instance, if attempting to deliver to an actor for perhaps six months while the follower remains unreachable, it is reasonable that the delivering server remove the subscriber from the `followers` list. Timeframes and behavior for dealing with unreachable actors are left to the discretion of the delivering server.
### 7.6 Accept Activity
The side effect of receiving this in an **inbox** is determined by the type of the `object` received, and it is possible to accept types not described in this document (for example, an `Offer`).
If the `object` of an `Accept` received to an **inbox** is a `Follow` activity previously sent by the receiver, the server *SHOULD* add the `actor` to the receiver's Following Collection.
### 7.7 Reject Activity
The side effect of receiving this in an **inbox** is determined by the type of the `object` received, and it is possible to reject types not described in this document (for example, an `Offer`).
If the `object` of a `Reject` received to an **inbox** is a `Follow` activity previously sent by the receiver, this means the recipient did not approve the `Follow` request. The server *MUST NOT* add the `actor` to the receiver's Following Collection.
### 7.8 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.
### 7.9 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:
@ -968,86 +918,69 @@ Upon receipt of a `Remove` activity into the **inbox**, the server *SHOULD* remo
* the `object` is not allowed to be removed to the `target` collection for some other reason, at the receiver's discretion.
### 7.10 Like Activity
The side effect of receiving this in an **inbox** is that the server *SHOULD* increment the object's count of likes by adding the received activity to the likes collection if this collection is present.
### 7.11 Announce Activity (sharing/boosting)
Upon receipt of an `Announce` activity in an **inbox**, a server *SHOULD* increment the object's count of shares by adding the received activity to the `shares` collection if this collection is present.
**Note**
The `Announce` activity is effectively what is known as "sharing", "reposting", or "boosting" in other social networks.
### 7.12 Undo Activity
### 7.12 Undo Activity
The `Undo` activity is used to undo the side effects of previous activities. See the ActivityStreams documentation on [Inverse Activities and "Undo"](https://www.w3.org/TR/activitystreams-vocabulary/#inverse). The scope and restrictions of the `Undo` activity are the same as for the Undo activity in the context of client to server interactions, but applied to a federated context.
## A. Internationalization
*This section is non-normative.*
Building an international base of users is important in a federated network. [ActivityStreams provides tooling for internationalization of content](https://www.w3.org/TR/activitystreams-core/#naturalLanguageValues), which should be used whenever possible. However, it can be difficult for implementations to determine which [`@language` property](https://www.w3.org/TR/activitystreams-core/#defaultlangcontext) to provide for user-submitted content. The [W3C Internationalization group](https://www.w3.org/International/) provides some [guidance on language detection](https://www.w3.org/International/wiki/LanguageDetection).
## B. Security Considerations
*This section is non-normative.*
### B.1 Authentication and Authorization
ActivityPub uses authentication for two purposes; first, to authenticate clients to servers, and secondly in federated implementations to authenticate servers to each other.
Unfortunately at the time of standardization, there are no strongly agreed upon mechanisms for authentication. Some possible directions for authentication are laid out [in the Social Web Community Group Authentication and Authorization best practices report](https://www.w3.org/wiki/SocialCG/ActivityPub/Authentication_Authorization).
### B.2 Verification
Servers should not trust client submitted content, and federated servers also should not trust content received from a server other than the content's origin without some form of verification.
Servers should be careful to verify that new content is really posted by the actor that claims to be posting it, and that the actor has permission to update the resources it claims to. See also section 3. Objects Authentication and Authorization.
### B.3 Accessing localhost URIs
It is often convenient while developing to test against a process running on localhost. However, permitting requests to localhost in a production client or server instance can be dangerous. Making requests to URIs on localhost which do not require authorization may unintentionally access or modify resources assumed to be protected to be usable by localhost-only.
If your ActivityPub server or client does permit making requests to localhost URIs for development purposes, consider making it a configuration option which defaults to off.
### B.4 URI Schemes
There are many types of URIs aside from just `http` and `https`. Some libraries which handle fetching requests at various URI schemes may try to be smart and reference schemes which may be undesirable, such as `file`. Client and server authors should carefully check how their libraries handle requests, and potentially whitelist only certain safe URI types, such as `http` and `https`.
### B.5 Recursive Objects
Servers should set a limit on how deep to recurse while resolving objects, or otherwise specially handle ActivityStreams objects with recursive references. Failure to properly do so may result in denial-of-service security vulnerabilities.
### B.6 Spam
Spam is a problem in any network, perhaps especially so in federated networks. While no specific mechanism for combating spam is provided in ActivityPub, it is recommended that servers filter incoming content both by local untrusted users and any remote users through some sort of spam filter.
### B.7 Federation denial-of-service
Servers should implement protections against denial-of-service attacks from other, federated servers. This can be done using, for example, some kind of ratelimiting mechanism. Servers should be especially careful to implement this protection around activities that involve side effects. Servers *SHOULD* also take care not to overload servers with submissions, for example by using an exponential backoff strategy.
### B.8 Client-to-server ratelimiting
Servers should ratelimit API client submissions. This serves two purposes:
* It prevents malicious clients from conducting denial-of-service attacks on the server.
* It ensures that the server will not distribute so many activities that it triggers another server's denial-of-service protections.
### B.9 Client-to-server response denial-of-service
In order to prevent a client from being overloaded by oversized Collections, servers should take care to limit the size of Collection pages they return to clients. Clients should still be prepared to limit the size of responses they are willing to handle in case they connect to malicious or compromised servers, for example by timing out and generating an error.
### B.10 Sanitizing Content
Any activity field being rendered for browsers (or other rich text enabled applications) should take care to sanitize fields containing markup to prevent cross site scripting attacks.
### B.11 Not displaying bto and bcc properties
`bto` and `bcc` already must be removed for delivery, but servers are free to decide how to represent the object in their own storage systems. However, since `bto` and `bcc` are only intended to be known/seen by the original author of the object/activity, servers should omit these properties during display as well.
## C. Acknowledgements
*This section is non-normative.*
This specification comes from years of hard work and experience by a number of communities exploring the space of federation on the web. In particular, much of this specification is informed by [OStatus](https://www.w3.org/community/ostatus/wiki/Main_Page) and the [Pump API](https://github.com/pump-io/pump.io/blob/master/API.md), as pioneered by StatusNet (now GNU Social) and Pump.io. Both of those initiatives were the product of many developers' hard work, but more than anyone, Evan Prodromou has been a constant leader in this space, and it is unlikely that ActivityPub would exist in something resembling its current state without his hard work.