フォロー

masterに、私が提案していた、Mastodonでグループアクターを扱う際の基本サポートが追加されました。

ActivityPub(で用いるActivityStream Actor Types)では、ユーザーのアカウント、ボット、サーバーなどのアプリケーションサービスをそれぞれPerson、Service、ApplicationといったActorで表します。

ActorにはPersonやServiceの他に、Groupもあります。文字通りActorのグループを扱うものです。

今回のmasterの変更内容は、Mastodonでこのグループを扱う際の基本的な対応を行うもので、

・グループアカウントにバッジを表示する

・フォローしているグループからブーストされた場合(単なる配送なので)通知を表示しない

・グループにメンションした場合、グループの参加者も対象に含める

という処理が行われます。

ここではグループをフォローしている人を参加者として扱います。

Groupを扱うActivityPubサービスが登場した際の対応準備です。

先のプルリクは、グループ機能そのものを実現するものではありませんが、基本的ながら、重要な機能追加となります。

ActivityPubをベースにしたMastodonの投稿の公開範囲は、誰を宛先にしているかを基準に判断されています。

公開投稿はw3.org/ns/activitystreams#Publ

未収載はw3.org/ns/activitystreams#Publ

フォロワーオンリーはfedibird.com/users/noellabo/fo

となっていて、宛先になっている相手だけが見られます。

グループの場合、グループアクターだけを宛先に指定するとグループの参加者が対象に含まれないため、そのままでは参加者だけを対象としたグループは実現できません。

そこで、グループアクターが参加者を対象にブーストすることで配送して見られるようにする必要があります。

また、グループのフォロワーを宛先に含めてあれば、ブーストではなく転送するだけで全てが実現可能です。

前者へのケアが今回の『通知の抑制』で、後者のケアが宛先の追加機能です。

ブーストは負荷が高いので、できるだけ後者で運用されるように移行していくといいですね。

なお『グループのフォロワーをグループ参加者とみなす』というのはActivityPubなどの仕様に存在しない、私が勝手にそう決めて提案したものです。

フォロワーとは別にmembersなど専用のコレクションを持たせる実装なども考えられますが、オプショナル仕様となって誰も実装しないことが想像でき、良くて最新版でしか使えないものになるため、普及させるのが難しいのではないかと思います。

いろいろ考え、これまでの議論や既存実装との互換性などを踏まえ、フォロワー方式にて提案しました。Mastodonでは*ひとまず*受け入れられました。

他の実装で広く受け入れられるものになるかはわかりませんが、より優れた方法が提案されなければこれを推していきたいと思います。

----

How to work with groups? #328 - ActivityPub
github.com/w3c/activitypub/iss

Support groups #139 - Mastodon
github.com/tootsuite/mastodon/

ログインして会話に参加
Fedibird

様々な目的に使える、日本の汎用マストドンサーバーです。安定した利用環境と、多数の独自機能を提供しています。