> For the complete documentation index, see [llms.txt](https://sherry-pang.gitbook.io/nostr-cn/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://sherry-pang.gitbook.io/nostr-cn/fu-lu-1-nip-xiang-jie/65.md).

# NIP65

## 中继列表元数据

`draft` `optional` `author:mikedilger`

表示“中继列表元数据”的特殊可替换事件被定义为具有标签列表的 `r` 事件 `10002`，作者用于读取或写入的每个中继都有一个标签。

此中继列表的主要用途是向其他人通告，而不是配置自己的客户端。

内容未使用，应为空字符串。

标记的 `r` 第二个参数可以是 `read` 或 `write`。如果省略，则表示作者将继电器用于两个目的。

与所有可替换事件一样，客户端应仅使用它们可以找到的最近的 kind-10002 事件。

### 读和写的意义

写中继适用于针对任何人的事件（例如你的关注者）。读取中继用于针对特定人员的事件。

客户端应将其用户创建的与 Feed 相关的事件写入其用户的写入中继。

客户端应至少从另一个人的一些写入中继中读取该另一个人创建的与馈送相关的事件。显然，他们不应期望它们在其用户的读取中继上可用。不应假定用户的读取中继与用户跟随的人的写入中继一致。

客户端应从其用户的读取中继中读取标记其用户的事件。

客户端应将标记人员的事件至少写入该人员的某些读取中继。显然，他们不应期望该用户将从其用户的写入中继中获取它们。不应假定用户的写入中继与被标记用户的读取中继一致。

客户端应该假设，如果他们的用户在他们的联系人列表（类型 3）中有一个 pubkey，这是因为他们希望看到作者的 Feed 相关事件。但客户可能会有不同的假设。

### 动机

有一个常见的 NOSTR 用例，其中用户希望跟踪其他用户生成的内容。中[NIP-02](/nostr-cn/fu-lu-1-nip-xiang-jie/02.md)的联系人列表的隐含含义证明了这一点

由于用户通常不会共享相同的中继集，因此出现了一些专门的解决方案来获取这些内容，但这些解决方案会对可扩展性和分散化产生负面影响：

* 大多数人都把他们的帖子发送到同样最受欢迎的中继站，以便被更广泛地看到。
* 为了获得更多的数据，许多人正在从大量的中继（包括许多重复的事件）中提取数据
* 事件在中继之间复制，通常复制到许多不同的中继

### 目的

这个 NIP 的目的是帮助客户找到他们关注的人的事件，帮助标记的事件到达标记的人，并帮助 NOSTR 更好地扩展。

### 建议

建议人们将他们的同类 `10002` 事件传播到许多中继，但将他们的正常反馈相关事件写入数量少得多的中继（2 到 6 个中继之间）。建议客户端为用户提供一种方法，将他们的同类 `10002` 事件传播到比他们通常发布到的更多的中继。

作者可以通过将事件发布到他们的“中继列表元数据”中列出的中继之外的中继，来发布他们希望其关注者关注的提要之外的事件。例如，作者可能想要在没有其所有关注者观看的情况下回复某人。

建议中继允许任何用户编写他们自己的 `10002` 事件（可选择使用 AUTH 来验证它是他们自己的），即使他们没有以其他方式订阅中继，因为

* 找到某人发帖的地方相当重要。
* 这些事件没有需要管理的内容
* 中继只需要为每个公钥存储一个可替换的事件来提供此服务

### 为什么不是实物元 `0` 数据

尽管这是与用户相关的元数据，但它是一个独立于种类 `0` 的事件，以使其保持较小（因为它应该广泛传播），并且不具有可能需要中继运营商审核的内容，以便中继更容易接受。

### 例子

```json
{
  "kind": 10002,
  "tags": [
    ["r", "wss://alicerelay.example.com"],
    ["r", "wss://brando-relay.com"],
    ["r", "wss://expensive-relay.example2.com", "write"],
    ["r", "wss://nostr-relay.example.com", "read"],
  ],
  "content": "",
  ...other fields
```