ActivityPub仕様のMUSTとSHOULDまとめ
#unsocial開発
3.1
(MUST) サーバー間通信でPOSTされるActivityは意図的に一過性のもの(チャットメッセージやゲームの通知など)でない限り、一意のグローバル識別子(id)を持たなければならない
(SHOULD) クライアントからサーバーへの通信では、idなしのオブジェクトを受信したサーバーは、アクターの名前空間にオブジェクトidを割り当て、投稿されたオブジェクトに添付すべき
3.2
(MUST) サーバーはapplication/ld+json; profile="https://www.w3.org/ns/activitystreams"のリクエストに対してActivityStreamオブジェクトをレスポンスしなければならない
(SHOULD) サーバーはapplication/activity+jsonのリクエストに対してActivityStreamsオブジェクトをレスポンスすべき
(MUST) クライアントはAcceptヘッダにapplication/ld+json; profile="https://www.w3.org/ns/activitystreams"を付けてリクエストを送らなければならない
補足：サーバーは上記を満たさないリクエストに対して他の動作(HTMLを返すなど)を実装することもできる
(SHOULD) サーバーは、認証をパスしないリクエストにHTTPエラーコー ドを返すべき
(SHOULD) サーバーは、プライベートオブジェクトへのリクエストに403を返すべき
補足：存在を隠したい場合は404を返してもいい
4
(SHOULD) ログインフォームなどにURIを入力する場合、以下の手順で正規化すべき
有効なURIならそのまま利用
example.org/aliceのようにスキーマがなければhttpsなどデフォルトを適用
それ以外は無効
(MUST) Actorオブジェクトは3.1のid, typeに加えて、inbox, outboxプロパティを持たなければならない
(SHOULD) Actorオブジェクトはfollowing, followersプロパティを持つべき
5
(MUST) OrderedCollection型のプロパティは逆時系列でなければならない
5.1
(MUST) ActorのプロパティoutboxはOrderedCollection型でなければならない
補足：outboxのレスポンスはリクエスト送信者の情報に応じてフィルタリングされる
5.2
(MUST) ActorのプロパティinboxはOrderedCollection型でなければならない
(SHOULD) inboxのレスポンスはリクエスト送信者の情報に応じてフィルタリングすべき
(MUST) サーバーはinboxから返すアクティビティの重複排除をしなければならない
補足：フォロワーである特定のユーザーAと、フォロワー全体が宛先のメッセージの場合、A宛のメッセージが重複するので排除する
(SHOULD) 連合していないサーバーからinboxへのPOSTリクエストには405 Method Not Allowedを返すべき
5.3
(SHOULD) Actorはfollowersプロパティを持つべき
(MUST) followersはOrderedCollection型またはCollection型のいずれかでなければならない
補足：リクエスト送信者の情報に応じてフィルタリングしてもよい
5.4
(SHOULD) Actorはfollowingプロパティを持つべき
(MUST) followingはOrderedCollection型またはCollection型のいずれかでなければならない
補足：リクエスト送信者の情報に応じてフィルタリングしてもよい
5.6
(MUST NOT) PublicなActivityの実装は、受け取ることができない特別なコレクションに対して配信してはいけない（？）
補足：PublicなActivityは認証なしですべてのユーザーがアクセス可能
5.7, 5.8
likesとsharesにfollowers, followingと同様のことが書かれているが、実装は任意(MAY)のため省略
7
(MUST) Activityはidを持つべき(3.1と同じ)
(MUST) inboxなどへのPOSTはContent-Typeヘッダーに、GETはAcceptヘッダーにapplication/ld+json; profile="https://www.w3.org/ns/activitystreams"がつくべき
(SHOULD) サーバー間でのやりとりでは、Content-TypeまたはAcceptのapplication/ld+jsonとapplication/ld+json; profile="https://www.w3.org/ns/activitystreams"を同等に扱うべき
(MUST) 他のサーバーの Actor の inbox または sharedInbox プロパティに対して配信を行うサーバーは、アクティビティで object プロパティ(Create, Update, Delete...)を提供しなければならない
(SHOULD) HTTPキャッシュ機構(RFC7234)は、他のサーバーから応答を受け取るときと、他のサーバーに応答を送るときの両方で、適切な場合には尊重されるべき
7.1
(MUST) 受信者がCollectionまたはOrderedCollectionの場合、サーバーはユーザーの認証情報でコレクションを参照し、コレクションから各受信トレイを見つけなければならない
よくわからない
(MUST) サーバーは受信者リストの重複を排除しなければならない(5.2と同じ？)
(MUST) サーバーはActivbityのActorと同じActorをリストから除外しなければならない
Actor は自分自身のアクティビティを自分自身に配信させるべきでない
(SHOULD) 連合していないサーバーのinboxへ配信しようとした場合、405 Method Not Allowedが帰ってくるべき
7.1.1
(MUST) オブジェクトがoutboxに送信されたとき、to、bto、cc、bcc、または値がアクターが所有する個人またはコレクションである場合はaudienceに配送しなければならない
よくわからない
7.1.2
(MUST) サーバーはinboxにActivityを受信したとき、オリジン(送信元？)が配信できなかった受信者に転送する必要があり、以下の条件がすべて真のときにto, cc, audienceに対して行う
Activityはサーバーが初めて受信するものである
Activityのto, cc, audienceの値には、サーバーが所有するCollectionが含まれる
ActivityのinReplyTo、object、target、tagの値はサーバーが所有するオブジェクトである
(SHOULD) サーバーはこれらの値を再帰処理してリンクされたオブジェクトを探すべき
(SHOULD) 再帰処理には上限(会話のスレッドの深さの上限)を設けるべき
(MUST) サーバーはオブジェクトの to、cc、audience の値のみを宛先とし、再帰処理の間に新しい宛先を取得してはならない
7.1.3