NIP-02 定义了 kind 3 事件，用于存储用户的关注列表。此事件是首页信息流、回复通知以及许多中继器选择策略的基础输入。

工作原理

一个 kind 3 事件包含列出已关注 pubkey 的 p 标签：

{
  "id": "d7a8f...",
  "pubkey": "a3b9c...",
  "created_at": 1734912000,
  "kind": 3,
  "tags": [
    ["p", "91cf9..af5f", "wss://alicerelay.example.com", "alice"],
    ["p", "14aeb..8dad", "wss://bobrelay.example.com", "bob"],
    ["p", "612ae..982b", "", ""]
  ],
  "content": "",
  "sig": "e4f8a..."
}

每个 p 标签有四个位置：标签名称、被关注的 pubkey（hex）、可选的中继器 URL 提示以及可选的"昵称"（本地昵称）。中继器提示告诉其他客户端在哪里可以找到该用户的事件。昵称让你可以为联系人分配容易记忆的名称，而不依赖他们自行声明的显示名称。

可替换行为

Kind 3 属于可替换范围（0、3、10000-19999），因此中继器仅保留每个 pubkey 的最新版本。当你关注新用户时，客户端会发布一个包含所有已关注用户加上新用户的完整 kind 3 事件。这意味着关注列表每次都必须是完整的，不能发布增量更新。

重要意义

要构建首页信息流，客户端获取用户的 kind 3，提取所有 p 标签中的 pubkey，然后订阅这些作者的 kind 1 事件：

["REQ", "home", {"kinds": [1], "authors": ["91cf9...", "14aeb...", "612ae..."], "limit": 50}]

中继器返回匹配的笔记，客户端进行渲染。Kind 3 中的中继器提示帮助客户端知道应该向哪些中继器查询每个已关注用户的内容。

这也是过期社交状态最先显现的地方。如果用户最新的 kind 3 在你查询的中继器上缺失，即使他们的关注列表仍存在于其他地方，信息流看起来也可能是空的。从多个中继器合并结果的客户端通常比信任单个中继器的客户端恢复得更好。

昵称与身份

昵称字段实现了一种去中心化的命名方案。你可以分配自己的标签，而不是信任用户在其个人资料中声明的名称。客户端可能显示"alice（我的姐姐）"，其中"alice"来自她的 kind 0 个人资料，“我的姐姐"是你的昵称。这提供了全局用户名无法提供的上下文。

互操作说明

因为 kind 3 事件是可替换的且必须是完整的，客户端在更新时应保留未知标签。如果另一个客户端添加了你的客户端不理解的标签，盲目覆盖会导致数据丢失。

同样的注意事项适用于中继器提示和昵称。它们是可选字段，但在写入时丢弃它们可能会悄无声息地降低其他客户端的体验。安全的更新路径是：加载最新的已知 kind 3，仅修改你理解的标签，保留其余部分，然后重新发布完整事件。

主要来源：

提及于：

另请参阅：