コハル @koharu917@fedibird.com

とりあえずグループ機能が話題になっていたので掘り起こしましたが、これは数年前まで取り組んでいた実装の名残です。

現在、Mastodon本家はグループ機能を別途開発中で、今回紹介したものとはまったく別のものになります。

私の実装の方は、Mastodonの実装に置き換わって消える見通しです。

まあ、こういう概念が実装可能ということは参考になると思います。

サーバをまたいで参加できる任意設置可能なコミュニティです。いろいろと課題もありますが、まずサーバありきの発想が変わると思います。

https://covelline.com/news/2023/1748/

feather開発の人が書かれた文章、私はAndroid勢でfeatherには触れたことはなかったけど自分のTwitterアプリのことを思い出してしまった

マストドンのグループ機能を使ってチャットがしたい……！というわけで
ポケモングループとサンリオグループを新たに作ってもらいました！！

下記のアカウントをフォローすることでポケモンやサンリオ好きな方はサーバー内外問わず会話に参加可能です！よろしくお願いします！

#fedibird
@pokemon
@sanrio

@playground なお、グループサーバーの登録は解放していないので、私の手動登録が必要です。

Fedibirdにだけ、いくつか機能拡張があります。たとえばグループディレクトリというのがあります。ここからグループを探すって感じね。

全部実験的な実装で、しかも3年ぐらいほったらかしにしてあるやつなので、全部暫定仕様だと思ってください。

そういうこともできるんだ、ぐらいの感じで！

グループ機能の開発・テストサーバーであるgdev.fedibird.com上に、サンリオとポケモンのグループが作成されました。

ポケモンGroup
@pokemon

サンリオGroup
@sanrio

オーナーはまりるりんとさん @AzumaRinto です。

このグループ機能は、グループのアカウントをフォローすることでどのサーバからでも参加することができます。

グループのアカウントにメンションすると、その投稿がグループアカウントによってブーストされ、参加者に届きます。

参加していない人がメンションしてもブーストはされません。

公開と未収載の投稿が可能ですので、ローカルタイムラインに流れるのを回避したい方は未収載での投稿をおすすめします。

なお、これは約3年前に実装した実験的なグループ機能の実験サーバで、特別な追加機能なしで実現できる互換性重視のグループ実装です。

性質上、非公開のグループは作成できない制約があります。

ハッシュタグに集う場合との違いとして、

ハッシュタグは誰も所有できないので、期待しない投稿の混入に弱いのですが、

グループは参加の承認や拒否、投稿単位での削除（グループアカウントがブーストを外すと結果として消える）など管理が可能で、確実に届くことがあります。

マストドンについて話しても反応悪いの、いきなり『マダガスカルに移住しました！マダガスカルはとってもいいところです！みんなもマダガスカルに移住しましょう！』って言われても戸惑うのと同じようなもんだと思うのよね。聞いたことあるけどよく知らんを深堀しないタイプの人も多いし。

※マダガスカルは完全に語感で選びました

もし、私が少人数の、それこそ一人のサーバだとしたら、リモートへの配送だけで済みます。

たとえば、人気のある人が自分のサーバに人を集めてしまったら、フォロワーだらけになりますから、それだけの負荷を自分で処理しなければなりません。

ところが、自分が発信するだけのサーバにして、フォロワーには分散SNS / Fediverseの空間にいてもらえば、サーバの数だけ配送すれば済みます。

10万人のフォロワーを自分のサーバに抱えると大変ですが、1,000のサーバに配送するだけなら楽々です。

この違いは承知しておきましょう。

ちなみに、私が投稿した際、リモート側では、mstdn.jpが1,320のフォロワーへの配送を受け持ってくれています。misskey.ioが196、mastodon-japan.netが159、pawoo.netが146、mastodon.socialが100です。

私はfedibird.comのサーバ管理者なので、たまたまfedibird.com（ローカル）のフォロワーが多いですが、みなさんの場合はもっと分散していると思います。

全体で薄く広く負荷を引き受けて、一つのノード（サーバ）が無理をしないように……なっているかな？

大きいサーバはちょっと不利ですね？

フォロワーの数と、Mastodonの負荷の話でもしましょう。

--

私のアカウントには、6,735のフォロワーがいます。

さて、私が何かを投稿したり、ブーストした際に、どこにどのぐらいの負荷がかかると思いますか？

これを判断するためには、ローカルのフォロワー数と、リモートサーバの数を知る必要があります。計算してみましょう。

fedibird.comの中のフォロワーは、3,089だそうです。

リモートのフォロワーへは、サーバの数になります。フォロワーは745サーバに散らばっているようです。

投稿した際、ローカルのユーザーには、fedibird.comがそれぞれに配ります。

ホームでフォローしている人が3,068、リストに64、アカウント購読に191、合計で3,323個のDistributionWorkerが生成されてタイムラインに挿入する仕事をします。通知やハッシュタグ、キーワード購読などの処理も別途行われます。

リモートへは、745個のActivityPub::DeliveryWorkerを起動し、リモートサーバに送ります。そのサーバの中のフォロワーへ配送する処理は、相手に任せます。

丸投げする分、リモートの方が遙かに負荷が軽い。

ここが分散SNSのポイントになってくるところです。

There was yet another Twitter API policy change last night: “good" bots may have light write-only API access.

This was instigated by, checks notes, someone Tweeting a picture of their cat.

I wish I was clever enough to make this stuff up…