Social Web Working Group

仕様のプロフィール

この仕様書では、密接に関係・相互作用する 2 つのプロトコルを定義します：

クライアント-サーバー間のプロトコル、すなわち「ソーシャル API」

このプロトコルは、ユーザーに代わってクライアントが動作することを可能にします。 例えば、このプロトコルは、携帯電話のアプリケーションがユーザーの actor のソーシャルストリームと接するために利用されます。

サーバー間のプロトコル、すなわち「連合プロトコル」

このプロトコルは、別々のサーバー上の actor たちによる activity を分配し、それらを同一のソーシャルグラフの内に結びつけるために利用されます。

これらのプロトコルのうちどちらか一方を実装したら、もう片方をサポートするのにわずかな努力しか必要がないように ActivityPub の仕様は設計されています。 しかしながら、依然としてサーバー側では片方のみしか実装しないこともあります。 このことは次の3つの準拠クラスを与えます：

ActivityPub に準拠したクライアント

この指定は、クライアント-サーバー間プロトコルのクライアントの部分すべての実装を持つものに当てはまります。

ActivityPub に準拠したサーバー

この指定は、クライアント-サーバー間プロトコルのサーバーの部分すべての実装を持つものに当てはまります。

ActivityPub に準拠した連合済みサーバー

この指定は、連合プロトコルのサーバーの部分すべての実装を持つものに当てはまります。

連合プロトコルの実装に仕様の一部が当てはまる場合にのみ、このように分類されて呼ばれます。 また、必要条件が指定されているときはいつでも、（クライアント-サーバー間のプロトコルについては）それらがクライアントまたはサーバーに当てはまるかどうか、 またはサーバー間のプロトコルの内で送受信を行うサーバーについて言及するかどうかで分類されて呼ばれます。

オブジェクトの識別子

[[!ActivityStreams]] のすべてのオブジェクトは、固有のグローバルな識別子を持つべきです。 ActivityPub はこの要求を拡張しています。ActivityPub プロトコルによって分配されるすべてのオブジェクトは、それらが意図的に一時的なもの（チャットメッセージやゲームの通知などの、生存期間が短くて検索されることを意図していない activity）でない場合には、固有のグローバルな識別子を持たなければいけません。 これらの識別子は、次の分類のうちどれか 1 つに入っていなければいけません。

1. public に参照外しができる、HTTPS URI などの URI で、その一存が元のサーバーに属しているようなもの （公開されているコンテンツには HTTPS URI を使うべきです）。
2. 匿名のオブジェクト（親の context の一部となるもの）を示す、明示的に JSON の null オブジェクトが指定された ID

識別子は、その activity が意図的に一時的なものでない場合には、サーバー間の伝達において送信される activity に与えられていなければなりません。 しかしながら、クライアント-サーバー間の伝達においては、サーバーに対して id が指定されていないオブジェクトが outbox に送信された場合、そのサーバーはその actor の名前空間内でオブジェクトの ID を確保し、それを送信されたオブジェクトに付与すべきです。

すべてのオブジェクトは次のプロパティを持ちます：

id

オブジェクトの固有のグローバルな識別子（オブジェクトが一時的なものであれば、id を省いてもよい）。

type

オブジェクトの型。

オブジェクトの取得

HTTP の GET メソッドは、オブジェクトの id に対して参照外しがなされ、activity を取得できます。 サーバーは [[!RFC7231]] で定められているように、HTTP コンテントネゴシエーションを利用してリクエストに対するレスポンスで返すデータの型を選択してもよいですが、application/ld+json; profile="https://www.w3.org/ns/activitystreams" に対するレスポンスでは ActivityStreams のオブジェクトの表現を渡さなければいけませんし、application/activity+json に対するレスポンスでも同様に ActivityStreams の表現を渡すべきです。 クライアントは、activity を取得するためには Accept ヘッダーに application/ld+json; profile="https://www.w3.org/ns/activitystreams" というメディアタイプを指定しなければいけません。

サーバーは、上記の要件に適合しないようなリクエストへのふるまい方を実装してもよいです （例えば、サーバーは追加でレガシーなプロトコルを実装したり、リソースの HTML および ActivityStreams における表現のために同一の URI を使ってもよい）。

サーバーは で指定されているように認可を要求してもよく、独自の認可ルールを実装することも許されます。 サーバーは、認可チェックを通らないようなリクエストについては、適切な HTTP エラーコードまたは 403 Forbidden エラーコードでオブジェクトの存在が秘密であるとみなした上で失敗させるべきです。 非公開な対象の存在を明らかにしたくないと願う配信元のサーバーは、404 Not Found ステータスコードで応答してもよいです。

source プロパティ

[[!Activity-Vocabulary]] で定められるすべてのプロパティに加えて、ActivityPub は Object に source プロパティを入れるという拡張を行っています。 source プロパティは、content のマークアップの出所となる一種のソースを伝えたり、クライアントによる将来の編集を意図したものです。 一般に、クライアントは source から content への変換を行い、その反対は行いません。

source の値そのものは、content と mediaType フィールドを持つオブジェクトであり、これでソースの情報を提供します。

          {
            "@context": ["https://www.w3.org/ns/activitystreams",
                         {"@language": "ja"}],
            "type": "Note",
            "id": "http://postparty.example/p/2415",
            "content": "<p>イチゴが <em>本当に</em> 好き！</p>",
            "source": {
              "content": "イチゴが *本当に* 好き！",
              "mediaType": "text/markdown"}
          }
        

Actor オブジェクト

Actor オブジェクトは で義務付けられたプロパティに加えて、次のプロパティを持たなければなりません。

inbox

actor が受け取ったすべてのメッセージを含むような [[!ActivityStreams]] の OrderedCollection への参照。詳細は

outbox

actor が生み出したすべてのメッセージを含むような [[!ActivityStreams]] の OrderedCollection への参照。詳細は

実装は、これに加えて次のプロパティを提供すべきです。

following

この actor がフォローしている actor で構成される [[!ActivityStreams]] の collection へのリンク。詳細は

followers

この actor をフォローしている actor で構成される [[!ActivityStreams]] の collection へのリンク。詳細は

実装は次のプロパティを提供してもよいです。

liked

この actor が like したオブジェクトで構成される [[!ActivityStreams]] の collection へのリンク。詳細は

{
  "@context": ["https://www.w3.org/ns/activitystreams",
               {"@language": "ja"}],
  "type": "Person",
  "id": "https://kenzoishii.example.com/",
  "following": "https://kenzoishii.example.com/following.json",
  "followers": "https://kenzoishii.example.com/followers.json",
  "liked": "https://kenzoishii.example.com/liked.json",
  "inbox": "https://kenzoishii.example.com/inbox.json",
  "outbox": "https://kenzoishii.example.com/feed.json",
  "preferredUsername": "kenzoishii",
  "name": "石井健蔵",
  "summary": "この方はただの例です",
  "icon": [
    "https://kenzoishii.example.com/image/165987aklre4"
  ]
}
        

実装は、これに加えて次のプロパティを提供してもよいです。

streams

関心があるかもしれない補足的な collection のリスト。

preferredUsername

固有性の保障はないが、actor へ言及するときに使える短いユーザーネーム。

endpoints

この actor や、この actor を参照する人にとって助けとなるかもしれない、追加の（典型的にはサーバー・ドメイン規模の）エンドポイントを表す JSON オブジェクト。 これは actor を表すドキュメントの中で値として含むこともできるし、これらのプロパティを含む JSON-LD ドキュメントへのリンクとすることもできる。

endpoints は、次のプロパティを含んでもよいです。

proxyUrl

actor のクライアントがこのエンドポイント URI によって、アクセスに認証を必要とする外部の ActivityStreams のオブジェクトにアクセスできるようになります。 このエンドポイントを使うには、クライアントは x-www-form-urlencoded な id パラメータに、要求する ActivityStreams オブジェクトの id を設定して POST します。

oauthAuthorizationEndpoint

OAuth 2.0 bearer tokens [[RFC6749]] [[RFC6750]] がクライアント-サーバー間のやりとりの認証で使われているとき、このエンドポイントはブラウザで認証されたユーザーに新しく認可の許可を与えるための URI を指定します。

oauthTokenEndpoint

OAuth 2.0 bearer tokens [[RFC6749]] [[RFC6750]] がクライアント-サーバー間のやりとりの認証で使われているとき、このエンドポイントはクライアントがアクセストークンを取得するための URI を指定します。

provideClientKey

Linked Data 署名と HTTP 署名が認証および認可に使われているとき、このエンドポイントはブラウザで認証されたユーザーがクライアント-サーバー間のやりとりのためのクライアントの公開鍵を認可するための URI を指定します。

signClientKey

Linked Data 署名と HTTP 署名が認証および認可に使われているとき、このエンドポイントはクライアントが actor の代わりに外部のサーバーとやりとりするために、クライアントの鍵を actor の鍵によってある一定期間だけ署名するための URI を指定します。

sharedInbox

公開された activity や、フォロワーに送信される activity を幅広く配信するために使われる任意のエンドポイント。 sharedInbox エンドポイントは特殊な Public collection 宛てのオブジェクトを含む、誰でも読める OrderedCollection オブジェクトでもあるべきです。 sharedInbox エンドポイントから読まれるオブジェクトとして Public エンドポイント宛てでないようなものは提供してはいけません。

name, preferredUsername, summary のような自然言語の値を含むプロパティは、ActivityStreams で定義される自然言語のサポートを活用できます。

Outbox

The outbox is discovered through the outbox property of an actor's profile. The outbox MUST be an 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.

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

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 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.

The server MUST perform de-duplication of activities returned by the inbox. Duplication can occur if an activity is addressed both to an actor's followers, and a specific actor who also follows the recipient actor, 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 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.

Followers Collection

Every actor SHOULD have a followers collection. This is a list of everyone who has sent a 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 or a Collection and MAY be filtered on privileges of an authenticated user or as appropriate when no authentication is given.

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.

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 or a Collection and MAY be filtered on privileges of an authenticated user or as appropriate when no authentication is given.

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 or a Collection and MAY be filtered on privileges of an authenticated user or as appropriate when no authentication is given.

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:

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

Activities addressed to this special URI shall be accessible to all users, without authentication. Implementations MUST NOT deliver to the "public" special collection; it is not capable of receiving actual activities. However, actors MAY have a sharedInbox endpoint which is available for efficient shared delivery of public posts (as well as posts to followers-only); see .

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 or a Collection and MAY be filtered on privileges of an authenticated user or as appropriate when no authentication is given.

Shares Collection

Every object MAY have a shares collection. 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 or a Collection and MAY be filtered on privileges of an authenticated user or as appropriate when no authentication is given.

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.

Clients SHOULD look at any objects attached to the new Activity via the object, target, inReplyTo and/or tag fields, retrieve their actor or attributedTo properties, and MAY also retrieve their addressing properties, and add these to the to or cc fields of the new Activity being created. Clients MAY recurse through attached objects, but if doing so, SHOULD set a limit for this recursion. (Note that this does not suggest that the client should "unpack" collections of actors being addressed as individual recipients).

Clients MAY give the user the chance to amend this addressing in the UI.

For example, when Chris likes the following article by Amy:

  {
    "@context": ["https://www.w3.org/ns/activitystreams",
                 {"@language": "en-GB"}],
    "id": "https://rhiaro.co.uk/2016/05/minimal-activitypub",
    "type": "Article",
    "name": "Minimal ActivityPub update client",
    "content": "Today I finished morph, a client for posting ActivityStreams2...",
    "attributedTo": "https://rhiaro.co.uk/#amy",
    "to": "https://rhiaro.co.uk/followers/",
    "cc": "https://e14n.com/evan"
  }
        

the like is generated by the client as:

  {
    "@context": ["https://www.w3.org/ns/activitystreams",
                 {"@language": "en"}],
    "type": "Like",
    "actor": "https://dustycloud.org/chris/",
    "summary": "Chris liked 'Minimal ActivityPub update client'",
    "object": "https://rhiaro.co.uk/2016/05/minimal-activitypub",
    "to": ["https://rhiaro.co.uk/#amy",
           "https://dustycloud.org/followers",
           "https://rhiaro.co.uk/followers/"],
    "cc": "https://e14n.com/evan"
  }
        

The receiving outbox can then perform delivery to not only the followers of Chris (the liker), but also to Amy, and Amy's followers and Evan, both of whom received the original article.

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.

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.

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).

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

        {
          "@context": "https://www.w3.org/ns/activitystreams",
          "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",
                   "https://www.w3.org/ns/activitystreams#Public"]
          },
          "published": "2015-02-10T15:04:55Z",
          "to": ["https://example.org/~john/"],
          "cc": ["https://example.com/~erik/followers",
                 "https://www.w3.org/ns/activitystreams#Public"]
        }
        

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.

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:

          {
            "@context": "https://www.w3.org/ns/activitystreams",
            "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"
          }
        

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.

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.

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.

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.

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.

Undo Activity

The Undo activity is used to undo a previous activity. See the Activity Vocabulary documentation on Inverse Activities and "Undo". 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.

Delivery

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

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; namely, the to, bto, cc, bcc, and audience fields of the activity.

The inbox is determined by first retrieving the target actor's JSON-LD representation and then looking up the inbox property. If a recipient is a Collection or OrderedCollection, 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. That is, actors shouldn't have their own activities delivered to themselves.

What to do when there are no recipients specified is not defined, however it's recommended that if no recipients are specified the object remains completely private and access controls restrict the access to object. If the object is just sent to the "public" collection the object is not delivered to any actors but is publicly viewable in the actor's outbox.

An HTTP POST request (with authorization of the submitting user) is then made 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. Attempts to deliver to an inbox on a non-federated server SHOULD result in a 405 Method Not Allowed response.

For federated servers performing delivery to a third party server, delivery SHOULD be performed asynchronously, and SHOULD additionally retry delivery to recipients if it fails due to network error.

Note: Activities being distributed between actors on the same origin may use any internal mechanism, and are not required to use HTTP.

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 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.

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.

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.

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).

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.

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.

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.

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.

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 removed to the target collection for some other reason, at the receiver's discretion.

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.

Announce Activity (sharing)

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.

Undo Activity

The Undo activity is used to undo the side effects of previous activities. See the ActivityStreams documentation on Inverse Activities and "Undo". 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.