# 《The Outbox Model and the Gossip Model》详细阅读笔记 ## 文章概述 这篇文章由 Mike Dilger 撰写（更新于2024年9月26日），旨在解释 Nostr 协议中的"Outbox Model"（出箱模型）和"Gossip Model"（流言模型）的概念，以及它们与 NIP-65 协议的关系。作者希望提供一个权威解释，避免重复回答相同的问题。 ## 核心问题背景 ### 传统模型的问题 在 Outbox Model 出现之前，Nostr 用户面临以下严重问题： - 用户需要手动配置中继(relay)列表 - 当两个人选择的中继集合完全不重叠时，会导致"为什么我找不到我关注的人的帖子？"的问题 - 更严重的是，用户甚至意识不到自己错过了什么内容（"没有人意识到不吠的狗"） - 临时解决方案是将内容复制到所有地方，导致用户配置数十个中继 - 这导致中继服务器负载过大，难以处理海量内容 - 为了确保中继列表与关注者重叠，用户被迫集中使用几个大型中继，削弱了 Nostr 的抗审查能力 - 攻击者只需击垮约5个中继，就能使一半的 Nostr 用户（尚未使用 Outbox Model 的）下线  ## Outbox Model（出箱模型） ### 设计目的 - 确保你能找到所有你关注的人的公开内容 - 确保你（和其他人）能找到对你发布内容的回复 - **仅适用于公开内容**，不适用于 Nostr 上的其他内容 ### 核心约束 - 必须**完全去中心化**：模型不能依赖你和你关注的人使用相同的中继 - 如果依赖特定中继，攻击者只需击垮这些中继就能实现有效审查 ### 工作原理 - 借鉴网站模型和 RSS 模型：你将内容发布到自己的网站，从他人的网站查找内容 - 在 Nostr 中的实现： - 你将内容发布到自己的**出箱中继**(outbox relays) - 从他人的出箱中继查找其他人的内容 - 通过 **NIP-65** 协议实现： - 创建数字签名事件，声明你发布的中继 - 可声明多个中继以实现冗余 - 将此信息传播出去 - 客户端工作流程： 1. 从你的公钥开始 2. 从可能已传播此信息的流行中继获取你的中继列表 3. 从你声明为出箱的中继下载你的事件 ### 优势与灵活性 - 可定义多个出箱中继 - 如果某个中继审查你，可以从列表中移除它，并可能添加更多中继 - 客户端应定期加载你最新的中继列表，以了解你当前发布的位置（以防被激进审查者追着跑） ## Inbox（收件箱） ### 设计目的 - 解决向他人发送私信的问题 - 当你@标记某人时，由于对方可能不关注你，无法期望他们在你的出箱中找到消息 ### 工作原理 - 人们选择用于接收消息的中继，并在中继列表中公布 - NIP-65 允许定义接收事件的 inbox 中继 - 当客户端标记某人时，应将该事件的副本发送到他们的收件箱 - 要查看某人帖子的所有回复，应该能在该人的收件箱中找到它们 > **注**：NIP-65 kind 10002 事件使用术语"write"表示 outbox，"read"表示 inbox ## 隐私问题 ### 隐私挑战 - 出箱模型解决了发现内容的问题，但也带来了隐私风险 - 为了让你的客户端找到并阅读我的内容，我可以将你的客户端引导到你从未听说、未配置且未验证过的中继 - 这类似于浏览器隐私问题：一个URL可能会引导浏览器从其他URL加载资源（如从Google获取字体），暴露浏览习惯 ### 解决方案 - 作者承认这是一个真实的问题，但认为已有解决方案：VPN和Tor - 客户端可以： - 要求用户批准连接到中继（麻烦！） - 要求客户端批准对中继的身份验证（这甚至更成隐私问题） - 终端用户可以： - 运行VPN或Tor（如果真关心隐私，这是必须做的） - 作者建议：Nostr开发者不应试图重新实现Tor或VPN已提供的功能，而应直接使用它们 - 最安全的方式是使用由安全专家设计的系统来使用Tor，例如qubes或whonix - Torsocks也应该安全，因为它在DLL层替换DNS查找，应该能获取全部 ## 模型图解  该图总结了使用_outbox模型_的客户端如何根据NIP-65与中继交互。 此外，文章还提到了一个优秀的[动画解释](

how nostr works

## Gossip Model（流言模型） ### 概念关系 - Gossip Model 是 Outbox Model 更一般形式的旧术语 - 本质上意味着"在 NIP-65 出现之前，gossip 客户端所做的事" ### 工作原理 - gossip 客户端动态确定人们在哪里发布内容（即使他们没有声明），并从那些中继获取帖子 - gossip 客户端跟踪人-中继关联，使用以下来源： | 来源 | 说明 | 可靠性 | |------|------|--------| | 手动输入 | 用户手动输入的关联 | 部分可靠，但需要用户操作 | | nprofile | 来自nprofile中继数据 | 可靠 | | NIP-05 | 来自 nostr.json 文件中的'relays'字段 | 不可靠（DNS已取消，是单点故障） | | kind 3 | 其他客户端发布到kind-3联系人列表事件中的'write'中继 | 非标准，许多客户端不提供 | | 推荐中继URL | 来自建议从何处获取由该人撰写的事件的事件标签 | 二手数据，非作者生成 | | kind 10002 (NIP-65) | 作者签名的中继列表元数据 | 作者声明，最可靠 | ### 分析 - 前3种来源来自Nostr外部，其中两种是手动输入，第三种不可靠（DNS） - NIP-05数据未数字签名，不应签名，因为nostr.json是由DNS域而非Nostr用户声明的 - 许多Nostr用户可能不想与任何DNS域关联 - 接下来的两种（kind 3和推荐中继URL）来自Nostr内部，但kind 3非标准，推荐中继URL是二手数据 - kind-10002(NIP-65)是为了弥补前五种方法的不足而创建的 - 不幸的是，当时很少有客户端创建这些（kind-10002事件），因此不能完全依赖 - 目前，gossip 客户端使用列表中的所有方法，其他遵循_gossip model_的客户端也应尝试这样做 ## Personal Relays（个人中继） ### 个人中继设置 该模型允许我们分散开来。一旦客户端充分采用它，你可以运行自己的中继，规则如下： **写入规则:** 1. 接受来自我的事件 2. 接受标记我的事件 3. 接受kind-10002事件 4. 拒绝所有其他事件 **读取规则:** 1. 允许我读取任何内容 2. 允许其他人读取我的事件 3. 允许其他人读取kind-10002事件 4. 阻止其他事件的读取 ### 优点与局限 - 适用于出箱和收件箱 - 无需审核任何内容（其他人不能写入然后读回他们写的内容） - 但会将对你笔记的回复对其他人隐藏 ### 实现示例 作者编写了一个通用中继 [Chorus](https://github.com/mikedilger/chorus)，默认以这种方式运行，但允许你审核和批准回复，以便公众最终可以看到这些回复（在你批准之后）。 ## 结论 Outbox Model 和 Gossip Model 通过 NIP-65 提供了一种完全去中心化的方式来解决 Nostr 中的内容发现问题，避免了过度依赖特定中继的风险，增强了网络的抗审查能力。尽管存在隐私挑战，但可以通过现有工具（如Tor和VPN）来解决。随着更多客户端实现 NIP-65，Nostr 网络将能够更好地扩展，支持更大规模的用户和内容。