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

通常、リレーは要求に応じて過去受け取った全てのイベントをクライアントに返すことになっているため、結果的に受け取ったイベントを無期限に保存することが要求される。

このNIPでは、リレーに対して通常のイベントとは異なる取り扱い方を要求する「上書き可能イベント」(Replaceable Events)と「一時イベント」(Ephemeral Events)というイベントのカテゴリを定めている。

kindが 1000 <= n < 10000 の範囲のイベント。

通常イベントを受け取ったら、リレーはそのイベントを要求する全てのクライアントに配信し、保存すべき(SHOULD)である。

同じkindのより新しいイベントが古いイベントに影響を与えることはない。

kindが 10000 <= n < 20000 の範囲のイベント。

すでに受け取ったものよりタイムスタンプが新しい、同じkindかつ同じ鍵で署名された上書き可能イベントを受け取ったら、リレーは古いイベントを破棄すべき(SHOULD)である。これにより、実質的に特定の 発行者:kind の組合せで問い合わせた際に返ってくるイベントが上書きされる形となる。

タイムスタンプが同じ2つのイベントがある場合、 id が(辞書順で)小さい方を保持し、他方は破棄すべき(SHOULD)

範囲外だが、kind:0(set_metadata, NIP-01)・kind:3(contact list, NIP-02)・kind:41(channel metadata, NIP-28)も似たような挙動が期待されている

ソース: NIP-01#63e66e471246d70000cd34f1, NIP-02#6413457aa99d480000f3e2ee, NIP-28#63edcbdd2b31300000c59041

関連: NIP-33で定義されている「パラメータつき上書き可能イベント」は、「同じkindかつ同じ鍵で署名」に加え「同じ値の d タグを持つ」ことを上書き条件に追加したもの

kindが 20000 <= n < 30000 の範囲のイベント。

一時イベントを受け取ったら、リレーはそれを要求しているクライアントに一度だけ配信すべき(SHOULD)であり、保存してはならない(MUST NOT)。

クライアントは、このNIPをサポートしていないリレー(NIP-11の supported_nips に 16 が含まれていないリレー)に対して

一時イベントを送信すべきではない(SHOULD NOT)

上書き可能イベントを送信してもよい(MAY)が、同じkindの上書き可能イベントが複数送られてくることを想定し、最新のイベントのみを使うようにすべき(SHOULD)

ユースケース

状態: 上書き可能イベントを利用して可変な状態(例: ステータス(在席状況))を表現する

この用途だとパラメータつき上書き可能イベント(NIP-33)のほうが便利そう

タイピング中表示: チャットアプリ向け。一時イベントを使う

メッセージング: 一時イベントを使って、二者間で記録に残らないメッセージのやり取りを行う