ちなみにfedibird.comから誰かがフォローしているリモートのサーバの数は4,574あるよ。
単に知っているというだけのトータルサーバ数は40,036。
問い合わせて200を返してくる、NodeInfoを備えた生きてるように見えるサーバが現在19,824。
うち、半分近くの9,683がMastodon系、2,296がMisskey系、1,624がPleroma系、gotosocialは867もありますね。friendicaが305、takaheが57、microblogpubが47、mitraが30、holloが14、gnusocialが12、といった具合です。
写真系では、Pixelfedが354、
動画系では、PeerTubeが935、owncastが141、loopsが1、
ブログ系では、wordpressが2,119、writefreelyが339、plumeが39、
リンクアグリゲーター系では、lemmyが252、mbinが14、kbinが5、
ってところかな。
数えてみたんだけど、fedibird.comは4,125のサーバからフォローされているね。
そのうち、私のアカウントをフォローしているサーバは1,261だった。
私が適当に って投稿すると、1,261のサーバにCreate Activityが送信される。
リモートのフォロワーは7,363いるけど、各サーバへは代表して一回だけ送れば良いので、17%ぐらいの送信量で済んでるね。
Misskeyのプロキシアカウントは、必要ないときにフォローする動作をやめた方がいいと思うよ。
たとえば、私のフォロワーがそのサーバに既にいて、投稿が相手のサーバに届いているときでも、そこのサーバの誰かがリストに入れただけでフォローしてくる。しなくていいよ。
#fedibird #fedibird_info いまちょっとエラー出てたと思うけど、たぶんなおったのでひっかかった人は再確認よろしく!
サーバ選び? あなたには、ウチのLTLの雰囲気がぴったりじゃないかな!
#fedibird #fedibird_info グループに返信する際、グループへのメンションを先頭にするよう修正しました(WebUI)
今回はgdevはデータベースの問題でロールバック(過去のデータに戻す)を行いましたが、一応動いた状態で対応ができました。
ロールバックで失われる情報も、リモートサーバから補いました。
もしグループのサーバが完全に死んでしまった(壊れたり、サービス終了した)場合でも、過去投稿はリモートの様々なサーバにキャッシュされていて参照できますし、それを元に新しいグループを別のサーバに作って、そこで新たにメンバーが再集結すれば、コミュニティは持続できます。
まあ、まだ自在に引っ越しできる、とまでは言えず、もう少しそのあたりをサポートする機能を充実させる必要がありますが、ともかく、できるということがある程度実証できたかなと思います。
今回、gdev.fedibird.comというサーバ上に作られたグループアカウントを、fedibird.comに引っ越しさせました。
MastodonやMisskey、Pleromaには、アカウントの引っ越しをサポートする機能があり、引っ越し先の新しいアカウントに既存のフォロワーを移し替えられます。
つまり、グループのメンバーを、別のアカウントに自動移行させることができます。
だいたいうまくいきましたね!
引っ越し機能(メンバー移し替え)ができなくても、メンバーに新しいグループアカウントを再フォローしてもらえばいいのですが、連絡がつけられなかったり、方法がわからなかったり、めんどうだったりして、離脱するケースも多くなると思います。
過去投稿を移し替えることは現状サポートされていないのですが、こちらは今回は手作業でやりました。fedibird.comにキャッシュされている情報を元に、新アカウントの投稿に書き換えています。
このグループの過去投稿にあたる、グループアカウントによるブーストは、あらためてリモートサーバへ伝播させていませんので、グループの設置サーバ以外では認識されていません。アカウントページを直接見に来る必要があります。
ともあれ、すべての投稿を引っ越しさせることができました。
QT: https://fedibird.com/@noellabo/104524341770775395 [参照]
グループの話(5/5)
グループは、連合する、サーバをまたぐコミュニティの構築に活用することができます。
ローカルタイムラインがコミュニティとして利用されてきていますが、その弱点を補うことができます。
Group Actorをホストしているサーバにメンバー管理と配送を依存していますが、投稿は参加者のサーバから発信され、参加者のサーバに配送されて保存されていくので、容易には失われません。
また、引っ越し機能でフォロワーを移し替えることで、コミュニティホストを引っ越すことすら可能です。
チャンネルに用いることもできます。これは、自身の投稿のうち、特定の内容だけをフォローしたいユーザーニーズに応え、投稿する側も配送先を使い分けることができるようになります。
複数アカウントの使い分けと比べ、リプライやお気に入り・ブーストが単一のアカウントにフィードバックされたり、メインアカウントのフォロワーに対して全てをまとめて配送できたりするメリットがあります。マルチポストが防げます。
こちらのらりおさんの記事をぜひ。これを実現可能なものです。
https://blog.cardina1.red/2018/02/25/strongest-dist-sns-i-think/
グループの話(4/5)
投稿するActorがGroupへメンションすると、Group Actorがそれを、メンバー(自身のフォロワー)へAnnouce Activityで転送します。これが基本形です。私はこれを、アクティブ方式と呼んでいます。
もう一つ、Group Actorからフォローバックして、ハッシュタグなど特定の条件が揃った場合にブーストする方式も可能で、私はこれをパッシブ方式と呼んでいます。
パッシブ方式は、無意味に多くの投稿をGroupに配送してしまう弱点がありますが、メンションせずにグループに投稿を流せるので、利便性はなかなかのものです。
これらは、既存のMastodonなどのサーバでも十分に機能しますが、サポートする機能を実装することで、より効率良く、使いやすくすることが可能です。
このあたりは、色々とアイデアがあって進めているところです。
主に、Fediverseへの関心に基づいた投稿を行うアカウントです。DTP・印刷に関する話をしたり、同人の話をしたり、カレーをブーストしたりします。
Mastodonのcollaborator(開発者の一員)です。また、独自機能を盛り込んだFedibirdを管理・開発しています!
Mastodonサーバ『fedibird.com』の管理者アカウントでもあります。ご連絡は当アカウントへ、サーバインフォメーションについては https://fedibird.com/about/more と @info を参照してください。