NIP-62は、vanish requestを定義します。これは、要求者のpubkeyに属するすべてのイベントを削除するよう特定relayへ求めるkind 62イベントです。このrequestはデフォルトではrelay指定型で、特別なALL_RELAYSタグ値を使えばglobal requestとしてbroadcastすることもできます。

仕組み

vanish requestは、自分の履歴削除を望むpubkeyが署名したkind 62イベントです。tag listには、そのrequestを処理すべきrelayを示すrelay値が最低1つ必要です。

{
  "id": "a7b8c9d0e1f23456789012345678901234567890abcdef1234567890abcdef12",
  "pubkey": "f1e2d3c4b5a697887766554433221100ffeeddccbbaa99887766554433221100",
  "created_at": 1743465600,
  "kind": 62,
  "tags": [
    ["relay", "wss://relay.example.com"]
  ],
  "content": "Requesting deletion of all events from this relay.",
  "sig": "11aa22bb33cc44dd55ee66ff77889900aabbccddeeff0011223344556677889911aa22bb33cc44dd55ee66ff77889900aabbccddeeff00112233445566778899"
}

contentフィールドには、relay operator向けの理由や法的通知を入れられます。clientは、ユーザーがnetwork-wide vanish requestを意図していない限り、広く投稿するのではなく対象relayへ直接このイベントを送るべきです。

Relay behavior

vanish requestを見て、relayタグ内に自分のservice URLがあるrelayは、そのpubkeyから発せられたcreated_atまでのイベントを完全に削除しなければなりません。仕様はまた、relayが消えたpubkeyをpタグしていたNIP-59（Gift Wrap）イベントも削除すべきだと述べています。これにより、受信DMもユーザー自身のイベントと一緒に消えます。

relayはさらに、その削除済みイベントが再broadcastされてrelayへ戻ることも防ぐ必要があります。帳簿目的で署名済みvanish request自体は保持してよいとされています。

Global requests

イベントを見たすべてのrelayで削除を求める場合、タグ値は大文字のALL_RELAYSになります。

{
  "kind": 62,
  "pubkey": "<32-byte-hex-pubkey>",
  "tags": [
    ["relay", "ALL_RELAYS"]
  ],
  "content": "Global vanish request"
}

clientはこの形式を、できるだけ多くのrelayへbroadcastするべきです。

なぜ重要か

NIP-62は、ad hocなmoderation APIやrelay固有dashboardを超えて、clientとrelay operatorが共有できる削除シグナルを与えます。ユーザーは1つの署名済みrequestを公開し、各relayに同じevent formatで処理させられます。

これはNIP-09も超えます。NIP-09は個別イベントを削除し、relayは従うかもしれません。NIP-62は、タグ付けされたrelayへ、そのpubkeyのすべてを削除し、それらイベントの再取り込みまで防ぐよう求めます。

Implementations

Primary sources:

Mentioned in:

See also: