NIP-10 指定 kind 1 笔记如何相互引用以形成回复线程。理解这一点对于构建对话视图至关重要。

工作原理

当有人回复一条笔记时，客户端需要知道：这是对什么的回复？对话的根在哪里？谁应该收到通知？NIP-10 通过 e 标签（事件引用）和 p 标签（pubkey 提及）回答这些问题。

标记式标签（推荐方式）

现代客户端在 e 标签中使用显式标记：

{
  "id": "f9c2e...",
  "pubkey": "a3b9c...",
  "created_at": 1734912345,
  "kind": 1,
  "tags": [
    ["e", "abc123...", "wss://relay.example.com", "root"],
    ["e", "def456...", "wss://relay.example.com", "reply"],
    ["p", "91cf9..."],
    ["p", "14aeb..."]
  ],
  "content": "Great point! I agree.",
  "sig": "b7d3f..."
}

root 标记指向发起线程的原始笔记。reply 标记指向正在回答的特定笔记。如果直接回复根笔记，只需使用 root（不需要 reply 标签）。这个区分对于渲染很重要：reply 决定线程视图中的缩进层级，而 root 将所有回复归为一组。

线程规则

  • 直接回复根笔记： 一个带 root 标记的 e 标签
  • 回复某个回复： 两个 e 标签，一个 root 一个 reply
  • root 在整个线程中保持不变；reply 根据你回复的内容而变化

通知与提及

包含所有应被通知的人的 p 标签。至少要标记你回复的笔记的作者。惯例是也包含父事件中的所有 p 标签，这样对话中的每个人都保持知情，加上你在内容中 @提及的任何用户。

中继器提示

e 和 p 标签的第三个位置可以包含一个中继器 URL，指示在哪里可以找到该事件或用户的内容。这帮助客户端获取被引用的内容，即使它们未连接到原始中继器。

互操作说明

早期 Nostr 实现从标签位置推断含义，而非使用标记：第一个 e 标签是根，最后一个是回复，中间的是提及。这种方式已被弃用，因为它会产生歧义。如果你看到没有标记的 e 标签，它们很可能来自较旧的客户端。现代实现应始终使用显式标记。

如果客户端想正确渲染较旧的线程，仍需要解析两种格式。在实践中，NIP-10 的互操作性部分是一个迁移问题：生产者应发出标记式标签，但消费者应对较旧的位置式形式保持宽容。

构建线程视图

要显示一个线程，获取根事件，然后查询所有包含引用该根的 e 标签的事件：

["REQ", "thread", {"kinds": [1], "#e": ["<root-event-id>"]}]

按 created_at 排序结果，并使用 reply 标记构建树结构。reply 指向根的事件是顶级回复；reply 指向其他回复的事件是嵌套回复。

主要来源：

提及于：

另请参阅：