注: 2023/08/14付で NIP-01に統合された。

送信したイベントをリレーが受理したか否かを、クライアント側で感知できるようにするために、コマンド結果(Command Results)という概念を導入する提案。

コマンド結果は以下のようなフォーマット。

リレーによってイベントが成功裏に保存 or 拒否されたときに、リレーからクライアントに送信される。

イベントがすでに保存済みだった場合、リレーは true を返さなければならない(MUST)。この場合、 duplicate: で始まる message をつけるべき(SHOULD)。

イベントを拒否し、保存しないことにした場合、リレーは false を返さなければならない(MUST)。

message によって、コマンド(イベントの送信)が成功・失敗した理由を表す追加情報を適用すべき(SHOULD)。

状況に応じて利用すべき(SHOULD) message のprefixが定められている。

blocked: ... 公開鍵またはネットワークアドレスがブロック対象・ホワイトリスト外の場合

invalid: ... イベントが不正な場合( created_at が現在時刻から離れすぎ(cf. NIP-22)、署名が不正など)

pow: ... イベントが proof-of-work 難易度の基準を満たさない場合(cf. NIP-13)

rate-limited: ... レート制限により拒否された場合

error: ... リレー側の問題でイベントの保存に失敗した場合

一時イベント(cf. NIP-16)に対しては、コマンド結果の応答を返さない

「イベントが保存されたかどうか」がポイントなので、そもそも保存されない一時イベントに対しては意味をなさない、ということ?

クライアントが送信したイベント自体または EVENT メッセージの形式が不正だった場合、コマンド結果ではなく NOTICE メッセージ(cf. NIP-01)を使うべき(SHOULD)。

クライアントによる処理

message の内容は人間が読むことを意図しているが、クライアントはprefixに応じてエラー処理を行うことも可能。

例:

rate-limited: が返ってきたら、メッセージを表示せずに単純にリトライする

pow: が返ってきたら、バックグラウンドでリレーのメタデータから必要なPoW難易度を取得→リトライする

今のところNIP-11からは取得できなさそうだけど、どうすればいいんだろうか

invalid: , blocked: が返ってきたらポップアップでエラーメッセージを表示する

prefixにコロン( : )を含めているのは、prefixとメッセージ本文をきれいに分割できるようにするため。

将来的には REQ や AUTH といった他のコマンドにも拡張される予定。