atprotoサービス開発者を中心とした、lexicon.communityという取り組みがある。これはlexiconを特定のサービスに結び付けずに共有しようという試みだ。
が、個人的にはこれに勝手な期待をかけて勝手に裏切られたため、否定的な態度を取ることが多い。先方に取っては迷惑千万だろうが、ダシに使わせてもらって、自分が望んでいたのはどういうものだったかを残しておこうと思う。念の為言っておくと、方向性とか目指すものが異なるという話であって、やっていることがしょぼいとか思っているわけではない。
lexicon.communityの最初のlexiconの議論を見た印象は、「普通にサービス作ってるみたい」というものだった。もちろん汎用性を強く意識したりはしているが、基本的には参加者が思い思いのユースケースを想像して、その中で良いlexiconを作ろうとしている。lexicon.communityはまだゴールも議論している段階のため、あくまで個人的な印象に過ぎないが、共有財産であることを明示したlexiconを作るということが重要なのだと思う。
一方で、lexicon.communityの存在を初めて知った時、中身を見る前に想像した可能性は、例えば以下のようなものだった。
- サービス自体を表すメタなスキーマ
- サービスの内容に依存しないプロトコルユーティリティ
- 多くのサービスで共有できるデータ
- 確立済スキーマの共有
- 汎用性の高い機能
- 全ての機能を包括する最小公倍数的なアプローチ
- 最低限の機能だけを定義する最大公約数的なアプローチ
- サービスによる拡張方法を予め定義するテンプレート的なアプローチ
厳密に欲しい順というわけではないが、上3つが個人的に特に興味があるところ。で、lexicon.communityのターゲットはそこから外れていたっぽいという話。
それぞれどんなものなのか具体的に説明する。この類の方法論はatproto固有の話ではない部分も多いので既に議論が色々ありそうだが、浅学のため思いつきで好き勝手言っておく。
メタスキーマ
様々なサービスが出てくると、サービス自体に関する情報を表す手段が欲しくなってくる。lexicon lexiconもその一種と言える。
他にも、以下のようなものがありえるだろう。
- 実装済APIの一覧取得API
- appviewの利用条件・利用方法を示すAPI
- データの(推奨)表示要件を示すrecord
基本的にappviewに関する情報なのでAPIの形で表れることが多いと思うが、lexicon解決仕様によってNSID管理者のrepositoryというものが定まるようになったので、recordになることもあるかもしれない。
プロトコルユーティリティ
サービスの中身にかかわらず、プロトコル仕様上あると便利なユーティリティというのもありえる。
strongRefやselfLabels等、既にある程度はatproto lexiconで定義されているとは思うが、ここで新しいパターンが発掘されれば一番面白い。
個人的にはstrongRefのcollection固定版が作れないか考えることが多い。以前もそんな話を書いたが、一般化には型パラメータが必要な気がしており、まだ解決していない。
このカテゴリはほぼobjectになるだろうが、enum stringとかもトップレベルで定義するのはあり。APIはメタスキーマ寄りな気はするが、まあ無くはないかも。
共有データ
複数サービスで共有するcollectionの話。全サービスで同じ情報を参照したい場合もあれば、サービス毎に異なるrecordを作るが串刺し検索などのAPIを提供したい場合もあるだろう。
表示名やステータスや連絡先あたり。サブアカウント情報やatprotoレベルのグローバルフォロー的なものもありえる。Bluemojiも今回の分類の中ではここに該当しそう。
とはいえあまり自明なものは思いつかないので、存在が周知されていても対立派閥ができたりしそう。
確立済スキーマ
既に一つのサービスとして完成したlexiconを共有する。bsky以外のサービスでプロフィールにgetProfileを使ったり、ブログサービスがwhtwnd lexiconを使ったりするのと似たようなもの。もちろん共有lexiconとして公開するならある程度は一般化してほしいが。使い方が明確な分、実践的と言える。
lexicon.communityでsmokesignal lexiconを引っ張ってきていたり、(recipes.blueという競合が存在する)recipe.exchangeが提案しているのも、標準として定着させる意図がありそう。関係者間で合意が取れるのであれば特に言うべきことはない。
汎用機能
likeのような、様々なサービスで利用可能なパターンを表すライブラリみたいなもの。実際にライブラリがセットで提供されることもありうる。冒頭で言及したbookmarkもここに分類されるだろう。
何かしら定義してあれば悩んだ開発者のヒントとして有用だろうが、サービス毎の拡張がバリエーションが想定される場合は、ちゃんと標準化しようと思えばアプローチを考える必要がある。
サービス横断的な共有データでないならば、lexicon検証やfirehose(jetstream)での抽出を考えると基本的にはrecordではなくobjectで定義するべきだろう。一方、APIに関しては多少のバリエーションがあっても同じNSIDを持っていた方が分かりやすいかもしれない。
包括的な定義
考えうるユースケースを全てオプションとして表現可能にし、サービス毎に必要なサブセットを選択する。オプションフィールドがすごい数並ぶことになりそう。結局どのサブセットを使うかはそれぞれ異なるが、同じ意味のフィールドやAPIを同じ名前に統一できるという点がメリット。
複数の仕様を後から統合しようとするとCommonMarkみたいになりそうだが、先に決まっていて後から拡張する形ならまだなんとかなるかもしれない。それでも網羅的に定義しようとすると管理がとても大変だし、制約((文字数制限など)は表せないという欠点もあるが。
最低限の定義
lexiconとして最低限提供するべき機能を定め、それ以外は独自拡張する。おそらく何かしらコアとなるAPIを決めて、そのAPIを成立させるために必要な情報等を定義していく形。
例えばcountLikes APIとlikeオブジェクトを定義する、とか。これくらいだったらエンドポイント共通化のために、汎用recordにしてNSIDをフィールドに持たせるという手もある。
getLikesまで定義しようとするとサービス固有の要素が入ってきて、エンドポイント共通化どころかlexicon上でもunknownになりそうだが。
サービス毎の拡張はAPIなら(outputに)独自フィールド追加だろうが、recordなら共通定義の外側に持つことが多くなりそう。
拡張前提の定義
open unionを使って独自要素を入れる場所を指定する。イメージとしてはrichtextやembed。
一番制御がきくので、巧くテンプレートを作ることができればメリットは多い。unionは独自フィールドと違って名前が固定されており、$type必須なので(lexicon解決ができれば)内部構造が分かるという点もポイント。
