tesaguri 🦀🦝 @tesaguri@fedibird.com

そもそも一般にサービス提供者視点で（ユーザ視点でなく）AT Protocol上にサービスを作る嬉しさというものが何なのかあまり理解していない気がするな。
Blueskyのユーザ層を引き込めること……はリレーを別けたら微妙そう。Blueskyのモデレーションに相乗りできること……もリレーを別けたら意味ないな。「ナウなAT Protocolのサービス」という話題性……うーん？

いや、同じlexiconを喋る複数のAppViewに分裂するならまだしも、独自のAppViewで独自のlexiconを喋る分には混乱はそこまで発生しないか？　いずれにせよあえてAT Protocolの上に実現する嬉しさがあるのかも微妙な気はするけど

例えばpixivのようなモデレーションの方針が相容れなそうな（偏見）プラットフォームがAT Protocol対応する際に独自のリレーを構えるようなシナリオを想像していたけど、ネットワークを別けるくらいならそもそもAT Protocolに対応する意義も薄いか

これ、Blueskyの崩壊とまではいかないまでも仮にモデレーションの方針の違いなどからリレーが分裂して、ユーザ層がある程度重複しつつも一致はしないネットワークに別れたりしたときに困らない？

勢いで「現在の仕組みでは」と書いてしまったけど、あるリポジトリの所有者がどのAppViewを使っているかクエリするための仕組みなんて将来的にも実現されるわけがないか。あるAppViewやリレーが`com.atproto.sync.subscribeRepos`しているホストの一覧くらいならまだしも

あと、自分の視界を確保する分には既知の人々のPDSを探してクロールするということも出来なくはないだろうけど（PLCの解決の問題をどうにかしてどうにかしたとして）、他人にリプライなどのアクティビティを届けるには相手が自分のPDSの存在を把握している必要があるわけだけど、この疎通の有無をこちらから確認するのは少なくとも現在の仕組みでは困難では。
現在は`bsky.network`が「公式」という権威をもって実質的に全てのPDS（あえて連合していないものを除く）から`com.atproto.requestCrawl`を受けて大域的なネットワークのクロールを実現しているものと理解しているけど、Blueskyが散り散りになった後にそのような権威が自明に存在しうるとも思えないし

Bluesky PBCが消滅してもBlueskyを「セルフホスト」することが出来ると言われても、仮にBluesky PBCですら失敗したのだとすれば他に誰がリレーだのAppViewだのといったデカブツを世話できるのかという問題があるわけで、代替可能であることがどこまで嬉しいのかは疑問に思う。
これらは酔狂で持続的にセルフホストできるだけの細かい単位に分割できるようなアーキテクチャにはなっていないわけで

いわゆるauthorized fetchで弾きたいようなアクセスはある程度の敵対的関係を前提にしたケースが多いと思うけど、公開オブジェクトについては許可リスト連合でもない限りはいくらでも迂回のしようがあるし、脅威モデルとしては「行儀良くアクセスしてくれる敵対者」という奇妙な存在が仮定に含まれるということになりそうだよなあ

というかアクターがサーバの協力なしに脱出できるようになると「ローカル」と「リモート」という分類の意味するところすら変わりうるな

考えてみれば、リモートのオブジェクトの`id`を不透明な文字列として扱っているのをローカルのオブジェクトにも一般化すれば良いだけの話か。どうせクライアント側での署名を考えると特定のパスの形式を強制するのは難しいだろうし
QT: https://mitra.social/objects/01935ec0-ca11-2b5e-00a7-ab0dbafd534e [参照]

Fediverseについて言えば`did:key`間でMastodon方式の`Move`を行うという手もあるだろうけど。
あるいは`did:plc`にFEP-ef61のgatewayのノリでカスタムのディレクトリサーバを導入できれば良いだろうか

個人的にDNSという仕組みをいまいち信用しきれていないけど、DID（と名乗っているものを含む）も今のところいまいち決定打に欠ける感じがするのだよな。
ブロックチェーン系はフットプリントの問題があるし、`did:key`はローテーション不能だし、`did:plc`はdecentralizedでないし

その観点に関連して、FEP-ef61 portable objectsの`id`のpathの形式は実装依存と認識しているけど、実装間の可搬性についてはどんなものなのだろう

Fediverseでアイデンティティの可搬性が欲しいかというと、セルフホストという選択肢が現実的に存在するので絶対に必要というほどでもないとは思うけど、それはそれとして実装を乗り換えたくなったりあるいはドメインを喪失したりしたときに可搬性が高ければ便利だろうし、やはり普及しているに越したことはないのだよな

ActivityPods、気になってはいるのだけど、これが怖くて足がすくんでいる（？）
https://docs.activitypods.org/tutorials/deploy-your-own-pod-provider/#maintainance
> It is required to regularly compact the datasets generated by Fuseki, otherwise they may grow very large. Unfortunately, due to the extension we developed to handle WAC permissions, it is required to stop Fuseki, compact it and launch it again.

まあそれだけでなくブロックとかも全て晒す形になってしまっているわけだけど……