tesaguri 🦀🦝 @tesaguri@fedibird.com

例によってPLCについては考えないものとする（？）

「bsky.socialに一極集中」については、BlueskyとBridgy Fedを除いたPDSのアクティブユーザ数は、ええと……約0.027%？（<https://blue.mackuba.eu/stats/>）

AppView実装という意味ならBlueskyの他にWhiteWindやFrontpage、Linkatなどがあるから、「ATProtoの実装はBlueskyしか存在しな」いはフェアな表現でないように思う。
PDS実装としてもarroba（Bridgy Fedのsnarfed氏がメンテナンスしているやつ）などがあるけど、可搬なデータ形式を共有する以上はPDS実装による違いというのは実際のところ多分そこまで重要でない。違いがあるとしてもXRPCメソッドの実装詳細などの細かい差異くらいだろうか。
で、分散という観点においてより重要であろうリレーについては……知らんｗ（？）

申し訳ないとは思っている。いやほんと、申し訳ないとは思っているのよ

（まあ理論上の問題としては受信のタイミングだけではなくて、例えば接続元やkeyid等によって異なる表現を出し分けられるとか、何ならfetchの度にランダムに異なる表現を返されるとか、あらゆる可能性を想定できてしまうのだけど）

投稿の編集を肯定しようがしまいが、content-addressedとかなわけでもないデータを連合している以上はリモートのオブジェクトが勝手に書き換わることを妨げられないわけで、オブジェクトの編集の受信をサポートしなければオブジェクトを受信したタイミングによって異なる表現を掴まされうるという問題を抱えるだけだよね

うおおおおお、私は外出先でテザリングしながら`docker pull`するぞおおおおお

機械に疎いので、ゆうちょ通帳アプリで二次元バーコードを読み取る手順を毎度調べ直している

https://github.com/misskey-dev/misskey/blob/5229f5de4d9ef7cd75d32466d29d672193adaf45/packages/backend/src/core/AbuseReportService.ts#L144
Misskeyでは対象ユーザのアクターか。
まあいわゆるシステムアクターを安定して特定する仕組みとかも特に確立していないし、それはそうか

プロトコルレベルでは報告を行うユーザ自身でなく代理のアクターが`Flag`アクティビティを送る慣習らしいというところまでは認識しているけど、宛先のアクターは具体的にどう決定されるのだったっけ。`Block`とかについてもそうだけど

Mastodonでは対象のサーバに転送するか否かはユーザによる選択式だったと思うけど、Misskeyでは管理者が選ぶのかな？

こういうのを調べるときはソースコードを該当するアクティビティで検索して当たりを付けるのが定石だと思っているけど、確か報告の連合はActivityPubでは規定されていないのだよな。現行のFediverseの慣習では`Flag`アクティビティだったっけ？

余剰の計算リソースをFolding@homeに費やしているような人はついでに帯域リソースをSnowflakeに費やしておくと良いですよ（？）

今まで何も考えずにSnowflakeプロクシ（<https://snowflake.torproject.org/>）を走らせていたけど、そういえばプロクシを走らせる環境でVPNを設定していても良いものなのだろうか

まっさらなプロファイルでも再現するから、環境に依らない不具合と見て良さそうかな。報告するにしても既存チケットがないか調べるのが面倒臭いな……

しかも別のディスプレイで試すと何故か再現しない

実際Cover Your Tracksでもかなり情報量の多いフィンガープリントとして報告される（後者の画像は参考のために100pxの倍数の高さに調整した場合の結果）