新しいものを表示

というかそもそもリレーなんてものに関係なく未知URIを都度解決できたならば一般のWebが分散的であるのと同程度には分散的なアーキテクチャと呼べただろうに(この際1 googolplex歩譲って検閲の問題は考えないものとする)、実際はキャッシュの立場が強すぎるっぽいのが惜しいと思っている。
"big world with small world fallbacks"の"small world fallbacks"って結局何なんやねん。クライアントの手元で手作業でDIDを解決・検証してPDSを直接叩くこと?(?)

スレッドを表示

エアプなので文の区切りのたびに免罪符として「恐らく」を挿入している(?)

リレーも建てる試みは一応存在しなかったっけ? まあいずれにせよ恐らくサードパーティのリレーの存在の有無自体は大した問題ではなくて、というのも恐らくリレーを建てたところでAppViewがそれを見てくれなければ意味がないので

Blobs - AT Protocol
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部分?)を全てひっくるめたものと大差ないのでは

tesaguri 🦀🦝 さんがブースト

#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] bsky.social/about/blog/5-5-202

Issueにかなりどうでも良い長文two centsを投げつけていたらタイミング悪くメンテナのコメントと被ってしまって、マジで邪魔なコメントを投げただけの人になってしまった

Fediverseでは使われていないと思うけど、TLSのクライアント証明書とかはそのあたりどうだったっけ(うろ覚え)。セッション鍵の確立までの認証だとしたら、その後のやり取りは否認可能になるだろうけど

スレッドを表示

否認不可になるのが嬉しいとは限らないかも知れないけど、そもそもHTTP Signaturesだって恐らく受信者が特定の`Host`に特定のメッセージを送られたことを否認不可な形で証明できてしまうよね

スレッドを表示

アクティビティの配送、いちいち`Host`ヘッダごとにHTTP Signaturesを生成しなおすのでなく、オブジェクトに署名を埋め込んでHTTP Signature抜きでそれを使い回すとか出来ないだろうか。MastodonとかはHTTP Signatureがないと受け付けてくれなかった気がするけど……

まあ、Fediverseに溢れているBluesky批判もAtmosphere側から見れば大概似たようなものか(?)。同じことでもそれをあえてFediverseにおいて他人のインフラを使いながらやるとアレになるというだけで

久しぶりに投稿したかと思ったら陳腐なMastodonオワコン論のリブログみたいな人、流石にアンフォローしちゃうよね

たらればの話をしても仕方ないけど、それはそれとして僕の考えた最強のプロトコル設計の話は楽しいので(?)

既存のnormが相容れないことについては、データ形式ごと放棄せずとも例えばFEP-ef61 portable objectsのように`id`の名前空間を仕切り直して、新しい名前空間で新たなnormを打ち立てることを目指すとかでも良かったのでは。どうせaccount portabilityの関係から名前空間を分ける必要性はいずれにせよ生じたものだろうし。
どちらもそのままでは相互運用できないことに変わりはないけど、完全に非互換なデータ形式と比べれば`id`が非互換なだけだったなら既存の実装が対応することも容易だっただろう。まあ、そうなるとActivityPub実装が一方的にBlueskyを読むだけというパターンが多くなったかも知れないし、それがBluesky側にとって望ましかったかは知らんけど

スレッドを表示

元の質問(ブリッジされていないけど、リプライ先の<atproto-browser.vercel.app/at/>のこと)がActivity Streamsについてだったのに対して、途中からはActivityPubの話になっているな。
まあ既存のActivityPubのエコシステムにおける純粋なActivity Streamsのサポートが渋くて、純粋なActivity Streamsを露出しても中途半端な扱いになったかも知れないというのはそれはそうかも知れないけど……

スレッドを表示

やはりRDFが嫌というのが第一の理由か。しかし根本的なアーキテクチャの違いなどと比べると、既存のエコシステムとの相互運用性と天秤にかけるには軽すぎるように個人的には思えるけど、まあこれはBlueskyにとっての一般のWebエコシステムとの相互運用性の重さというのがその程度でしかないという話なのだろう
QT: bsky.brid.gy/r/https://bsky.ap
[参照]

Paul Frazee  
I gave RDF and ActivityStreams a really close look and there are two things I really didn’t like about it1, RDF usability is bad. It’s designed to...
tesaguri 🦀🦝 さんがブースト

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 —

AT ProtocolのAppViewをGoogleに喩えると一般のWebと大して変わらないように思えるけど、恐らくAppViewというのは検索エンジンだけでなくgoogle.com/ampのようなキャッシュレイヤーでもあって、しかもGoogleのそれと違ってキャッシュされていないWebページ、もとい`at:` URIへのアクセスを許すようなものでもないっぽいので、重要な要素を取りこぼした喩えのように思っている

例えばZennがGitHub以外のGitリポジトリからもデプロイできたとして、それを「分散」と呼んで良いのかみたいな(適当)

Blueskyは「ActivityPubはスケールしない(笑)」(<bsky.brid.gy/r/https://bsky.ap>)という立場だから、「ActivityPubに対応」するようではそもそもの存在意義が薄れるわけで……。それを"decentralized"と呼んで良いかはアレとして [参照]

古いものを表示
Fedibird

様々な目的に使える、日本の汎用マストドンサーバーです。安定した利用環境と、多数の独自機能を提供しています。