NIP-42

Authentication of clients to relays

クライアントからリレーに対する認証

ざっくりと

チャレンジ/レスポンス認証のような動きをします

流れ

クライアントはリレーから「チャレンジ」文字列をもらい、チャレンジを含むイベントを作って署名をし、リレーに送ります

リレーは署名されたイベントが届いたら、正しい署名かどうかを検証します

署名が正しければ、リレーはユーザの公開鍵を元に有料会員かどうかや許可リストに載っているかどうかを判断します

検証が成功したら、そのあとはクライアントは色々な操作を行えるようになります

失敗したときはエラーがクライアントに返ります

認証によってWebSocketに接続しているのが本人であることが保証されます

動機

制限されたリソースにアクセスするクライアントに対し、リレーは認証を求めたいかもしれない

イベントの投稿を支払いを求めるか、他の形による許可リストによって許可制にしたい

単に許可リスト内にあるキーで署名されたイベントのみに投稿を制限することで

チャットのやり取りをしている人々だけにダイレクトメッセージ(kind 4)の利用を制限したい

クライアントがDMをクエリするときに認証を必要とする

リレーは購読を有料会員や許可リストに載っているユーザだけに制限したい

リレーから送信されるAUTHメッセージ

["AUTH", <challenge-string>]

クライアントから送信されるAUTHメッセージ

["AUTH", <signed-event-json>]

→ 署名されたイベント

一時的なイベントであり、投稿や問い合わせには使われない

リレーは、kind 22242のイベントをいかなるクライアントに対してもブロードキャストしてはならない(MUST)

code:_.json

{

"id": "...",

"pubkey": "...",

"created_at": 1669695536,

"kind": 22242,

"tags": [

],

"content": "",

"sig": "..."

}

通信の流れ

クライアントはチャレンジを受信したら認証自体を行うかどうかを決めてよい

チャレンジは接続の間、あるいはリレーから次のチャレンジが送られるまでは有効と見做されることが期待される

認証はWebSocket接続が切れるまで続くことが期待される

認証済みでないユーザからメッセージを受信し、認証なしでは続行できない場合は、リレーはクライアントに通知できる

NOTICE

["NOTICE", "restricted: 認証していないユーザにはDMを提供していません。お使いのクライアントはNIP-42に対応していますか？"]

OK

["OK", <event-id>, false, "restricted: 認証していないユーザからのイベントは受けつけていません。https://example.com/ でサインアップしてください"]

URL正規化の手法を適用してもよい

多くの場合はドメイン名が正しいかどうかを確認するだけで十分である