NIP-20
Command Results
送信したイベントをリレーが受理したか否かを、クライアント側で感知できるようにするために、コマンド結果(Command Results)という概念を導入する提案。
コマンド結果は以下のようなフォーマット。
リレーによってイベントが成功裏に保存 or 拒否されたときに、リレーからクライアントに送信される。
["OK", <event_id>, <true|false>, <message>]
イベントがすでに保存済みだった場合、リレーは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)に対しては、コマンド結果の応答を返さない 「イベントが保存されたかどうか」がポイントなので、そもそも保存されない一時イベントに対しては意味をなさない、ということ? jiftechnify.icon
クライアントが送信したイベント自体またはEVENTメッセージの形式が不正だった場合、コマンド結果ではなくNOTICEメッセージ(cf. NIP-01)を使うべき(SHOULD)。 クライアントによる処理
messageの内容は人間が読むことを意図しているが、クライアントはprefixに応じてエラー処理を行うことも可能。
例:
rate-limited:が返ってきたら、メッセージを表示せずに単純にリトライする
pow:が返ってきたら、バックグラウンドでリレーのメタデータから必要なPoW難易度を取得→リトライする
今のところNIP-11からは取得できなさそうだけど、どうすればいいんだろうかjiftechnify.icon invalid:, blocked:が返ってきたらポップアップでエラーメッセージを表示する
prefixにコロン(:)を含めているのは、prefixとメッセージ本文をきれいに分割できるようにするため。
将来的にはREQやAUTHといった他のコマンドにも拡張される予定。