https://github.com/tesaguri/userscripts/commit/fae29bf35351c3cc1ea62744d877dad0723a67dd
> fix(fedibird-hook-bsky-app-links): oh shoot `RequestInit.referrer` uses correct spelling
今日のクソコミット

このアカウントは、notestockで公開設定になっていません。

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

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

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

このアカウントは、notestockで公開設定になっていません。

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

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

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

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