リレーも建てる試みは一応存在しなかったっけ? まあいずれにせよ恐らくサードパーティのリレーの存在の有無自体は大した問題ではなくて、というのも恐らくリレーを建てたところでAppViewがそれを見てくれなければ意味がないので
Blobs - AT Protocol
https://atproto.com/specs/blob
> It is not a recommended or required pattern to serve media directly from the PDS to end-user browsers, and servers do not need to support or facilitate this use case.
ともあるし
"outsource traffic and storage costs"の部分は私も疑ったことがないでもないけど、仮にリレーやAppViewのキャッシュを抑制してAppViewがblob referenceばかり返してクライアントはPDSを直接叩きに行くような世界観だったならまだしも、実際はAppViewは今のところblobとかもキャッシュしているようだし、そのストレージコストは既知のPDSの権威的なデータ(のうち関心のあるlexicon部分?)を全てひっくるめたものと大差ないのでは
#BlueSky isn't decentralised or federated. The outage yesterday is the obvious proof. It may *look* decentralised and they definitely love to outsource traffic and storage costs by claiming that running your own PDS (Personal Data Server) is somehow something federated, but that's all smoke and mirrors. You have to gor deep on [1] to find "networking through Relays instead of server-to-server" as their current implementation choice. THEY run the relays. No one else.
[1] https://bsky.social/about/blog/5-5-2023-federation-architecture
アクティビティの配送、いちいち`Host`ヘッダごとにHTTP Signaturesを生成しなおすのでなく、オブジェクトに署名を埋め込んでHTTP Signature抜きでそれを使い回すとか出来ないだろうか。MastodonとかはHTTP Signatureがないと受け付けてくれなかった気がするけど……
@noellabo @tell_me_fedi_jp 詳細には詳しくないですが、FEP-0837: Federated Marketplace (<w3id.org/fep/0837>)が近そうな気がします。Mitraの有償購読機能(<https://codeberg.org/silverpill/mitra/src/commit/f678698eb31832c417166e774377c54201ed1332/FEDERATION.md#subscriptions>)がこれによるもののようです
既存のnormが相容れないことについては、データ形式ごと放棄せずとも例えばFEP-ef61 portable objectsのように`id`の名前空間を仕切り直して、新しい名前空間で新たなnormを打ち立てることを目指すとかでも良かったのでは。どうせaccount portabilityの関係から名前空間を分ける必要性はいずれにせよ生じたものだろうし。
どちらもそのままでは相互運用できないことに変わりはないけど、完全に非互換なデータ形式と比べれば`id`が非互換なだけだったなら既存の実装が対応することも容易だっただろう。まあ、そうなるとActivityPub実装が一方的にBlueskyを読むだけというパターンが多くなったかも知れないし、それがBluesky側にとって望ましかったかは知らんけど
元の質問(ブリッジされていないけど、リプライ先の<https://atproto-browser.vercel.app/at/did:plc:linxaw3dwjjlqxyiit6vbapy/app.bsky.feed.post/3juumhkeuag2z>のこと)がActivity Streamsについてだったのに対して、途中からはActivityPubの話になっているな。
まあ既存のActivityPubのエコシステムにおける純粋なActivity Streamsのサポートが渋くて、純粋なActivity Streamsを露出しても中途半端な扱いになったかも知れないというのはそれはそうかも知れないけど……
やはりRDFが嫌というのが第一の理由か。しかし根本的なアーキテクチャの違いなどと比べると、既存のエコシステムとの相互運用性と天秤にかけるには軽すぎるように個人的には思えるけど、まあこれはBlueskyにとっての一般のWebエコシステムとの相互運用性の重さというのがその程度でしかないという話なのだろう
QT: https://bsky.brid.gy/r/https://bsky.app/profile/did:plc:ragtjsm2j2vknwkz3zp4oxrd/post/3juunh2s5gh26 [参照]
I gave RDF and ActivityStreams a really close look and there are two things I really didn’t like about it 1, RDF usability is bad. It’s designed to solve the problem of universal terms agreement, and it does *that* very well, but that’s a far more general system than what a protocol needs —
Blueskyは「ActivityPubはスケールしない(笑)」(<https://bsky.brid.gy/r/https://bsky.app/profile/did:plc:vpkhqolt662uhesyj6nxm7ys/post/3l3gvrir5bu2u>)という立場だから、「ActivityPubに対応」するようではそもそもの存在意義が薄れるわけで……。それを"decentralized"と呼んで良いかはアレとして [参照]
#Bluesky は、分散型を謳うからには実際に分散して、あと標準化団体がちゃんと標準化した技術であるところの #ActivityPub に対応してから出直しておいで…と、2億年前から思っている。
横目で応援はしてるけど、not for me という感じ
この方はただの例です