Reply on Bluesky and Decentralization | bryan newbold | WhiteWind blog
https://whtwnd.com/did:plc:44ybard66vv44zksje25o7dz/3lbvbtqrg5t2t
元の記事ではshared heapの性質として特にリプライに関して"no directed delivery"であることを述べていたわけだけど、この記事はそれに対する答えになっていないように思う。
リプライを送る・受け取ることを必須の要件としないならばそりゃRFC 9518の要件を満たすかも知れないけど、流石にそれは暗黙の仮定として受け入れるには無理があると思うので少なくとも陽に言及されるべき論点かと思う
> Technically, Bluesky PBC is still operating the PLC directory (we are actively exploring how to change this). However, […], so any retroactive manipulation would be observed and called out.
個人的にはBluesky PBCが初めから（retroactiveですらなく）上位のローテーション鍵によるPLC operationを存在しないかのように扱って下位のローテーション鍵で好き放題するシナリオを想定していたけど（元の記事の意図は知らぬ）、まあ現実的にはDIDコントローラがサードパーティのPLCサーバに同じ操作を登録して回ればどうにかなる……か？
> Other data transfer mechanisms, such as […] routed delivery of events (closer to "message passing") are possible and likely to emerge.
これが具体的に何を想定しているのか気になる
> Resilient small-world bsky AppViews could work by periodically polling specific accounts from their PDS and indexing relevant posts.
というかこれ本当にやって良い想定なのですか？ `com.atproto.sync.subscribeRepos`の個別リポジトリのみを購読するバージョンを用意しないなら私は本当にレートリミットの許す限りの頻度でポーリングするつもりだぞ、おおん？（？）
元の記事が具体的にコストの計算を試みていたのがリレーのみであったのは、その更に引用元のセルフホストについての記事がAppViewまではセルフホストできていなかったことによるものだと思うけど、そもそもの参入障壁の問題の議論はAppViewを含めたものなので、リレーのコストだけを云々してもあまり本質的でないように思う。
というか問題はネットワークの全体を集約する必要があることなので（記事では"The ability to scale-down atproto"について述べられているものの、ここではリプライの到達可能性等のために必要と仮定する）、共時的な具体的コストについて論じても仕方ないのでは。Non-archival relayにしてもスループットには比例するだろうし、AppViewに至ってはストレージコストは増大し続けるだろうし（それとも将来的にAppViewもnon-archivalとか言い出す？）