NIP-09事件删除机制详解

draft optional relay

事件删除请求

一种 kind 为 5 的特殊事件，意为“删除请求”，定义为包含一个或多个 e 或 a 标签的列表，每个标签引用作者请求删除的一个事件。删除请求应当为每个被请求删除的事件包含一个 k 标签，以指明该事件的 kind。

事件的 content 字段可以包含一条文本备注，描述删除请求的原因。

例如：

{
  "kind": 5,
  "pubkey": <32字节十六进制编码的事件创建者公钥>,
  "tags": [
    ["e", "dcd59..464a2"],
    ["e", "968c5..ad7a4"],
    ["a", "<kind>:<pubkey>:<d-identifier>"],
    ["k", "1"],
    ["k", "30023"]
  ],
  "content": "这些帖子是意外发布的",
  // 其他字段...
}

Relay 应当删除或停止发布任何与删除请求具有相同 pubkey 的被引用事件。客户端应当隐藏或以其他方式指示被引用事件的删除请求状态。

Relay 应当无限期地继续发布/共享删除请求事件，因为客户端可能已经拥有那些意图被删除的事件。此外，客户端应当将删除请求事件广播到其他尚未拥有该事件的 relay。

当使用 a 标签时，relay 应当删除该可替换事件的所有版本，直至删除请求事件的 created_at 时间戳。

客户端用法

客户端可以选择完全隐藏任何被有效删除请求事件所引用的事件。这包括文本笔记、直接消息或其他尚未定义的事件 kind。或者，它们可以显示该事件，并配上一个图标或其它指示，表明作者已“放弃”该事件。content 字段也可以用来替换被删除事件自身的内容，但用户界面应明确表明这是删除请求的原因，而非原始内容。

在隐藏或删除任何事件之前，客户端必须验证删除请求的 e 标签中引用的每个事件的 pubkey 是否与删除请求的 pubkey 相同。Relay 通常无法执行此验证，因此不应被视为权威。

客户端可以以任何方式显示删除请求事件本身，例如完全不显示，或带有醒目的通知。

客户端可以选择告知用户，其删除请求并不能保证删除，因为要从所有 relay 和客户端中删除事件是不可能的。

Relay 用法

Relay 可以验证删除请求事件仅引用与删除请求自身具有相同 pubkey 的事件，但这不是必需的，因为 relay 可能不知道所有被引用的事件。

对删除请求的删除请求

发布针对另一个删除请求事件的删除请求事件无效。客户端和 relay 没有义务支持“取消删除请求”功能。

• 原文链接： github.com/nostr-protoco...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～