グループの話(1/5)

まず、ActivityPubの概要から。

Mastodon、Pleroma、Misskeyは、それぞれまったく異なるプログラムですが、ActivityPubというプロトコルに従ってやりとりすることで、相互接続を実現しています。

ActivityPubをざっくり言うと、Actorが別のActorに対してActivityを送信し、相互作用する仕組みです。

Actorはユーザーのアカウントに相当するものです。通常のユーザーはPerson、botはServiceという種類のActorとして表現されます。

Activityは『投稿を・作った』とか『投稿を・気に入った』『Actorを・フォローする』というようなメッセージです。

Actorは、受け取ったActivity、送ったActivity、フォローしているActor、フォローされているActorなどのコレクションを保持しています。

・ActorとActorがやりとりする
・ActorにPersonやServiceなどの種類がある
・Activityを送り合う
・フォロワーなどのコレクションを保持している

グループの話(2/5)

Actor同士が直接やりとりする投稿は、当事者以外、他の人には見えません。

そこで、Activityの宛先として、Publicコレクションという特殊な宛先を指定することができるようになっており、各サーバプログラムでは、これを誰にでも見えるようにしたり、連合タイムラインやローカルタイムラインに流して表示しています。

フォロワー限定やダイレクトが基本形で、公開や未収載が特殊な公開範囲だということです。

また、連合タイムラインやローカルタイムラインはユーザーを探すための場所ですよ、と説明されるのは、こういった事情があるためです。

公開投稿をどのように扱うか（見せ方を工夫するか）は、サーバ次第です。

なお、Activityの宛先には、メールと同様にToとCcがあります。一般に、PublicをToに指定したものが公開投稿、PublicをCcに指定したものが未収載として扱われています。

ここまで、なんとなくつかめましたでしょうか？

グループの話(3/5)

グループは、ActivityPubによるユーザーの集合の表現で、コミュニティやチャンネルを実現することができる仕組みとして利用できます。

Actorの種類としてGroupが定義されているので、これを用います。

Group Actorを宛先とすることで、Groupに参加しているActorへ間接的にActivityを送ることができます。

（ただし、第三者となるActorがActivityを転送するにはJSON-LD署名が必要で、現実的には投稿と削除ぐらいしか対応していない状況です）

Groupのメンバーを表現する方法はいろいろ考えられますが、Mastodonなどの既存実装との互換性を考えると、Groupのフォロワーをメンバーと見做す実装が現実的であるため、私はそれを採用しています。