Note
このドキュメントは2026-02-27 02:02にPLaMo Translation Modelを使用して自動翻訳されました。
FEP-f1d5: フェディバースソフトウェアにおけるNodeInfo仕様
概要
NodeInfoは、サーバーレベルのメタデータを公開するための標準化プロトコルとして設計されています。これにより、ツールやクライアントアプリケーションはこのメタデータを活用して、サーバーの健全性を評価したり、エンドユーザーがFediverseで使用する適切なサーバーやソフトウェアを選択する際に役立てることができます。
歴史
NodeInfoは、diaspora、friendica、redmatrixなどのソフトウェア向けに開発されたActivityPubプロトコルよりも先行して開発されました。このプロトコルが包含する元来の仕様には、diaspora、pumpio、gnusocialなどが含まれます。
NodeInfoの仕様は非常に厳格なスキーマを採用しており、多くの場合正規表現による検証や、あらかじめ定義された列挙型値のみを許容します。これに対する批判として、一部のフィールド検証を省略し、メタデータ構造を再編成したフォーク版であるNodeInfo2が作成されました。さらにNodeInfoとNodeInfo2を基盤として、ServiceInfo仕様も一時的に検討されました。
本FEPでは具体的なプロトコル詳細の文書化は行いません。その詳細については、NodeInfoおよびNodeInfo2を参照してください。本FEPでは、現在のアプローチにおける歴史的経緯と課題点を明らかにし、Fediverseソフトウェア開発者にとって有用な背景情報を提供することを目的としています。
要件
本仕様書中で使用される「MUST」「MUST NOT」「REQUIRED」「SHALL」「SHALL NOT」「SHOULD」「SHOULD NOT」「RECOMMENDED」「MAY」「OPTIONAL」といった用語は、RFC-2119で規定されている解釈に従うものとします。
Fediverseソフトウェアは[NodeInfo][NodeInfoRepository]を実装することが推奨されます。
注意点
本FEP作成時点で、コミュニティによって指摘されている現在のNodeInfo仕様に対する主な問題点は以下の通りです。なお、ここで言及する技術的代替案はあくまで参考例であり、強制的な要件ではありません:
software.nameフィールドに適用される正規表現が不必要に制限的です。具体的には、大文字の使用禁止、スペースの不使用、英語以外のアルファベットの排除、およびハイフン以外の特殊文字の許可制限などが挙げられます。software.versionフィールドが必須とされている点も過度に厳格です。これはソフトウェアに対してバージョン情報の開示を強制するものであり、セキュリティ上の問題を引き起こす可能性があります。inboundおよびoutbound要素は、単純な文字列ではなくあらかじめ定義された列挙型として規定されています。プロトコルのバージョンアップは名称変更を伴う形で実装されるため、新たな列挙型を追加する必要が生じ、結果としてバージョン管理が不明瞭になります。- Fediverseソフトウェアには必須要件として、
openRegistrations概念を実装しなければなりません。 - HTTP Signaturesやwebfinger、OAuthなど、他の機能を識別・バージョン管理する拡張可能な方法が欠如しています。仕様自体は非常に厳格である一方、
metadata部分は過度に寛容な設計となっています。 usage.usersフィールドは非正規化されておらず、実装によってはソフトウェアに適した独自の(アクティビティ数, 期間日数)ペアを提供することができません。usage.usersは、ユーザーIDが特定の実行インスタンスのソフトウェアと紐付いていることを前提としています。複数サーバーに分散している場合、複数グループに所属している場合、あるいは複数のユーザー集合内に存在している場合など、「総ユーザー数」をどのようにカウントすべきかが明確ではありません。異なるソフトウェアインスタンスがそれぞれ独自の基準で「当該ソフトウェアを使用している」と主張する可能性があり、その結果、同一ユーザーが複数回カウントされる事態が生じ得ます。usage.usersにおけるアクティビティカウントも同様に、ユーザーIDが特定の実行インスタンスと紐付いていることを前提としています。上記と同様の理由により、全ソフトウェアで集計した場合、「総ユーザー数」が重複してカウントされる可能性があるように、activeHalfYearやactiveMonthといった活動期間指標も世界的に過大評価される可能性があります。activeHalfyearおよびactiveMonthというプロパティ名は、それぞれ180日間と30日間の時間区分を表すには不適切です。「1年の半分」は実際には180日である場合が0%であり、約182.5日となるケースは75%に過ぎません。一方、月単位で見ると30日となるのは33%の期間のみです。localPostsおよびlocalCommentsは、音声ファイルを扱うソフトウェア、動画コンテンツをホストするソフトウェア、あるいはコメント機能を持たないソフトウェア、または投稿機能自体がないソフトウェア向けに、(種類, カウント数)ペアとして非正規化されていません。localPostsおよびlocalCommentsが必須とされている点は、これらの機能を有さないソフトウェアにとって問題となります。
実装例
サーバー側
以下は網羅的なリストではありません:
- Mastodon
- Matrix
- Pleroma
- PeerTube
- WriteFreely
- Friendica
- Diaspora
- PixelFed
- Misskey
- Funkwhale
- Smithereen
- Plume
- GNU Social
- lemmy
- zap
- Socialhome
- epicyon
- apcore
- FIRM
クライアント側
参考文献
- Christine Lemmer Webber, Jessica Tallon, ActivityPub, 2018年
- Jonne Haß, jhass/nodeinfo, 2014年
- Jason Robinson, jaywink/nodeinfo2, 2016年
- Jason Robinson, ServiceInfo - service metadata仕様書, 2019年
- S. Bradner, RFCで要件レベルを示すためのキーワードの使用法, 1997年
著作権
CC0 1.0 Universal(CC0 1.0)パブリックドメイン献呈
法律で許容される範囲内において、本Fediverse Enhancement Proposalの著者らは、当該作品に関するすべての著作権および関連する権利を放棄しています。