ちなみに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、

ってところかな。

@tell_me_fedi_jp @dampuzakura アカウント毎に設定できるドメインブロック（ミュート）については、現状、例外を設定できるような構造にはなってないですね。

キーワード購読にのみ、この設定を無視して拾う機能があります。

Elixir由来なところもあるかもしれないけど、ActivityPubのルーズさに対して、不整な値に対するチェックが厳しいのはあるよね。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

@khkq 解決しちゃいましたか。

十中八九不具合なんですが、具体的事例がないとなかなか直せないので、また発生した時に教えてください！

#fedibird

インセンティブ設計したくないなぁ。

良くて、胃が荒れる薬を、胃薬とセットで飲ますみたいなやつになる。

@chaoruko この不具合が出る時は、とりあえずCWボタンを押して解除すると復活したりするので試してみて。

#fedibird

環v4の機運

現行のPleroma / Akkomaに、プロフィール補足情報（Misskeyだと追加情報）が多すぎるとアカウント情報の取得に失敗し、再取得を繰り返してしまうバグが存在します。

これにより、CPUが使い尽くされたり、データベースが肥大したり、相手サーバへ過大な負荷をかけてしまいます。

Pleroma / Akkoma全体でこれが発生するため、実質的にDDoSを仕掛けるような挙動となります。

デフォルトが20なので、これを設定（Instance の Max remote account fields）で大きく引き上げる方法でまず対応し、

指定数をオーバーしたら切り捨てて対応するパッチをあてる対応が必要です。
https://git.pleroma.social/pleroma/pleroma/-/merge_requests/4220

Pleroma / Akkomaの新バージョンがリリースされたら速やかにアップデートしましょう。

この不具合は、プロフィール補足情報の件数が多いActivityPub実装すべてで発生します。

Mastodonの標準は4件、Misskeyは16件、Fedibirdは8件ですが、独自に数を増やしているサーバであれば該当する可能性があります。

また、Misskey.ioのバナー機能はプロフィール補足情報で連合するので、こちらでも発生します。

Illustratorにはグラデーションメッシュあるのにねえ

マルイストーン

Akkomaについて、今回の不具合への対応を含む不定期リリースが出ています。3.13.3です。
https://akkoma.dev/AkkomaGang/akkoma/src/branch/develop/CHANGELOG.md#3-13-3

stableブランチだね。
QT: https://ihatebeinga.live/objects/7dcc6cd6-3918-435e-bc95-571f70b28345 [参照]

@Reaper メモリとかカツカツのサーバの場合、定期リセットしないとメモリ不足になることはあります。安定していれば、何週間も再起動なしでいけます。（aptのupdateとかは来ますが）