tesaguri 🦀🦝 @tesaguri@fedibird.com

まあAT Protocolの偉いところとして、PDSとAppViewの分離が成立していて、多くの公開情報についてPDSに置くのが最も自然になるようなアーキテクチャになっているという点はあると思う。
ミュートとかダイレクトメッセージのようにそうでないものがあるといのも事実だけど、例えば「相互リンク」のようなものはBlueskyだったら多分PDSに記すような設計になっただろうし

まあそれを言ったらMisskey.ioの「相互リンク」とかもそうなのだけど

いや、既に後者のようなことをしようと思えば出来る力を有していることが問題なのであって、当座として実際にどちらになるのか自体は実はそこまで重要でないとも言えるのかも知れない

件の記事でも言及されていたけど、これとかもどうなるのだろうな。`*.host.bsky.network`にそういうデータをホストするのに課金するという話なのか`bsky.network`リレーや`bsky.app` AppViewでの受理に課金するのかで大違いな気がするけど

現状広告がないのとかは単に広告の出稿を受け付ける基盤が整備できていないだけなどの解釈も可能だけど、無料firehoseとかはいかにも赤字前提の段階のベンチャ〜感がある

Migrating bsky.social to Multiple PDS Instances (Nov 2023) · bluesky-social/atproto · Discussion #1832
https://github.com/bluesky-social/atproto/discussions/1832
> Account repos will, of course, be canonically hosted at the new hostname indicated in the DID document. repo events will be emitted from the canonical PDS host for the account, not from `bsky.social`; subscribe to the BGS firehose (`bsky.network`) to get all events from all accounts.

流石に`bsky.social` entrywayの`subscribeRepos`は塞がれているっぽいけど、今のところ`*.host.bsky.network`のは通るっぽい？（`websocat`で一瞬接続を試しただけだけど）
QT: https://fedibird.com/@tesaguri/113537193193889537 [参照]

それをいうとリレーも現状は土管のようなものと言えばそれはそうだけど、これは例えばfirehoseの利用に課金するなどの選択肢があるだろうし。
そうすると大規模PDSの`com.atproto.sync.subscribeRepos`をどうするのかとかが非自明な気もするけど

まあネットワーク全体の情報を把握している集約サービスの視点としてはリプライの通知なども自分達で行えるのにメッセージパッシングなんてやっていたら純粋なオーバーヘッドだしね。
あとサービス運用上の問題として、メッセージパッシングのような中小規模のノードに最適化された機能を足してしまうと、AppViewは本当にただのYahoo!リアルタイム検索のような立ち位置になってしまってユーザの囲い込みが難しくなるというのがありそうだけど、これも個人的にはうるせえ知らねえそんなのプラットフォーマーの論理だろという感想でしかないので、はい

ネットワークを横断した全文検索のような本質的に集約が求められる機能についてはともかく、それ以外の機能もメッセージパッシングでなく"shared heap"によって実現するアーキテクチャなのはいかにもTwitterの代替としての設計という感じである

あとこれは純粋にPDSとそのホストするユーザのハンドルの関係を勘違いしていそうな雰囲気がある
> Most users are mapped to domains controlled as `*.bsky.app` [sic] subdomains, so Bluesky can remap those to different users, and this will be true with any "Personal Data Store" [sic] provider one might use too

あとハンドルシステムが無意味かのような評価も過剰かなと。以前に解決したことのあるハンドルについてはその"DID"との対応の変遷はクライアントが記録を付けておけば良い話だし（新規の解決はまた別問題だけど）、現実的にそのような運用を可能とするだけの枠組みは提供されているように見える。
Petnameシステムについてはこの記事で初めて名前を目にしたくらいなので、それとの比較でどうなのかについては何も言えないけど

まあこれについてもMatrixのようにもっとユーザフレンドリーながらサーバを信用しない鍵管理とかも考えられるのかも知れないけど。いや、Matrixが実際に何をしているのかは正直一切把握していないですけど……（？）。
あと詳しくはないけど、これも実際恐らく真なのだよな：
> And *even if* Bluesky delegates authority to that user to control their identity information in the future, there is still a problem in that Bluesky will *always* have control over that user's key, and thus their identity future.
"72hr window"とかもPLCサーバ自体が敵対的なら恐らくどうとでもできる程度のものだろうし（<https://web.plc.directory/spec/v0.1/did-plc>の"PLC Server Trust Model"節を参照）

まあもちろん細かい点で共感できない部分もあるけど。例えば自分で鍵を管理していないユーザを保護できていないことについての批判は流石に酷なように思う。
個人的にはまずはやる気があるユーザが現実的なコストで自分のデータを確保できることが重要かなと

これはBlueskyが"decentralized"という形容をPDSレイヤーに限定せずに用いているのが悪いのだけど、FediverseにおけるBluesky批判の多くがBluesky側のビジョンについてそれに同意するしない以前に議論ために最低限必要な理解もそこそこに「分散していない」の一点の批判に終始しがちだし、擁護者も「Blueskyは分散している」という雑な主張で返してグダグダになりがちという感想

分散システムのサービスとしてのBlueskyに対する評価としてはこんなところだよね（スレッドの方は未読）。というか"decentralized"という自称が無用な幻想と失望を招きすぎている

「（何が？）」じゃあないんだよ、AppViewが落ちたらどうするのだ（？）