NIP-62 定义了消失请求，一种用户请求中继删除其内容的机制。虽然中继没有义务遵守这些请求，但支持 NIP-62 可以让用户对已发布的数据拥有更多控制权，并提供一种标准化的方式在网络中表达删除意图。

工作原理

消失请求是由想要移除内容的用户签署的 kind 62 事件。请求可以通过在 e 标签中包含事件 ID 来针对特定事件，也可以通过完全省略 e 标签来请求删除该公钥的所有内容。

{
  "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 标签中的中继提示告诉中继原始事件发布在何处，尽管中继无论是否拥有指定事件都可以遵守请求。

中继行为

支持 NIP-62 的中继应从其存储中删除指定事件并停止向订阅者提供它们。消失请求本身可以被保留作为请求删除的记录，这有助于防止已删除的事件从其他中继重新导入。

当消失请求省略所有 e 标签时，中继将其解释为请求删除该公钥的所有事件。这是一个更激烈的操作，中继可能会以不同方式处理，例如将该公钥标记为"已消失"并拒绝接受或提供其任何事件。

中继不必须支持 NIP-62。Nostr 网络是去中心化的，每个中继运营者自行决定数据保留策略。用户不应仅因发布了消失请求就假设其内容会在所有地方被删除。

重要意义

NIP-62 为客户端和中继运营者提供了一个共享的删除信号，超越了临时审核 API 或中继特定的管理面板。用户可以发布一个签名请求，让每个中继决定如何处理。

实际限制在于范围。消失请求只影响看到它、支持它并选择遵守的中继。它不会撤回截图、本地数据库、第三方存档或已在中继控制范围之外被转发的副本。

隐私考虑

消失请求是一种尽力而为的删除机制，不是隐私保证。即使发布消失请求后，内容副本可能仍存在于网络其他地方，包括不支持 NIP-62 的其他中继、客户端设备上的本地缓存、第三方存档或搜索引擎，以及备份中。

请求本身也是一个签名的 Nostr 事件，意味着它成为你公开记录的一部分。任何看到消失请求的人都知道你删除了某些内容，即使他们看不到被删除的是什么。

对于必须保持私密的内容，应考虑使用 NIP-17 等加密消息方式，而非依赖事后删除。

互操作说明

NIP-62 是对 NIP-09 的补充。NIP-09 是 Nostr 中通用的删除请求事件，而 NIP-62 为中继提供了一个更强的消失导向信号，可以覆盖特定事件或整个公钥的内容集。实现可以同时支持两者，rust-nostr 的数据库后端现已提供关于该执行边界的配置选项。

主要来源：

提及于：

另请参阅：