NIP-29はリレーベースのグループを定義し、リレーがグループのメンバーシップ、権限、メッセージの可視性を管理します。

仕組み

グループはrelay hostとgroup idの組で識別され、membershipとmoderationの権威はリレーにあります。グループに送られるユーザー作成イベントはgroup idを持つhタグを持ちます。リレーが生成するmetadataは、リレー自身のkeyで署名されたaddressable eventを使います。

中核になるmetadata eventはkind 39000で、kind 39001から39003がadmin、member、supported roleを記述します。moderation actionはput-user、remove-user、edit-metadata、create-inviteのような9000番台イベントで行われます。

アクセスモデル

  • private: メンバーのみがグループメッセージを読める
  • closed: リレーがinvite-code処理を使わない限り、参加リクエストは無視される
  • hidden: リレーが非メンバーからグループメタデータを隠し、グループを発見不可能にする
  • restricted: メンバーのみがグループにメッセージを書ける

これらのタグは互いに独立しています。誰でも読めるがmemberだけが書けるグループにもできますし、非memberから完全に隠されたグループにもできます。この分離は重要で、クライアントはprivateをすべてのアクセス制御の総称として扱うべきではありません。

信頼モデル

NIP-29はtrustlessなグループプロトコルではありません。ホスティングするリレーが、どのmoderation eventを有効とみなすか、どんなroleが存在するか、member listを見せるか、古いメッセージや文脈外メッセージを受け入れるかを決めます。クライアントはsignatureやtimeline referenceを検証できますが、グループの実際の状態は依然としてrelay policyに依存します。

そのため、migrationやforkは可能でも自動ではありません。同じgroup idが別のリレー上に存在しても、履歴やルールは異なる可能性があります。実務上、relay URLはグループ識別子の一部です。

実装メモ

  • クライアントはrelay URLをgroup host keyとして扱うべきです。2026-01の明確化で、pubkeyではなくこれを使うことが仕様上はっきりしました
  • グループ状態はmoderation historyから再構築され、39000番台のrelay eventはその状態のinformative snapshotとして働きます
  • timelineのprevious参照は、relay fork間で文脈外の再配信を防ぐためのもので、単なるUI上のスレッド改善ではありません

主要ソース:

言及箇所:

関連項目: