グループの話(2/5)
Actor同士が直接やりとりする投稿は、当事者以外、他の人には見えません。
そこで、Activityの宛先として、Publicコレクションという特殊な宛先を指定することができるようになっており、各サーバプログラムでは、これを誰にでも見えるようにしたり、連合タイムラインやローカルタイムラインに流して表示しています。
フォロワー限定やダイレクトが基本形で、公開や未収載が特殊な公開範囲だということです。
また、連合タイムラインやローカルタイムラインはユーザーを探すための場所ですよ、と説明されるのは、こういった事情があるためです。
公開投稿をどのように扱うか(見せ方を工夫するか)は、サーバ次第です。
なお、Activityの宛先には、メールと同様にToとCcがあります。一般に、PublicをToに指定したものが公開投稿、PublicをCcに指定したものが未収載として扱われています。
ここまで、なんとなくつかめましたでしょうか?
グループの話(4/5)
投稿するActorがGroupへメンションすると、Group Actorがそれを、メンバー(自身のフォロワー)へAnnouce Activityで転送します。これが基本形です。私はこれを、アクティブ方式と呼んでいます。
もう一つ、Group Actorからフォローバックして、ハッシュタグなど特定の条件が揃った場合にブーストする方式も可能で、私はこれをパッシブ方式と呼んでいます。
パッシブ方式は、無意味に多くの投稿をGroupに配送してしまう弱点がありますが、メンションせずにグループに投稿を流せるので、利便性はなかなかのものです。
これらは、既存のMastodonなどのサーバでも十分に機能しますが、サポートする機能を実装することで、より効率良く、使いやすくすることが可能です。
このあたりは、色々とアイデアがあって進めているところです。
グループの話(5/5)
グループは、連合する、サーバをまたぐコミュニティの構築に活用することができます。
ローカルタイムラインがコミュニティとして利用されてきていますが、その弱点を補うことができます。
Group Actorをホストしているサーバにメンバー管理と配送を依存していますが、投稿は参加者のサーバから発信され、参加者のサーバに配送されて保存されていくので、容易には失われません。
また、引っ越し機能でフォロワーを移し替えることで、コミュニティホストを引っ越すことすら可能です。
チャンネルに用いることもできます。これは、自身の投稿のうち、特定の内容だけをフォローしたいユーザーニーズに応え、投稿する側も配送先を使い分けることができるようになります。
複数アカウントの使い分けと比べ、リプライやお気に入り・ブーストが単一のアカウントにフィードバックされたり、メインアカウントのフォロワーに対して全てをまとめて配送できたりするメリットがあります。マルチポストが防げます。
こちらのらりおさんの記事をぜひ。これを実現可能なものです。
https://blog.cardina1.red/2018/02/25/strongest-dist-sns-i-think/
グループの話(3/5)
グループは、ActivityPubによるユーザーの集合の表現で、コミュニティやチャンネルを実現することができる仕組みとして利用できます。
Actorの種類としてGroupが定義されているので、これを用います。
Group Actorを宛先とすることで、Groupに参加しているActorへ間接的にActivityを送ることができます。
(ただし、第三者となるActorがActivityを転送するにはJSON-LD署名が必要で、現実的には投稿と削除ぐらいしか対応していない状況です)
Groupのメンバーを表現する方法はいろいろ考えられますが、Mastodonなどの既存実装との互換性を考えると、Groupのフォロワーをメンバーと見做す実装が現実的であるため、私はそれを採用しています。