何か重いと思ったら、裏のタブでCookieが無効なせいでAnubis（<https://github.com/TecharoHQ/anubis>）が実質的なビジーループを回し続けていた

ある程度は仕方ないとはいえ、あらゆるサイトがJavaScriptとCookieを求めて、いずれかが無効だと無言で壊れるのが何だかなあ。それを承知で自分で選んだ設定ではあるけど

計算資源を浪費するAI vs. スクレイピング避けのPoWとかいう環境破壊競争の様相

`utoipa`クレート、今までてっきり`utopia`だと思っていた

`utopia`がtyposquattingされていたら多分引っかかるところだったな（直近で`cargo add`する予定があったとかいうわけではないけど）

まずライブラリ名を手入力しようとするなという話である。はい

Blueskyアカウントなら入国審査もCARエクスポートで便利なスピード検閲！（炎上）

いや、実際にやるならばわざわざ入国のタイミングで調べるよりも、初めからfirehoseを監視して不穏分子のアカウントをあぶり出しておけばより便利なワンストップ検閲に出来るだろうけど

まあActivityPubだってクローリングは容易だからどっこいどっこいだけど、一応フォロー承認制・非公開投稿という地下潜伏運用も可能だから恐らく多少はアナーキスト向き（？）

それはそれとしてActivity Streams + Verifiable Credentialsだと個々のオブジェクトの真正性は保証できても`outbox`全体の整合性を保証できない（一部のオブジェクトを隠してもそのことを検知できない）点についてはちょっと分が悪く感じる

まあ、基本的にリレーやらAppViewやらといった中間者を挟むAT Protocolのエコシステムとは前提が違うからあれだけど、しかしその当のAtmosphereは何かJetstreamやらAppViewやらと、結局暗号学的な検証よりも権威の信頼に頼った運用が大半になっていたりしない？（例によってエアプなので知らんけど）

とにかく、APの検閲耐性についてはセルフホストという腕力で解決できるとして、しかし依然として鍵ローテーションをどうするのという問題があるのでは。全部署名しなおす？　AT Protocolの場合はこれはMSTの根（のCIDを参照するコミット）を署名しなおせば良いわけだろうけど

This account is not set to public on notestock.

明示的に設計思想として明言されていることだったのか

https://atproto.com/articles/atproto-ethos#opinionated-takes

まあ正直"staking its reputation"と言っても、一般的にAppView相当のプラットフォーマーがモデレーションとしてデータを検閲することについてはある種の諦念のようなものが存在して、そこまでstakeとして成立していないのではという感想がある

個人的にはあらゆる人類に常にnon-repudiationを求めるのは早すぎるのではという気がしていて、もしrepudiableなTLSとかでも上手く回るのだとしたらそういう選択肢もあった方が良いのではという気持ちもあるのであれだけど