AT Protocolの世界観では少数のAppViewの実装者が自身の所有するNSIDのlexiconをかっちりと制御するのが理想で、拡張プロパティが対等でないのはもしかして欠点ではなく機能として意図されているのではという気がしてきた。
コレクションは基本的に1つのAppView実装＆インスタンスにのみ対応するという想定で、例えば`app.bsky.feed.like`に絵文字リアクションのサポートを追加する代替／フォークAppViewのようなものを考慮する必要性は低い的な（適当）
QT: https://fedibird.com/@tesaguri/113265786190900091 [参照]

大量の実装がそれぞれ微妙に異なる拡張のセットしかサポートしていない中でいかにマシなフォールバック表現に落ち着くように拡張を設計できるかとかを考えるのが楽しいのに（いいえ）

AT Protocolの`!no-unauthenticated`ラベルとかいうやつ、エコシステムの中で一人だけ妙に浮いている気がする。他はあらゆるものを全世界に晒している中で中途半端に融通の効かないアクセス制御もどきが紛れ込んでいるというか

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

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

他人が管理する名前空間の名前を勝手に使うの、所有者本人が同じ名前を使おうとした時に困るというアレがありそう

「ありそう」というか、名前空間というものがそもそもそういうものか……

そういえば名前空間の所有権とはまた別の話だけど、FEP-268dを書いていたときにこれを見かけたのだけど、結局この`searchableBy`は実用されたことがあるのだろうか。あるならターム名の衝突だし、ないとしてもニアミスで、いずれにしても現行のFediverseにおいてJSON-LDの名前空間の仕組みが実質的に死に体になってしまっていることの弊害の例をなしていそう
QT: https://blahaj.zone/notes/9ev0kge0aj [参照]