ActivityPub

1.1 Social Web Working Group

2.1 仕様プロファイル

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

クライアントからサーバへのプロトコル、または"Social API"

このプロトコルにより、クライアントはユーザーを代表して動作できます。 例えばモバイルアプリがユーザーアクターのソーシャル・ストリームとやりとりするのに使われます。

サーバ間プロトコル、または"連合プロトコル"

このプロトコルは、異なるサーバ上のアクター間のアクティビティを分配し、同じソーシャルグラフにつなげます。

ActivityPub仕様は、このいずれか片方を実装した後で、もう一方もほとんど手間なく追加できるよう設計されています。 ただしサーバは片方だけ実装しても問題ありません。 このため、以下の3つの適合クラスが定義されます：

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

これはクライアントからサーバプロトコルのクライアント部全体を実装したものに該当します。

ActivityPubに準拠したサーバ

これはクライアントからサーバプロトコルのサーバ部全体を実装したものに該当します。

ActivityPubに準拠した連合サーバ

これは連合プロトコル全体を実装したものに該当します。

仕様の一部が連合プロトコルの実装時のみに適用される場合、このことが明確に示されます。 また要件指定時は、それがクライアント／サーバ（クライアントからサーバプロトコル）に該当するのか、 サーバ間プロトコルの送信サーバ／受信サーバに該当するのか明示されます。

3.1 オブジェクト識別子

[ActivityStreams]の全オブジェクトはグローバルに一意な識別子を持つべきです。 ActivityPubはこの要件を拡張し、ActivityPubプロトコルで配信される全オブジェクトは、意図的に一時的なもの（チャットやゲーム通知のように参照を意図しない短命アクティビティ）を除き、グローバルに一意な識別子が必須となります。 識別子は以下のいずれかに該当する必要があります：

1. 公開参照可能なURI、たとえばHTTPS URIで、その所有権が元サーバに属していること。 （公開向けコンテンツはHTTPS URIを使うべきです。）
2. JSONのnullとして明示的に指定されたID、つまり匿名オブジェクト（親コンテキストの一部）

サーバ間連携で配信されるアクティビティには、意図的に一時的でない限り識別子が必須です。 ただしクライアントからサーバへの通信では、outboxにID指定無しで投稿されたオブジェクトを受信するサーバは、アクターの名前空間内でIDを割り当ててオブジェクトに付与すべきです。

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

id

（一時的オブジェクトでなければ）オブジェクトのグローバル一意識別子

type

オブジェクトの種別

3.2 オブジェクトの取得

HTTP GETメソッドは、オブジェクトのidプロパティに対して発行することで、そのアクティビティを取得できます。 サーバは、[RFC7231]で定義されるHTTPコンテンツネゴシエーションを利用してもよいですが、 application/ld+json; profile="https://www.w3.org/ns/activitystreams" でリクエストされた場合は必ず ActivityStreamsオブジェクト表現を返す必要があります。 またapplication/activity+jsonでもActivityStreams表現を返すべきです。 クライアントはアクティビティを取得するため、Acceptヘッダーで application/ld+json; profile="https://www.w3.org/ns/activitystreams" メディアタイプを必ず指定しなければなりません。

上記要件に従わないリクエストへの対処として、サーバはその他動作も実装できます。 （例：追加のレガシープロトコルの実装や、同一URIでHTMLとActivityStreamsの両方の表現を使い分ける場合など）

サーバは認可をB.1 認証と認可に従って要求することもできますし、独自の認可ルールも実装可能です。 認可チェック不合格のリクエストは適切なHTTPエラーコード、または存在自体を秘匿したい場合は403 Forbiddenエラーで拒否すべきです。 存在自体が秘匿されるべきとサーバが判断した場合は、404 Not Foundでレスポンスしてもよいです。

3.3 sourceプロパティ

[Activity-Vocabulary]で定義されたすべてのプロパティに加えて、ActivityPubはObjectにsourceプロパティを拡張します。 sourceは、contentマークアップの由来を示す情報や証跡、将来の編集機能サポートなどを伝える用途のためのものです。 一般に、source→contentへの変換はクライアントが担い、逆は行いません。

sourceの値はオブジェクトで、content および mediaType フィールドを使い元情報を与えます。

{
  "@context": ["https://www.w3.org/ns/activitystreams",
               {"@language": "en"}],
  "type": "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 アクターオブジェクト

アクターオブジェクトは3.1 オブジェクト識別子の必須プロパティに加えて、以下のプロパティを必ず持たなければなりません:

inbox

アクターが受信したすべてのメッセージを含む [ActivityStreams] OrderedCollection への参照。詳しくは 5.2 Inbox を参照。

outbox

アクターが生成したすべてのメッセージを含む [ActivityStreams] OrderedCollection への参照。詳しくは 5.1 Outbox を参照。

実装は、さらに次のプロパティも提供することが望ましいです:

following

このアクターがフォローしているアクターの [ActivityStreams] コレクションへのリンク。5.4 フォロー中コレクションを参照。

followers

このアクターをフォローしているアクターの [ActivityStreams] コレクションへのリンク。5.3 フォロワーコレクションを参照。

実装は、さらに次のプロパティも任意で提供できます:

liked

このアクターが「いいね」したオブジェクトの [ActivityStreams] コレクションへのリンク。5.5 Likedコレクションを参照。

{
  "@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

補足的なコレクションの一覧（興味深いリソースかもしれません）。

preferredUsername

このアクターを参照するための短いユーザー名。一意とは限りません。

endpoints

追加の（一般的にサーバ/ドメイン単位の）エンドポイントをマッピングするJSONオブジェクト。 これらはこのアクター用、あるいはこのアクターを参照する他者用に有用です。 このマッピングはアクタードキュメントの中に値としてネストされるか、または別のJSON-LDドキュメントへのリンクでもかまいません。

endpointsマッピングには、以下のプロパティを含めてもよいです:

proxyUrl

このアクターのクライアントが認証を必要とするリモートActivityStreamsオブジェクトへアクセスできるようにするエンドポイントURI。 このエンドポイント利用時は、クライアントはx-www-form-urlencodedのidパラメータに、取得したいActivityStreamsオブジェクトのidを指定してPOSTします。

oauthAuthorizationEndpoint

クライアントからサーバ連携で OAuth 2.0ベアラートークン [RFC6749][RFC6750] を認証用途で使う場合、 ブラウザ認証済みユーザーが新しい認可を取得できるURIを指定します。

oauthTokenEndpoint

クライアントからサーバ連携で OAuth 2.0ベアラートークン [RFC6749][RFC6750] を認証用途で使う場合、 クライアントがアクセストークンを取得できるURIを指定します。

provideClientKey

Linked Data SignatureやHTTP Signatureで認証・認可を行う場合、クライアントの公開鍵認可のためのURI（クライアントからサーバー連携用、ブラウザ認証ユーザー向け）を指定します。

signClientKey

Linked Data SignatureやHTTP Signatureで認証・認可を行う場合、他サーバとのやり取りでクライアントキーが一時的にアクター代理として署名されるためのURIを指定します。

sharedInbox

公開宛やフォロワー宛アクティビティの広域配信用 のオプションエンドポイントです。 sharedInboxエンドポイントは、Public特別コレクション宛のオブジェクトを収めた 公開読み取り可能なOrderedCollectionオブジェクトとしてもあるべきです。 sharedInboxへのGETでは、Public宛でないオブジェクトは絶対に表示してはいけません。

5.1 Outbox

Outboxはアクターのプロフィールのoutboxプロパティによって発見されます。 outboxは必ず OrderedCollectionでなければなりません。

Outboxストリームはユーザーが公開したアクティビティを含みますが、これはリクエスタがそのアクティビティを取得できる権限を持っている場合に限ります（つまり、Outboxの内容は閲覧者の権限によってフィルタされます）。 ユーザーが認可無しでリクエストした場合、サーバはすべての公開宛の投稿を返すべきです。 これは当該ユーザーによる公開済みオブジェクトの全てとなる可能性もありますが、何件返すかはサーバ実装者の裁量に委ねられます。

OutboxはHTTP POSTリクエストも受け付け、その挙動はクライアントとサーバーのやりとりセクションで説明されています。

5.2 Inbox

Inboxはアクターのプロフィールのinboxプロパティによって発見されます。 inboxは必ず OrderedCollectionでなければなりません。

Inboxストリームはアクターが受信したすべてのアクティビティを含みます。 サーバはリクエスタの権限に応じて内容をフィルタするべきです。 一般的にInbox所有者はInboxの内容全てにアクセス可能ですが、アクセス制御によって他者には公開/非公開が分かれ、認証無しの利用者にはアクセスできない場合もあります。

サーバはInbox内で返すアクティビティの重複排除を必ず行う必要があります。たとえば1つのアクティビティがアクターのフォロワー全員ならびに特定のアクター（そのアクターもフォロワーである）の両方に宛てられた場合で、サーバが受取人リストの重複排除に失敗した場合などです。 この重複排除は、アクティビティのidを比較し、すでに見たものは除外することで必ず 行います。

連合サーバ上のアクターのInboxはHTTP POSTリクエストも受け付け、その挙動は配信セクションで説明されています。 非連合サーバはPOSTリクエストを受け取った場合405 Method Not Allowedを返すべきです。

5.3 フォロワーコレクション

すべてのアクターはフォロワーコレクションfollowersを持つべきです。 これは、そのアクターにFollowアクティビティを送信した全ての人の一覧であり、 副作用として追加されます。 ここでアクターをフォローしている全アクターのリストが取得できます。 followersコレクションは必ず OrderedCollection または Collection でなければならず、さらに認証ユーザの特権や認証なしの場合の適宜な条件でフィルタ可能です。

5.4 フォロー中コレクション

各アクターはfollowingコレクションを持つべきです。 これはアクターがフォローした全員のリストであり、副作用として追加されます。 followingコレクションは必ず OrderedCollection または Collection でなければならず、必要に応じて認証ユーザの特権によるフィルタや認証無し時の適切な制限が施されてもよいです。

5.5 Likedコレクション

各アクターはlikedコレクションを持ってもよいです。 これは、アクターが行った全てのLikeアクティビティの対象オブジェクトのリストであり、 副作用として追加されます。 likedコレクションは必ず OrderedCollection または Collection でなければならず、必要に応じて認証ユーザの特権によるフィルタや認証無し時の制限が加わってもよいです。

5.6 公開宛先

[ActivityStreams]コレクションやオブジェクトに加え、 アクティビティは特別な「公開（public）」コレクションhttps://www.w3.org/ns/activitystreams#Public宛てにも送ることができます。 例：

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

この特別なURI宛てのアクティビティは、すべてのユーザーが認証無しでアクセス可能でなければなりません。 実装は「public」特別コレクションへの配信を行ってはいけません； ここは実際のアクティビティを受理できません。 ただし、アクターは sharedInboxエンドポイントを持てます。 これは公開投稿やフォロワー宛投稿の効率的な共有配信用であり、詳しくは 7.1.3 共有Inbox配信 を参照してください。

5.7 Likesコレクション

すべてのオブジェクトはlikesコレクションを持ってもよいです。 これは、本オブジェクトをobjectとする全てのLikeアクティビティのリストであり、 副作用として 追加されます。 likesコレクションは必ず OrderedCollection または Collection でなければならず、必要に応じて認証ユーザの特権や認証無し時の制限などのフィルタがかかる可能性もあります。

5.8 Sharesコレクション

すべてのオブジェクトはsharesコレクションを持ってもよいです。 これは本オブジェクトをobjectプロパティとする全Announceアクティビティのリストであり、 副作用として 追加されます。 sharesコレクションは必ず OrderedCollection または Collection でなければならず、必要に応じて認証ユーザの特権や認証無し時のフィルタがかかる場合もあります。

6.1 クライアントによる宛先指定

クライアントは新しいアクティビティの宛先指定を適切に行う責任が有ります。 どのように宛て先を決定するかはクライアントの実装によりますが、サーバーが新しいアクティビティを転送するのはto、bto、cc、bcc、audienceフィールド内の宛先だけである、ということをクライアントは理解しておかなければなりません。

フォロワーコレクションや公開コレクションは、新規アクティビティのデフォルトの宛先として適切な選択肢です。

クライアントは新しいアクティビティのobject、target、inReplyTo、tagフィールドに付いているオブジェクトを調べ、それぞれのactorまたはattributedToプロパティや、さらに各オブジェクトの宛先指定プロパティを取得し、新しく作るアクティビティのtoやccフィールドに追加することが望ましいです。 クライアントは再帰的にオブジェクトをたどっても構いませんが、その際は再帰の深さ制限を設けるべきです。 （ただし、「宛先アクターのコレクション」をリスト内で個別に分解して受信者とする必要がある、という意味ではありません。）

クライアントはUIでユーザーが宛名を修正する機会を与えても構いません。

例えば、Chrisが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"
}

クライアントが生成するLikeは：

{
  "@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"
}

受信したoutboxは配信時に、Chris（Likeした本人）のフォロワーに加え、Amy本人、Amyのフォロワー、また元記事を受信したEvanにもdeliveryできます。

クライアントがoutboxへ以下のアクティビティを投稿する際はobjectプロパティを必ず指定しなければなりません： Create, Update, Delete, Follow, Add, Remove, Like, Block, Undo。 またAdd、Remove投稿時はtargetプロパティの指定も必須です。

6.2 Createアクティビティ

Createアクティビティは新しいオブジェクトを投稿するときに用います。 これには、そのアクティビティに埋め込まれた（objectプロパティ内の）オブジェクトを新規作成する副作用があります。

Createアクティビティを投稿した際は、そのactorフィールドを objectのattributedToフィールドにコピーすべきです。

Createアクティビティとそのobjectの宛先指定が一致していないと混乱のもとになります。 そのため、サーバーは初回配信時にCreateアクティビティの宛先指定をobjectにコピーしたり、逆にobjectからラップしているCreateアクティビティへコピーすべきです。 ただし、objectの宛て先が後で変更されてもCreate側の宛て先指定は変更される必要はありません（例：Updateアクティビティによる場合）。

{
  "@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"]
}

6.3 Updateアクティビティ

Updateアクティビティは、既存のオブジェクトを更新する際に使います。 これにより、objectは、更新アクティビティが定義する新しい構造で必ず書き換えられます（そのアクターに更新権限がある場合）。

6.4 Deleteアクティビティ

Deleteアクティビティは既存オブジェクトを削除するために使います。 この副作用として、サーバはobjectを、そのオブジェクトのTombstoneで置き換えても構いません（他のアクティビティが削除済みオブジェクトを参照する際に表示されます）。 削除済みオブジェクトがリクエストされた場合、サーバはTombstoneオブジェクトをレスポンスボディに返すならHTTP 410 Goneで返すべき、それ以外は404 Not Foundで返します。

削除済みオブジェクトの例：

{
  "@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"
}

6.5 Followアクティビティ

Followアクティビティは他のアクターのアクティビティ購読時に使用します。

outboxでこれを受信した場合、 サーバーはAcceptアクティビティが、このFollowアクティビティをobjectとして受信するまでは objectをactorのfollowingコレクションに追加すべきでありません。

6.6 Addアクティビティ

outboxにAddアクティビティが届いたら、サーバーは objectをtargetで指定されたコレクションに追加すべきですが、以下の場合は除きます：

• targetの所有者が受信サーバでない場合（よって更新権限が無い場合）。
• objectをtargetコレクションに追加するのが受信サーバの裁量で許可されない場合。

6.7 Removeアクティビティ

outboxにRemoveアクティビティが届いたら、サーバーは objectをtargetで指定されたコレクションから削除すべきですが、以下の場合は除きます：

• targetの所有者が受信サーバでない場合（よって更新権限が無い場合）。
• objectをそのtargetコレクションから削除するのが受信サーバの裁量で許可されない場合。

6.8 Likeアクティビティ

Likeアクティビティはactorがobjectを「いいね」したことを示します。

outboxでこれを受信した場合、 サーバーはobjectをactorのlikedコレクションに追加すべきです。

6.9 Blockアクティビティ

Blockアクティビティは、投稿者アクターが（objectフィールドで指定する）他のアクターに対し、自分の投稿したオブジェクトとやり取りできないようにしたい時に使います。 サーバーはブロックされたユーザーが投稿者アクターのオブジェクトとやり取りできないように防ぐべきです。

サーバーはBlockアクティビティをそのobjectで指定された相手へ配信すべきでありません。

6.10 Undoアクティビティ

Undoアクティビティは以前のアクティビティを取り消すために使われます。 詳細はActivity Vocabularyの 逆アクティビティと「Undo」を参照。 例えばLike、Follow、Blockなどを取り消すのに使います。 Undoアクティビティも元アクティビティも必ず同じアクターでなければなりません。 副作用は出来る限り元に戻してください。 例えばLikeのUndoであれば、以前インクリメントされたカウンターは適切にデクリメントするなど。

ただし、明示的な「逆アクティビティ」がある場合はそちらを用いるべきです。 CreateベースアクティビティならDelete、 AddアクティビティならRemoveを使ってください。

6.11 配信

連合型サーバーはoutboxに投稿されたすべてのアクティビティについて、 outbox配信に従い必ず配信しなければなりません。

7.1 配信

以降は連合型サーバー間の通信についてのみ必要となる規定です。

アクティビティはそのターゲット（アクター）のinboxを参照し、 そのinboxへ投稿することで届けられます。 ターゲットは ActivityStreamsの宛先指定 、つまりアクティビティのto、bto、cc、bcc、audienceフィールドで決定します。

inboxはまず ターゲットアクターのJSON-LD表現を取得し 、そのinboxプロパティを参照することで特定されます。 受信者がCollectionまたはOrderedCollectionの場合、サーバーは必ず（ユーザーの認証情報で）そのコレクションをデリファレンスし、各アイテムのinboxを探します。 サーバーはコレクションを通じた間接的なたどりの階層数に上限を設ける必要があり、その上限は1階層でもかまいません。

サーバーは最終的な受信者リストを重複排除しなければならず、配信対象アクティビティのactor自身はリストから除外する必要があります。すなわち、アクターは自身のアクティビティを自分自身に配信しないで下さい。

その後、（送信者認証つきで）inboxへHTTP POSTリクエストが発行され、ボディにアクティビティが含まれます。 このアクティビティは受信側によりinboxのOrderedCollectionのitemとして追加されます。 非連合サーバーのinboxに配信しようとした場合は405 Method Not Allowed が返るべきです。

連合サーバーが第三者サーバーへ配信を行う場合、配信は非同期で実施すべきです。またネットワークエラーなどで失敗した場合には配信を再試行すべきです。

注: 同一オリジン間のアクター同士の配信は任意の内部メカニズムを用いても良く、HTTPを使う必要はありません。

7.2 Createアクティビティ

inboxでCreateを受信した際の副作用は意外と少なく、そのアクティビティはアクターのinboxに現れるべきですが、サーバー側でそのアクティビティや付随オブジェクトのローカル表現を保存したくなる可能性が高いです。 ただし、このことは全般的にinboxに配信されたアクティビティを処理する際には常に行われます。

7.3 Updateアクティビティ

サーバー間通信では、Updateアクティビティを受信したサーバーは、そのidが一致する objectのコピーをUpdateで送られてきた内容で上書きすべきです。 なお、 クライアント→サーバでのUpdateアクティビティ と違い、サーバ間では部分更新ではなくオブジェクト全体が置き換えられます。

受信サーバはこのUpdateが対象objectの更新権限を持つことを厳重に確認すべきです。 最低でもUpdateとobjectが同じオリジンであることを確認しましょう。

7.4 Deleteアクティビティ

これを受信した場合の副作用は、（objectが送信アクター／サーバー所有である場合）受信側サーバは id一致のobject表現を削除すべきであり、Tombstoneオブジェクトに置換しても構いません。

（なお、ActivityPubで発信元サーバからリモートサーバにアクティビティが送信された後は、オブジェクトの表現のリモート削除強制を義務付けるものはありません。）

7.5 Followアクティビティ

inboxでこれを受信した場合、 サーバーはobjectにこのFollowアクティビティを指定した AcceptまたはRejectアクティビティを生成し、そのFollowのactorに配信すべきです。 受理Acceptも拒否Rejectも自動生成またはユーザー操作で生成できます（レビュー後の遅延発行も可）。 サーバーはFollowリクエストに明示的なRejectの送信をしない 選択も可能ですが、リクエスト送信側サーバが中間状態に留まるリスクには注意しましょう。 （例：ユーザー保護のためRejectedの通知を控える…など）

AcceptでこのFollowアクティビティがobjectとなっている場合、サーバーは actorを目的アクターのFollowers Collectionに追加すべきです。 Rejectの場合は絶対に目的アクターのFollowers Collectionに追加してはいけません。

7.6 Acceptアクティビティ

inboxでこれを受信した際の副作用はobjectの種別によって決まります。 本書で述べていない型（例: Offer）も受理可能です。

inbox宛Acceptのobjectが、以前受信者から送信されたFollowアクティビティであれば、 サーバーはactorを受信者のFollowing Collectionに追加すべきです。

7.7 Rejectアクティビティ

inboxでこれを受信した際の副作用はobjectの種別によって決まります。 本書で述べていない型（例: Offer）も拒否可能です。

inbox宛のRejectのobjectが、以前受信者から送信されたFollowアクティビティであった場合、 これは受信者がFollow要求を認可しなかったことを意味します。サーバーはactorを受信者のFollowing Collectionに絶対に追加してはいけません。

7.8 Addアクティビティ

inboxでAddアクティビティを受信した際は、サーバーは objectをtargetプロパティのコレクションに追加すべきですが、以下の場合を除きます：

• targetが受信サーバの所有物でなく、更新権限が無い場合
• objectが他理由でtargetコレクションに追加されるべきでないと、受信側が判断する場合

7.9 Removeアクティビティ

inboxでRemoveアクティビティを受信した場合、サーバーは objectをtargetプロパティのコレクションから削除すべきですが、以下の場合を除きます：

• targetが受信サーバ所有でなく、更新権限が無い場合
• objectのtargetコレクション削除が認められないと判断した場合

7.10 Likeアクティビティ

inboxでこれを受信した副作用として、サーバーは likesコレクションが有る場合は アクティビティを追加しobjectのLike数をインクリメントすべきです。

7.11 Announceアクティビティ（共有）

inboxでAnnounceアクティビティを受信した際は、サーバーは sharesコレクションが有る場合は アクティビティを追加しobjectの共有数をインクリメントすべきです。

7.12 Undoアクティビティ

Undoアクティビティは直前のアクティビティ副作用を取り消すために利用されます。 詳細はActivityStreamsの 逆アクティビティと「Undo」 を参照してください。 Undoアクティビティの効力および制約範囲は クライアントからサーバー時のUndoアクティビティ と同様ですが、ここでは連合サーバー間で適用されます。