eventually consistent ってわけじゃないけど、「とりあえず動かせるだけ動かしておけば、『理想的な状態』に追い付ける」という特性がほしい
復帰を簡単に発動できる・勝手に発動するなら、もっと気軽に止めてもというのはまあわからんでも
配信が(ある期間、ある瞬間に)行われているかどうかというのは正直あまり重要でもなくて(いや SNS としてはリアルタイム性は欲しいけど)、「漏れが最終的になくなるか」の方が気になりますね、個人的には
ので自動的なそういう判定には慎重で、一応あまりに失敗が続くと長期的に配信やめる実装もあるけど、その処理はフォロワーへの投稿配信にしか適用しないので通知やメンション等の明示的な配信は通るし、それでもし通ればすぐに解除するようになってますね。あと短期間だけ止めてすぐ解除するStoplightの導入で試行期間は減らさずに負荷だけ軽減するようにしたり。
少なくとも、他インスタンスの状態管理に使われているデータストアがアクティブなキューしか存在しなくて、しかもキューの中身は条件付きで捨てられうる、というのはあまり真っ当ではなさそう
たとえば「落ちたと思っていたインスタンスが復帰していることに気付いたとき、過去ログの取得や投稿の push を行う」みたいなこと
まあ本来であれば正確な判定よりも「後から正常な状態に復帰させる手段」の方を充実させるべきな気がするので、 Mastodon がそれについて貧弱とかそういう問題なのかもしれない (Mastodon の実装詳しく知らんけど)
遡り取得なんてせず、取れたやつだけ出す、24時間以内くらいだったら配信側がリトライしてやる、くらいでも十分「ちゃんと動く」ように見えるのではないかと思った。
#yukari4a Next の mastodon トゥート表示に 非収載/非公開/ダイレクト表示を追加するための羊羹本数を考える
ちょっと日本とはMastodonの使われ方が違うらしい。「よく考えてから投稿」????
実録:Twitterを“脱出”して「Mastodon」に移行したら、デジタルライフに活気が甦った https://wired.jp/2018/09/17/mastodon-twitter-alternative/
LANG=ja_KS.UTF-8 NetBSDでは動きました(UTF-8 が入ってたら全部同じ扱いという雑な処理の可能性)
debian系ならいけるとかですかね(全く分からない)
OK Google,としぁを1億ふぁぼして