コハル @koharu917@fedibird.com

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

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

#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…

Mastodonの公式アプリって、Twitterの公式アプリを使うのとは少し意味合いが違います。

Twitterは、自社のコントロール下でサービスを使って欲しいこともあり、サードパーティの同等（同等以上）の機能を提供するアプリを排除しており、公式アプリを使うのがサービスの利用者の正しい姿、というテイで利用を求めてきますが、

Mastodonの公式アプリというのはそういう囲い込みのためのものではなく、

アプリストアでMastodonで検索して出てくるアプリとして公式がないと、新しい利用者をキャッチし損ねるということで用意されたもので、

Mastodonの利用者が皆、これを使うことを求めているというものではありません。

公式アプリが新規利用者をキャッチし、Mastodonの各サーバに登録するまでの導線を提供することが第一使命で、

もちろんそのまま公式アプリを使い続けてもらってもいいのですが、

サードパーティのアプリが、公式アプリより優れた特徴的な機能を提供して、利用者が選択することで、全体として盛り上げていくことを目指しています。

ま、ちょっと公式を推し過ぎなきらいはありますが :-)

いろいろなアプリを探して選んでみてください。（実はWebUIが便利だったりするというオチ？もあります）