NIP-43はrelayがメンバーシップ情報を公開する方法と、ユーザーが制限付きrelayへの入会、招待、または退会をリクエストする方法を定義します。すべてのプライベートまたはセミプライベートrelayが独自の参加プロトコルを発明する代わりに、relayアクセス制御に標準的なイベントサーフェスを提供します。

仕組み

この仕様は複数のイベントkindを組み合わせます：

  • kind 13534はrelayメンバーシップリストを公開します
  • kind 8000はメンバーが追加されたことを通知します
  • kind 8001はメンバーが削除されたことを通知します
  • kind 28934はユーザーがクレームコード付きの参加リクエストを送信できます
  • kind 28935はrelayがオンデマンドで招待コードを返せます
  • kind 28936はユーザーが自身のアクセス取り消しをリクエストできます

メンバーシップ状態は意図的に単一のイベントだけでは導出されません。クライアントはアクセスが現在有効かどうかを判断する前に、relay署名のメンバーシップイベントとメンバー自身のイベントの両方を参照する必要がある場合があります。

なぜ重要か

NIP-43は制限付きrelayに入会とメンバーシップ状態を表現する標準的な方法を提供します。これはグループシステム、招待制コミュニティ、および帯域外のWebフォームや手動のオペレーターワークフローに頼らず機械可読なオンボーディングが必要なrelayにとって重要です。

PR #2267のオープンされた明確化は、1つの実用的なポイントを強化します：relayはpubkeyごとに1つの権威あるメンバーシップ状態を維持すべきです。これにより、古い追加または削除イベントが現在の状態として誤読される可能性のある曖昧なリプレイ履歴をクライアントが回避できます。

相互運用に関する注記

NIP-43はrelayがNIP-11ドキュメントを通じてサポートを広告することに依存します。参加リクエスト、招待リクエスト、退会リクエストは、このNIPをサポートすると明示的に表明しているrelayにのみ送信すべきです。

イベントがrelay管理空間とユーザー管理空間に同時に存在するため、実装には明確な競合ルールが必要です。これが、メンバーシップ状態の明確化が見た目以上に重要な理由です。

主要ソース:

掲載号:

関連項目: