ActivityPubとは、ActivityStreams 2.0データフォーマットに基づいた非中央集権型ソーシャルネットワーク用のプロトコルである。
早い話がMastodonやMisskeyなんかでサーバ間が通信したりするのに使うためのプロトコルと思ってもらえばOKである。
概要
まずActivityStreamsはJSON-LDと呼ばれるフォーマットをベースに構築されている。簡単に言えば、特定の文法に基づいて各種オブジェクトを定義する。ActivityStreamsにおける@contextは「https://www.w3.org/ns/activitystreams」である。
ActivityStreamsにおいては、まず基本となる以下の8つの型が存在する。
そして、「誰が」「何を」「どうした」というActivityや、「誰」を示すActor、「何」を示すObject・Linkを記述するための語彙がActivity Vocabularyである。
ActivityPubでは、ユーザには受信箱(inbox)と送信箱(outbox)の2つがある。inboxに外からPOSTすると、ユーザはinboxからGETできる。ユーザがoutboxにPOSTすると、外からGETできる。
そして、サーバの役割は、誰かのoutboxにPOSTされたものを、誰かのinboxにPOSTするという役割もある。
Actorにおいては、以下のうちidとinboxとoutboxは必ず持たなければならず、それ以外のものは任意で持つことができる(followingとfollowersは持つべきとされている)。
- id - そのユーザを識別するURI
- inbox - 受信箱(OrderedCollection型)
- outbox - 送信箱(OrderedCollection型)
- following - その人がフォローしている先(OrderedCollection型もしくはCollection型)
- followers - その人をフォローしているもの(OrderedCollection型もしくはCollection型)
- liked - その人がいいねしたもの(OrderedCollection型もしくはCollection型)
- streams - 追加のストリーム(Collection型)
- preferredUsername - 一意であることが保証されない、短い名前
- endpoints - エンドポイントのURL。いろいろあるが詳細割愛
あとは、当然だがActorはObjectを継承しているので、Objectが持っているフィールドは持つことが可能。
ActivityPubにはクライアント・サーバ間通信とサーバ間通信の2つがあるが、実際のところ、ほぼ用いられているのはサーバ間通信である(クライアント・サーバ間通信はそれぞれのソフトウェアが自前で実装するから、ActivityPubに従う必然性がない)。
例えば、AさんがAさんのフォロワーリストを宛先としてoutboxにPOSTした場合、そのフォロワーのinboxに対してサーバはPOSTする必要がある。リモートフォローはこの仕組みがあるから成り立つ、というわけだ。
関連リンク
関連項目
親記事
子記事
- なし
兄弟記事
- 7
- 0pt
