NIP-42は、クライアントがリレーに認証する方法を定義します。リレーはアクセス制御の提供、悪用の防止、または有料リレーサービスの実装のために認証を要求できます。

仕組み

認証フローは、リレーがクライアントにAUTHメッセージを送信することから始まります。このメッセージには、クライアントが署名する必要があるチャレンジ文字列が含まれています。クライアントはチャレンジを含むkind 22242認証イベントを作成し、秘密鍵で署名します。リレーは署名とチャレンジを検証し、アクセスを許可します。

{
  "kind": 22242,
  "tags": [
    ["relay", "wss://relay.example.com"],
    ["challenge", "random-challenge-string"]
  ],
  "content": "",
  "pubkey": "<client_pubkey>",
  "created_at": 1736784000,
  "sig": "<signature>"
}

チャレンジはリプレイ攻撃を防ぎます:クライアントは各認証試行で新しいチャレンジに署名する必要があります。タグ内のリレーURLは、認証トークンが異なるリレー間で再利用されないことを保証します。

ユースケース

有料リレーはNIP-42を使用して、アクセスを許可する前に購読者を確認します。認証後、リレーは支払いステータスまたは購読期限を確認できます。プライベートリレーは承認されたpubkeyへのアクセスを制限し、クローズドコミュニティまたは個人用リレーインフラストラクチャを作成します。

レート制限は認証によってより効果的になります。リレーはIPアドレスではなく認証されたpubkeyごとにリクエストレートを追跡でき、共有IPの背後にいる正当なユーザーをサポートしながら悪用を防止できます。リレーがイベント公開に認証を要求すると、スパム防止が向上します。

一部のリレーはNIP-42を分析に使用し、集中型アカウントを必要とせずにどのユーザーがどのコンテンツにアクセスするかを追跡します。NIP-11メタデータと組み合わせることで、クライアントは接続を試みる前にリレーが認証を必要とするかどうかを発見します。


主要な出典:

  • NIP-42仕様 - クライアントからリレーへの認証

関連項目: