ActivityPub

1.1 Social Web Working Group

2.1 仕様プロファイル

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

クライアント-サーバ間プロトコル(ソーシャル API)

このプロトコルは、クライアントがユーザーに代わって行動することを認める。例えば、このプロトコルはあるユーザーのactorのソーシャルストリームに 相互作用するモバイルフォンアプリケーションで使われる。

サーバ-サーバ間プロトコル(連合プロトコル)

このプロトコルは、異なるサーバにあり、同じソーシャルグラフ上で 結びつけられているactorの間でアクティビティを配布するために使われる。

ActivityPub 仕様は、一旦これらのどちらかのプロトコルが実装されると、 もう片方への対応はほとんど追加の作業が不要であるように設計されている。しかし、それでもサーバはもう片方なしで片方を実装できる。これは三つの準拠クラスを与える:

ActivityPub 準拠クライアント

この指定は、クライアント-サーバプロトコルのクライアント部分を全て 実装しているものに適用される。

ActivityPub 準拠サーバ

この指定は、クライアント-サーバプロトコルのサーバ部分を全て 実装しているものに適用される。

ActivityPub 準拠連合サーバ

この指定は、連合プロトコルを全て実装しているものに 適用される。

これは、仕様のうち、連合プロトコルの実装にのみ適用されるものに付記される。さらに、要件が指定される場合、(クライアント-サーバプロトコルでは) クライアントとサーバのどちらに適用されるかが明示され、 サーバ間プロトコルでは送信サーバと受信サーバのどちらを参照するかが 明示される。

3.1 オブジェクト識別子

[ActivityStreams] の全てのオブジェクトはユニークなグローバル識別子を 付けるべきとされている。ActivityPub はこの要求を拡張する; ActivityPub プロトコルで配布される全てのオブジェクトは、 意図的に一時的なもの(ある種のチャットメッセージやゲーム通知のような、短命の アクティビティで検索されることを意図していないもの)でない限り、 ユニークなグローバル識別子を持たなければならない(MUST)。これらの識別子は以下のグループのどれか一つでなければならない:

1. HTTPS URI のような、参照先をパブリックに取得可能な URI で、 その権限が発信元サーバに帰属するもの。(公開用のコンテンツは HTTPS URI を使うべきである(SHOULD)。)
2. 明示的に JSON null オブジェクトとして指定された ID; この場合は無名オブジェクト(親コンテキストの一部) を意味する。

識別子は、アクティビティが意図的に一時的なものでない限り、 サーバからサーバへの通信で投稿するアクティビティでは 提供しなければならない(MUST)。しかし、クライアントからサーバへの通信では、id の指定なしに outbox に投稿されたオブジェクトを受信したサーバは、 そのアクターの名前空間の ID を割り当て、投稿されたオブジェクトに それを添付するべきである(SHOULD)。

全てのオブジェクトは以下の属性を持つ:

id

オブジェクトのユニークなグローバル識別子(オブジェクトが一時的なものの場合を 除く; この場合 id は省略しても良い(MAY))。

type

オブジェクトの型。

3.2 オブジェクトの取得

アクティビティを取得するために、 オブジェクトの id 属性に対して HTTP GET メソッドを使うことがある。リクエストに対するレスポンスとして返すデータの種類を選択するために、 サーバは [RFC7231] で定義されている HTTP content negotiation を使っても良い(MAY)が、 application/ld+json; profile="https://www.w3.org/ns/activitystreams" への返答として ActivityStreams オブジェクト表現を表現しなければならず(MUST)、 application/activity+json への返答としても ActivityStreams 表現を表現するべきである(SHOULD)。クライアントはアクティビティを取得するために Accept ヘッダに application/ld+json; profile="https://www.w3.org/ns/activitystreams" メディアタイプを指定しなければならない(MUST)。

サーバは前述する要求に従わないリクエストに対して他の振る舞いを 実装しても良い(MAY)。(例えば、サーバは追加でレガシーなプロトコルを実装しても良いし、 あるリソースの HTML 表現と ActivityStreams 表現で同じ URI を使っても良い。)

サーバは B.1 認証と認可 で指定された認証を要求したり、 独自の認証規則を実装したりしても良い(MAY)。サーバは、認証チェックを通過しなかったリクエストに対して適切な HTTP エラーコードか、 オブジェクトの存在がプライベートなものと考えられる場合は 403 Forbidden エラーコードで失敗するべきである(SHOULD)。プライベートターゲットの存在を公開したくない発信元サーバは、 代わりに 404 Not Found のステータスコードを返しても良い(MAY)。

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 Actor オブジェクト

Actor オブジェクトは、3.1 Object Identifiers で強制される属性に加えて、 以下の属性を持たなければならない(MUST):

inbox

このアクターが受け取った全てのメッセージから成る [ActivityStreams] OrderedCollection への参照; 5.2 Inbox を参照のこと。

outbox

このアクターによって作成された全てのメッセージから成る [ActivityStreams] OrderedCollection; 5.1 Outbox を参照のこと。

実装は、これに加えて、以下の属性を提供するべきである(SHOULD):

following

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

followers

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

実装は以下の属性を提供しても良い(MAY):

liked

このアクターが好んでいるオブジェクトを示す [ActivityStreams] コレクションへのリンク; 5.5 Liked 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"
  ]
}

実装は、これに加えて、以下の属性を提供しても良い(MAY):

streams

関心のある補助的な Collection のリスト。

preferredUsername

アクターを参照するために使われる短いユーザー名; ユニーク性は保証されない。

endpoints

このアクターまたはこのアクターを参照する誰かにとって有用かもしれない (典型的にはサーバ/ドメイン単位の) 追加のエンドポイントをマッピングした json オブジェクト。このマッピングはアクター文書の中で値としてネストしても良いし、 これらの属性を持つ JSON-LD 文書へのリンクでも良い。

endpoints マッピングは以下の属性を含んでいても良い(MAY):

proxyUrl

アクターのクライアントが、 アクセスするのに認証が必要なリモート ActivityStreams にアクセスするのに 使われる エンドポイント URI。このエンドポイントを使うには、クライアントは 要求する ActivityStreams オブジェクトの id の値を持つ x-www-form-urlencoded id 引数を 投稿する。

oauthAuthorizationEndpoint

OAuth 2.0 bearer トークン [RFC6749] [RFC6750] が クライアントからサーバへの通信 の 認証として使われる場合、 このエンドポイントは、ブラウザ認証ユーザーが新しい認証グラントを得るための URI を指定する。

oauthTokenEndpoint

OAuth 2.0 bearer トークン [RFC6749] [RFC6750] が クライアントからサーバへの通信 の 認証として使われる場合、 このエンドポイントは、クライアントがアクセストークンを得るための URI を指定する。

provideClientKey

Linked Data Signatures と HTTP Signatures が認証と認可として使われている場合、 このエンドポイントはブラウザ認証ユーザーが クライアントからサーバへの通信 の ためのクライアントの公開鍵を認証する URI を指定する。

signClientKey

Linked Data Signatures と HTTP Signatures が認証と認可として使われている場合、 このエンドポイントは 外部サーバと通信する際にアクターに代わって動作するタイミングのための、 actor のキーによって署名されるクライアントキーの URI を指定する。

sharedInbox

パブリックに宛先指定された アクティビティとフォロワーによって送られたアクティビティを 広く配布するために使われる オプションのエンドポイント。publicInbox エンドポイントは、 パブリックに読み込み可能な、 Public 特殊コレクションを示す オブジェクトを含む OrderedCollection オブジェクトであるべきである(SHOULD)。sharedInbox エンドポイントからの読み込みは、 Public エンドポイントにアドレス指定されていないオブジェクトを 表現してはならない(MUST NOT)。

5.1 Outbox

outbox は アクター のプロファイルの outbox プロパティを使って発見される。outbox は OrderedCollectionでなければならない(MUST)。

outboxストリームは、要求者がアクティビティを取得する能力があるという前提で、 ユーザーが発行したアクティビティを含む (つまり、outbox の内容はそれを読む人の権限によってフィルタされる)。ユーザーが Authorization なしでリクエストを投稿した場合、 サーバは全ての Public 投稿を 応答するべきである。これは場合によってはそのユーザーによって発行された、全ての関連する オブジェクトとなるかもしれないが、 利用可能なアイテムの数はサーバの実装とデプロイの自由裁量に任されている。

outbox は HTTP POST リクエストを受け付ける; その振る舞いは クライアントからサーバへの通信に 記述されている。

5.2 Inbox

inbox は アクター のプロファイルの inbox プロパティを使って発見される。inbox は OrderedCollection でなければならない(MUST)。

inbox ストリームはアクターが受信した全てのアクティビティを含む。サーバは要求者の権限に応じてコンテンツをフィルタリングするべきである(SHOULD)。一般的に、inbox の所有者は その inbox のコンテンツ全てにアクセスできる。inbox にアクセスできる場合でも、アクセス制御に依存して、その他のコンテンツの 一部はパブリックで、一方その他のコンテンツは非所有者のユーザーは認証を 要求されるかもしれない。

サーバは inbox に返されたアクティビティの重複解消を 実行しなければならない(MUST)。重複は、あるアクティビティがあるアクターのフォロワーと、受信アクターを フォローしている特定のアクターの両方にアドレス指定され、 サーバが受信リストの重複解消に失敗したときに起こる。このような重複解消は、アクティビティの id を比較して、 既に読んだアクティビティを落とす形で行われなければならない(MUST)。

連合サーバ上のアクターの inbox は HTTP POST リクエストを受け付ける; その振る舞いは 配送 に記述されている。非連合サーバは POST リクエストを受け取った場合は 405 Method Not Allowed を 返すべきである(SHOULD)。

5.3 Followers コレクション

各 アクター は followers コレクションを 持つべきである(SHOULD)。これはこのアクターに Follow アクティビティを送信したときに 副作用 として追加された送信者の一覧である。これは誰かがあるアクターをフォローしている全てのユーザーの一覧を 見つける場所である。followers コレクションは OrderedCollection または Collection でなければならず(MUST)、 認証されたユーザーの権限や、認証がない場合は適切な形でフィルタリングしても 良い(MAY)。

5.4 Following コレクション

各アクターは following コレクションを持つべきである(SHOULD)。これは 副作用 として追加された、 このアクターがフォローした相手の一覧である。following コレクションは OrderedCollection または Collection でなければならず(MUST)、 認証されたユーザーの権限や、認証がない場合は適切な形でフィルタリングしても 良い(MAY)。

5.5 Liked コレクション

各アクターは liked コレクションを持っても良い(MAY)。これは 副作用 として追加された、 このアクターの全ての Like のオブジェクトの一覧である。liked コレクションは OrderedCollection または Collection でなければならず(MUST)、 認証されたユーザーの権限や、認証がない場合は適切な形でフィルタリングしても 良い(MAY)。

5.6 Public アドレス指定

[ActivityStreams] コレクションとオブジェクトに加えて、 Activity は追加で特殊な「パブリック」コレクションを宛先に指定できる; これは識別子 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 を宛先に指定された Activity は全てのユーザーから 認証なしにアクセスできる。実装者は「パブリック」特殊コレクションへ配送してはならない(MUST NOT); これは実際のアクティビティを受信する能力を持たない。しかし、アクターはパブリックな投稿の効率的な共有配送のために利用可能である sharedInbox エンドポイントを 持ってもよい(MAY); 7.1.3 共有 inbox への配送 を参照のこと。

5.7 Likes コレクション

各オブジェクトは likes コレクションを持ってもよい(MAY)。これは 副作用 として追加された、 このオブジェクトを object 属性として持つ全ての Like アクティビティの一覧である。likes コレクションは OrderedCollection または Collection でなければならず(MUST)、 認証されたユーザーの権限や、認証がない場合は適切な形でフィルタリングしても 良い(MAY)。

5.8 Shares コレクション

各オブジェクトは shares コレクションを持っても良い(MAY)。これは、このオブジェクトを object 属性に含む全ての Announce アクティビティの一覧で、 副作用 として追加されたものである。shares コレクションは OrderedCollection または Collection でなければならず(MUST)、 認証ユーザーの権限によってや、認証が与えられなかったときに適切になるように、 フィルタリングしても良い(MAY)。

6.1 クライアントアドレス指定

クライアント は、 新しい Activity を適切にアドレス指定することに責任を持つ。これはある程度特定のクライアントの実装に依存するが、 サーバは新しい Activity を to, bto, cc, bcc, audience フィールドのアドレス指定先にのみ 転送する、ということをクライアントは認識しておかなければならない。

Followers コレクション と Public コレクション は、 新しい Activity のデフォルトの宛先として良い選択肢である。

クライアントは、 object, target, inReplyTo, tag フィールドで 新しい Activity に添付されたオブジェクトを見るべきであり(SHOULD)、 その actor や attributedTo 属性を取得して、 また、そのアドレス指定属性を取得して、 作成された新しい Activity の to または cc フィールドに追加してもよい(MAY)。クライアントは添付されたオブジェクトを再帰しても良い(MAY)が、 そうする場合はこの再帰に制限を設定するべきである(SHOULD)。(これは、クライアントがアドレス指定されたアクターのコレクションを個々の宛先として 「展開」することを提案しているのではないことに注意すること。)

クライアントは UI でユーザーに宛先を変更する機会を与えても良い(MAY)。

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

クライアントによって生成される「いいね」は:

{
  "@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 のフォロワーだけでなく、 元の記事を受け取っている Amy、Amy のフォロワー、Evan にも 配送できる。

以下のアクティビティを outbox に投稿するクライアントは、 アクティビティに object 属性も提供しなければならない(MUST): Create, Update, Delete, Follow, Add, Remove, Like, Block, Undo。さらに、以下のアクティビティを outbox へ投稿するクライアントは、 target 属性も提供しなければならない(MUST): Add, Remove。

6.2 Create アクティビティ

Create アクティビティは新しいオブジェクトを投稿するときに使われる。これは、Activity の中に(object 属性として)埋め込まれている オブジェクトが作成されるという副作用がある。

Create アクティビティが投稿されたとき、アクティビティの actor は object の attributedTo フィールドにコピーされるべきである(SHOULD)。

Create アクティビティとその object のアドレス指定の 不一致はおそらく混乱を引き起こす。従って、サーバは初期の配送時に Create アクティビティの宛先を その object にコピーするべきであり(SHOULD)、 同様に object からラップしている Create アクティビティに コピーするべきである(SHOULD)。Create のアドレス指定を変更することなく (例えば Update アクティビティで) object のアドレス指定を変更することは 受け入れられることに注意すること。

{
  "@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 は Update アクティビティで定義されている新しい構造を 反映した形で修正されなければならない(MUST)。

6.4 Delete アクティビティ

Delete アクティビティは、既に存在するオブジェクトを 削除するために使われる。この副作用として、サーバは object を、 削除されたオブジェクトを参照するアクティビティで表示される Tombstone のオブジェクトに置き換えても良い(MAY)。削除されたオブジェクトが要求された場合、サーバは、 レスポンスボディとして Tombstone オブジェクトが表現されている場合は HTTP 410 Gone ステータスを、 さもなければ HTTP 404 Not Found ステータスを返すべきである (SHOULD)。

削除されたオブジェクト:

{
  "@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 に受信した場合の副作用として、 サーバは、この Follow アクティビティをオブジェクトとした Accept アクティビティを引き続いて受信した場合にのみ、 actor の following コレクション に object を追加するべきである(SHOULD)。

6.6 Add アクティビティ

Add アクティビティを outbox に受け取ったとき、 以下の場合を除いて、サーバは object を target プロパティで指定されたコレクションに追加するべきである(SHOULD):

• target が受信サーバによって所有されておらず、従ってこれを更新する権限がない。
• 受信サーバの裁量により、なんらかの理由によって object を target コレクションに追加することを 認められていない。

6.7 Remove アクティビティ

outbox に Remove アクティビティを受信すると、 サーバは次の場合を除いて、 target 属性で指定されたコレクションから object を削除するべきである(SHOULD)。

• target が受信サーバによって所有されておらず、従ってこれを更新する権限がない。
• object が、受信サーバの裁量により、何らかの他の理由で target から削除することを認められていない。

6.8 Like アクティビティ

Like アクティビティは アクター が object を好んでいることを示す。

これを outbox に受信したときの副作用として、 サーバは actor の liked コレクション に この object を追加するべきである(SHOULD)。

6.9 Block アクティビティ

Block アクティビティは、投稿したアクターは (object属性で定義された)アクターが Block アクティビティを投稿したアクターによって投稿された オブジェクトと相互作用出来ることを望まないことを示すために使われる。サーバはブロックしたユーザーと、このアクターによって投稿された任意の オブジェクトとの相互作用を防止するべきである (SHOULD)。

サーバは Block アクティビティをその object に 配送するべきではない(SHOULD NOT)。

6.10 Undo アクティビティ

Undo アクティビティは以前のアクティビティを取り消すときに使われる。Activity Vocabulary 文書の Inverse Activities and "Undo" を参照のこと。例えば、Undo は以前の Like, Follow, Block のいずれかの 取り消しのために使われる。Undo アクティビティと取り消されるアクティビティはどちらも同じ actor を 持っていなければならない(MUST)。副作用として、できるだけ広範囲に取り消しを行うべきである。例えば、もし Like を取り消すと、その前にインクリメントされた カウンタは適切にデクリメントされるべきである。

既存の明示的な「逆アクティビティ」を代わりに使うべき例外がある。Create ベースのアクティビティは Delete を、 Add アクティビティは Remove を使うべきである。

6.11 配送

連合サーバは outbox に投稿された全ての Activity を outbox配送 に従って配送を実行しなければならない(MUST)。

7.1 配送

以下は他の連合サーバと通信する連合サーバのみに要求される。

アクティビティは、まずターゲット(これはアクター)の inboxを探して、それからそのinboxにアクティビティを投稿することで配送される。配送するターゲットは、 ActivityStreams audience targeting をチェックすることで決定される; つまり、アクティビティの to, bto, cc, bcc, audience フィールドである。

inbox はまず ターゲットアクターのJSON-LD表現を取得し、 それから inbox 属性を探すことで決定される。宛先が Collection または OrderedCollection の場合、 サーバはコレクションを(ユーザーの認証情報と共に)展開し、コレクションの それぞれの要素の inbox を発見しなければならない(MUST)。サーバはコレクションの展開を実行する層の数を制限しなければならない(MUST); これは 1 でもよい(MAY)。

サーバは最終的な宛先リストの重複を解消しなければならい(MUST)。サーバはまた、通知される Activity の アクター と同じアクターをリストから除去しなければならない(MUST)。つまり、ユーザーは自分のアクティビティを自分に配送することはできない。

(投稿ユーザーの認証付きの) HTTP POST リクエストは、 アクティビティをリクエストのボディとして inboxに行われる。このアクティビティは受信者によって inbox OrderedCollection の item として追加される。非連合サーバの inbox へ配送しようとする試みは 405 Method Not Allowed レスポンスを返すべきである(SHOULD)。

連合サーバがサードパーティーサーバへ配送を実行する場合には、 配送は非同期に実行されるべきであり(SHOULD)、 これがネットワークエラーによって失敗した場合は受信者への配送を 再試行するべきである(SHOULD)。

注記: 同じ origin のアクター間で 配送される Activity は任意の内部機構を使ってもよく、HTTP を使うことは要求されない。

7.2 Create アクティビティ

inbox に Create アクティビティを受信したときには、 意外にもほとんど副作用はない; このアクティビティはアクターの inbox に現れるべきで、 サーバはおそらくこのアクティビティとそれに添付されているオブジェクトの表現を ローカルに保管したいはずである。しかし、これはとにかく inbox にアクティビティが配送されたときに ほとんど一般的に処理されることである。

7.3 Update アクティビティ

サーバからサーバへの通信では、 Update アクティビティは、 同じ id の object のコピーを、 Update アクティビティの中に供給されているコピーで 更新するべきである(SHOULD)。 Update アクティビティのクライアントからサーバへの扱い と異なり、 これは部分更新ではなくオブジェクトの完全な置き換えである。

受信サーバは Update がその object を修正する権限があることを 確認することに注意しなければならない(MUST)。最小限として、これは Update とその object が同じ送信元であることを確認することで行われる。

7.4 Delete アクティビティ

(object は送信したアクター/サーバが所有していると仮定して) これを受信したときの副作用として、 Delete アクティビティを受信したサーバは 同じ id を持つ object の表現を削除するべき(SHOULD)で、 表現を Tombstone オブジェクトに置き換えても良い(MAY)。

(あるアクティビティが発信元サーバからリモートサーバに転送された後、 オブジェクトの表現をリモートをリモートで削除することを 強制する 方法は、ActivityPub プロトコルにはないということに注意すること。)

7.5 Follow アクティビティ

これを inbox に受信したときの副作用として、 サーバは、この Follow を object に設定した Accept または Reject アクティビティを生成し、 Follow した アクター に配送するべきである(SHOULD)。Accept や Reject は自動的に生成しても良い(MAY)し、 (おそらくはユーザーの確認のための多少の遅延の後)ユーザー入力の 結果としてもよい(MAY)。サーバは Follow への応答として明示的に Reject を 送らないという選択をしてもよい(MAY)が、実装者はリクエストを送信したサーバが 中間的な状態のままになるかもしれないことに注意するべきである。例えば、サーバはユーザーのプライバシーを守るために Reject を 送信しないかもしれない。

この Follow を object として参照している Accept を 受信する場合、サーバは object の actor の Followers コレクション に アクター を追加するべきである(SHOULD)。Reject の場合、object の actor の Followers コレクション に actor を 追加してはならない(MUST NOT)。

7.6 Accept アクティビティ

これを inbox に受信した場合の副作用は、受信した object の型によって決定され、(例えば Offer のような) この文書に記述していない型を受け入れることも可能である。

inbox に受信した Accept の object が、以前受信者によって送られた Follow アクティビティの場合、 サーバは 受信者の Following コレクションn に actor を追加するべきである(SHOULD)。

7.7 Reject アクティビティ

これを inbox に受信することによる副作用は、 受信した object の型によって決定され、 この文書に記述されていない型 (例えば Offer)を 拒否することもできる。

inbox に受信した Reject の object が、以前受信者によって送られた Follow アクティビティの場合、 これは受け取り側が Follow リクエストを承認しなかったことを 意味する。サーバは受信者の Following コレクション に actor を追加してはならない(MUST)。

7.8 Add アクティビティ

Add アクティビティを inbox に受け取ったとき、 次のような場合を除いて、サーバは target 属性で指定された コレクションに object を追加するべきである (SHOULD):

• target を受信サーバが所有しておらず、従って更新できない場合。
• 受信者の裁量による何らかの理由により、 object を target コレクションに 追加することを認められていない場合。

7.9 Remove アクティビティ

Remove アクティビティを inbox に受け取ったとき、 次のような場合を除いて、サーバは target 属性で指定された コレクションから object を除去するべきである (SHOULD):

• target を受信サーバが所有しておらず、従って更新できない場合。
• 受信者の裁量による何らかの理由により、 object を target コレクションから 削除することを認められていない場合。

7.10 Like アクティビティ

これを inbox に受信したときの副作用として、 サーバは、likes コレクションがある場合は、 このコレクションに受信したアクティビティを追加することで このオブジェクトのいいねのカウントを増やすべきである (SHOULD)。

7.11 Announce アクティビティ (共有)

Announce アクティビティを inbox に 受け取ったとき、サーバは、shares コレクションがある場合は、このコレクションに受信したアクティビティを 追加することで、 このオブジェクトの共有のカウントを増やすべきである (SHOULD)。

7.12 Undo アクティビティ

Undo アクティビティは、以前のアクティビティの副作用を 取り消すために使われる。ActivityStreams 文書の Inverse Activities and "Undo" を参照のこと。Undo アクティビティのスコープと制限は クライアントサーバ間での Undo アクティビティ と同様であるが、 連合コンテキストに適用される。