NIP-62はvanishリクエストを定義しています。これは、ユーザーがrelayにコンテンツの削除を要求するためのメカニズムです。relayはこれらのリクエストに従う義務はありませんが、NIP-62をサポートすることで、ユーザーは公開したデータをより制御でき、ネットワーク全体で削除の意図を通知する標準化された方法が提供されます。

仕組み

vanishリクエストは、コンテンツを削除したいユーザーによって署名されたkind 62 eventです。リクエストは、eタグにIDを含めることで特定のeventを対象にするか、eタグを完全に省略することでそのpubkeyからのすべてのコンテンツの削除を要求できます。

{
  "id": "a1b2c3d4e5f6...",
  "pubkey": "abcd1234...",
  "created_at": 1736726400,
  "kind": 62,
  "tags": [
    ["e", "event1234...", "wss://relay.example.com"],
    ["e", "event5678...", "wss://relay.example.com"]
  ],
  "content": "Removing old posts",
  "sig": "sig1234..."
}

contentフィールドには、削除リクエストの人間が読める理由をオプションで含めることができます。eタグ内のrelayヒントは、元のeventがどこに公開されたかをrelayに伝えますが、relayは指定されたeventを持っているかどうかに関係なくリクエストに従う場合があります。

Relayの動作

NIP-62をサポートするrelayは、指定されたeventをストレージから削除し、サブスクライバーへの提供を停止する必要があります。vanishリクエスト自体は、削除が要求されたことの記録として保持される場合があり、これにより削除されたeventが他のrelayから再インポートされるのを防ぐのに役立ちます。

vanishリクエストがすべてのeタグを省略した場合、relayはこれをそのpubkeyからのすべてのeventを削除するリクエストとして解釈します。これはより抜本的なアクションであり、relayは異なる方法で処理する場合があります。例えば、pubkeyを「消滅済み」としてマークし、今後そのeventを受け入れたり提供したりすることを拒否するなどです。

relayはNIP-62をサポートする必要はありません。Nostrネットワークは分散化されており、各relayオペレーターは独自のデータ保持ポリシーを決定します。ユーザーは、vanishリクエストを公開したからといって、コンテンツがあらゆる場所で削除されると想定すべきではありません。

プライバシーに関する考慮事項

vanishリクエストはベストエフォートの削除メカニズムであり、プライバシーの保証ではありません。vanishリクエストを公開した後でも、コンテンツのコピーはネットワークの他の場所に存在する可能性があります。これには、NIP-62をサポートしていない他のrelay、クライアントデバイスのローカルキャッシュ、サードパーティのアーカイブや検索エンジン、バックアップなどが含まれます。

リクエスト自体も署名されたNostr eventであり、公開記録の一部になることを意味します。vanishリクエストを見た人は、たとえ何が削除されたかを見ることができなくても、あなたが何かを削除したことを知ることができます。

非公開にする必要があるコンテンツについては、事後の削除に頼るのではなく、NIP-17のような暗号化メッセージングの使用を検討してください。

主要ソース：

言及されている記事：