ActivityPubからAT Protocolのブリッジについてはどうしてもdata repositoryへのデータの複製・再頒布を伴うからオプトインが妥当だと思うけど、逆方向についてはAPサーバというのは単なるプロクシとして振る舞えるので、一般のAppViewと同じくオプトインなしで閲覧できるようにしても問題ないのではという気がする。ATPのアクセス制御はAPのそれのサブセットくらいの強さしかなさそうだし

`!no-unauthenticated`ラベルとかいうのもあるけど、ActivityPubサーバをAT ProtocolのAppViewと見做すならそのユーザに見せる分には問題ないのでは。知らんけど

オプトインにでもしないとブリッジが乱立するという問題はあるだろうけど、そこはFEP-fffd proxy objectsとかで良い感じに重複排除するような方針もありうるだろうし

AT Protocolのレコードはデータ型のlexiconがプロパティを規定しているものと認識しているけど（詳しく読んでいないので知らんけど）、型がプロパティを規定するよりプロパティが型を規定するRDF的なアプローチの方が拡張性の観点で有利なのではという気がする

RDF Schema 1.1
https://www.w3.org/TR/2014/REC-rdf-schema-20140225/
> One benefit of the RDF property-centric approach is that it allows anyone to extend the description of existing resources, one of the architectural principles of the Web

一方のAT Protocolは拡張のための慣習の案の一つとして何と`x-`接頭辞を検討しているという：
https://atproto.com/specs/lexicon
> or a convention around field name prefixes (x-) to indicate unofficial extension.

Blueskyには拡張の互換性の問題がない。なぜなら拡張が禁止されているからである（？）：
https://docs.bsky.app/docs/advanced-guides/custom-schemas
> Right now, we artificially prevent non-Bluesky records from being created by our PDSs. However, we'll be lifting that limitation soon.

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

確かに`host.bsky.network`のプロフィールだ……

そういえばAT ProtocolではActivityPubと違ってリプライの許可範囲の意思表示の仕組みが確立しているのだったか。
一応Activity Streamsでも`replies`コレクションを管理するのはリプライの受信者のサーバであるし、ActivityPubでも`inReplyTo`の副作用は特に定められていないはずだからプロトコル上は受信者がリプライを制御していると考えられなくもないけど、実際は`inReplyTo`が副作用として無条件に対象オブジェクトの`replies`コレクション相当のキャッシュにリプライを追加する扱いが一般的だし、ActivityPubのinbox forwardingとかもそのような扱いを前提とした仕様に見える

BlueskyがActivityPubを採用しなかった3つの理由 | Bam | WhiteWind blog
https://whtwnd.com/boobam.bsky.social/entries/BlueskyがActivityPubを採用しなかった3つの理由
うーん

皮肉とかのつもりではないのだけど、著者の方自身がBridgy Fedにオプトインしていなくて笑ってしまった（記事ではオプトイン方式に否定的な立場を取っているので整合はしている）

アカウントポータビリティについては必須でないというだけで、FEP-ef61のように後付けすることは不可能でないからなあ

Fediverseが一極集中していると批判するなら、まずはその屏風からより一極集中していないAtomosphereというものを出していただきたいと思ってしまう

「コミュニティごとの集まりを形成したいだけならば、中央集権型のSNSで十分」というのもよく分からない。
コミュニティごとに外部から独立して独自のモデレーションを行いたいなら連合しないセルフホストのコミュニティで十分という主張だったなら理解できるけど、既存の中央集権プラットフォームでは現状のFediverseよりもモデレーションの自由度が低いわけで

インプレッション云々については、正直その動機にもあまり共感できないけど、仮にそれを受け入れるとしても現状のFediverseでも目的の大規模サーバから1人以上フォローされていれば（そして文化的に近い大規模サーバなら特にその蓋然性は高い）投稿を届けるには十分なわけで、セルフホストのデメリットとしては弱いと思う

スケーラビリティについては、AT Protocolには明るくないのでよく分からないけど、例えば「リレー抜きの"small world fallbacks"のみの」AT ProtocolでもActivityPubより効率的だったりするのだろうか。
フォロイーの投稿を受け取るという基本的な機能についても第三者のリレーを信用することが前提なのだとしたら、それは非中央集権プロトコルと呼ぶには難があるのでは。まあActivityPubにもオプショナルなリレーのような仕組み（今のFediverseにあるようなものでなく、AT Protocolのそれのようなもの）があっても良いのではという立場もありうるだろうけど

「クローリングに対する文化的抵抗」については……まあ、はい。
個々のサーバによる連合の制限によるロックインについても、AT Protocolの全てを曝け出すアプローチによって緩和できる側面はあるかも知れないけど、これは各サーバのデータ主権にも関わるところなので、一概にどちらが良いとも言い難いしなあ

リレー……ActivityPub over WebSubの機運か？（？）
QT: https://fedibird.com/@tesaguri/113266141695459889 [参照]

というかAT Protocolはネットワークのスモールワールド性と関係ない概念を"small world"などと呼ぶのをやめろ定期（？）

"Atmosphere"のつもりが、いかにも日本人みたいな（？）typoをしておる……

VCの資金を食い潰す前のTwitterも同じくVCの資金で回っている今のBluesky PBCに劣らないくらいには良心的でしたよ（炎上）