tesaguri 🦀🦝 @tesaguri@fedibird.com

AppViewの運用というものにはグローバルビューの集約という劇重責務が付き物であることから、気軽に実装して運用できるような代物でないという構造的なインセンティヴの問題はあるかも知れない

AT Protocolのサービスといっても、単なる"Sign in with Bluesky"レベルのものやbsky.appの代替Webクライアントの見分けが付きづらいのが困る。いや、それこそが意図して設計された「機能」なのかも知れないけど

例によって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を設定していても良いものなのだろうか

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