tesaguri 🦀🦝 @tesaguri@fedibird.com

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.

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

まあ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