既存の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 という感じ
https://github.com/tesaguri/userscripts/commit/fae29bf35351c3cc1ea62744d877dad0723a67dd
> fix(fedibird-hook-bsky-app-links): oh shoot `RequestInit.referrer` uses correct spelling
今日のクソコミット
First draft of ActivityPub HTML Discovery report from Evan Prodromou on 2024-11-16 (public-swicg@w3.org from November 2024)
https://lists.w3.org/Archives/Public/public-swicg/2024Nov/0041.html
ActivityPub Discovery
https://swicg.github.io/activitypub-html-discovery/
FirefoxとThunderbiredくらいしか開いていないのにメモリ不足になって何事かと思ったけど、Misskey Hubや<https://misskey.io/api-doc>を閉じたら2 GiBくらい空いた(?)
他人からのリプライについてはともかく、なぜ自己リプライ・スレッドまでワンクッションの操作を挟む仕様なのか気になっている表示も何か小さいし
AT Protocol(というか`app.bsky.*` lexicon?)の性質を考えればオプトアウトの方が馴染むというのは総論として同意だけど、`!no-unauthenticated`セルフラベルやリプライ制御と、(特にアカウントの所有者本人によってセルフホストされた)他のブリッジとの重複への対応をどうするのか気になるな
QT: https://fedibird.com/@tesaguri/113265667860530240 [参照]
Switch Bluesky to opt out? · Issue #1471 · snarfed/bridgy-fed
https://github.com/snarfed/bridgy-fed/issues/1471
この方はただの例です