本質的にはアカウント削除時のdelete activityの連打と同じで、積上がった、かつ即時性の低い or 低くなってしまったキューをどう処理していくか、という話だと思うんですよ。これを遅延処理するだけで "被害" は少なくなるんじゃないかな、って https://best-friends.chat/@rosylilly/102837440839190525
ななななななながいよ鯖缶ですら読む価値なし
少なくとも現状のアーキテクチャでは配送(N)、受信側による fetch (M) 、その結果をエンドユーザーに配送(P) で O(NMP) になるのが確定で、それに耐える構造は、柔軟なスケーリングか、あるいは N の最小化、M の圧縮、 P の効率化、みたいな論点になるか、もしくは各所でのディレイ、あるいはキャッシュ戦略(これはこれでコスト増)みたいになるけど、すべてのサーバーがその柔軟なスケーリング戦略を取れない以上、どこかで臨界点は来て、かつその臨界点の上限値は常にでかいサーバーがリードを取るので、新規参入コストが増大し続ける未来しかなく、 Tier レベルで区分けするとか、遅延あるいはプロキシーする中間サーバーの出現とか、そういうあれこれがないと無理では?と思う。今だってメールサーバーを本気で運用できるのは Google か Yahoo かみたいになってるし、そういう未来以外どうしようもないんじゃないの。
仕組みの改善というのは何かとコストがかかりがちだけど、"悪者" を追い出して解決というのは技術に対して誠実なのか、という疑問が残る https://best-friends.chat/@rosylilly/102837381864031378
まあ実際、実行からある程度経ったActivityの配信はまとめてやるのではなく、順繰りに遅延させてほどほどにやれって言うのは同意する。アカウント削除のdelete activityの配信も優先度が下がった[要出典]らしいし https://mstdn.jp/@walkthrough/102837201452745610
鯖缶は独裁すべきだけど、そのインスタンスを選んでくれた利用者に対して誠実な独裁者でなければならないと思うのよ。そういう意味では、ドメインブロックなどの "措置" の公表はしっかりする必要があるわけだし、鯖缶の一時の感情で公平性のない "措置" をしてはいけないと思う https://mstdn.ijs01140.com/@ijs01140/102837177475396404
会いたいのですが、めったにPawooを使いません。 ここに書いてください - http://badoogirls.com/ ニックネーム 「HanakoKiss」 Write me here - http://badoogirls.com/ Nickname "HanakoKiss"
楽園追放されたオタク