Michael Dilger、Pablof7z、jb55: 如何改进Nostr 中继

YakiHonne 社区对 Nostrasia 充满了热情，目前正在对 Nostrasia 大会的精彩演讲进行了文字转录，以便大家阅读。 转录的工作正在进行，我们将逐步发布更多的转录文章。 日语和西班牙语版本由社区成员用AI工具初步进行翻译和校对，欢迎所有 YakiHonne 用户参与审核校对。 完成审核后，将获得3000 Sats的特别奖励。 联系我们（在这里评论、DM 或 TG）报名参与，第一个报名并提交审核的人将收到奖励。 欢迎参与并将这些演讲转录文章翻译成更多语言。 加入我们吧！

🌟English: The Gossip Model 🌟日本語: ゴシップモデル 🌟Español: El modelo del chisme

我是迈克尔·迪尔格(Michael Dilger)，就职于Gossip客户端。今天我要分享的是关于“中继会晤(Relay Rendezvous)”的演讲。原本这个演讲是以“Gossip模型”为主题的，但我认为更合适的表达应该是“中继会晤”，因为这更准确地描述了我们要讨论的内容。毕竟，“Gossip模型”只是客户端的名称而已。

在实现“中继会晤”时，有两种常见的方式，分别是收件箱模型和发件箱模型。我认为我们可以采用这些术语来更清晰地表达。因此，我们将不再深入“Gossip模型”的概念，而是专注于这两种方式。我相信“中继会晤”更能准确地解释我们试图探讨的内容。

想象一下 nostr，通过中继传输的笔记和其他内容。在这个过程中，客户端将事件放置在一个中继上，并出于某种目的将其留在那里。重要的是，并不是仅仅把事件放在某个中继上，就完事了，而是最终会有人前去那个中继，将事件取回以获取信息。

因此，我们面临一个问题，即为什么选择中继以及如何选择中继。在 nostr 中，我遇到了大约 300 个中继。如果你只是把你的事件放在某个中继上，期望别人能找到它，但他们实际上并未使用相同的中继，那效果就不会太好。因此，有几种模型可供选择。

其中一种被称为收件箱模型，类似于电子邮件。通过电子邮件，你可以订阅一个通讯，通讯的作者会每周将通讯发送到你的电子邮件。在这个情境下，事件的创建者将其放在一个特定用途的中继上。

另一种模型是发件箱模型，更像是一个网站。它不是为特定的个人准备的，而是为所有人。

我参与的 nostr 中的第一个应用是某种 Twitter 克隆，类似于微博。在这种情况下，如果我想发布一些东西供人们查看，他们需要知道我应该在哪个中继上发布。如果他们关注我，但我将其发布到芬兰的中继，而其他人使用德国的中继，他们将无法找到它。

这些中继并不会相互交流，它们实际上是孤立的。因此，如果人们想关注我的内容，就需要某种方式告诉他们：“嘿，我正在这个芬兰的中继上发布。”有一个 NIP 65，基本上是一种告诉人们你在使用哪些中继以及它们用途的方法。我们最初选择的两种用途是发件箱，表示“这是我发布东西的地方。如果你感兴趣，请来这里。”另一种用途是收件箱，表示“如果你希望我阅读一些东西，请将其放在我的收件箱，因为我会密切关注标记我的事物。”

在进一步讨论之前，我要为我不知道帕布罗会出现在这么多小组中而道歉。但在我们深入探讨更多内容之前，你们有什么想要分享或提问的吗？

因此，在这次演讲中，我将讨论的主题是，有许多不同的方式可以存储笔记并从中继检索笔记，这实际上取决于具体的用例。

当我首次创建我的客户端时，我研究了一些来自 Fiat-Jaf 的代码，他提出了一个称为中继池的概念。这是 nostr 上可能是最简单的方法，虽然在分散化等方面可能存在问题，但对于初学者来说是个不错的选择。中继池提供了一种非常简单的方式来推送和检索笔记，只需维护一个中继数组，选择要发布的中继，然后编写一小段代码将笔记推送到这些中继。当然，在考虑分散化等方面可能存在的问题时，这只是一个入门的简单方法。

这就是我在 Damus 中采用的方式，而我在 Damas 中仍然保留了这个模型。当然，并不是说这是最佳的分散化方式，因为正如你刚才提到的，存在很多问题。但如果你只是想建立一个社交媒体网络，只需将这些中继放在你的个人资料中，人们就可以阅读你的个人资料，假设他们一开始就能获取到，然后他们就可以访问笔记，这样就能实现一定程度的抗审查性。 因此，我觉得这就像是尝试 nostr 这个理念的最简单模型之一。但除此之外，还有很多其他的模型，其中Gossip是其中之一。这个收件箱和发件箱，我猜被认为是发件箱模型。但我想要讨论的是，实际上还有其他获取和检索数据的方式，以及完全不同的模型，现在没有人真正讨论。

我想要尝试在 nostr 上构建异步通信，类似于电子邮件，因为我不再想使用电子邮件，我希望将一切都搬到 nostr 上。因此，我考虑的是，如果你在运行邮件列表，你有一个代表邮件列表的中继。于是，人们可以向该中继发送笔记。

这有点类似，因此，中继本身可以被视为邮件列表本身。唯一的问题是，如果人们只是将其添加到中继池中，如果他们正在使用类似于会费模型的模型，那么你只是从随机的人那里收到一堆随机的消息。因此，像基于社区的中继或那些非常特殊目的的中继实际上不太有效，因为人们只是向它们发送笔记。

为了解决这个问题，我一直在思考如何解决这个问题，我想做的一件事是在笔记上添加类似于“to”、“CC”以及不同类型的元数据，以便当你的邮件列表中继收到一个笔记时，它确实确保它是打算发送到那个特定中继的。

总的来说，我认为有很多不同的方式。在 nostr 上发送和接收笔记有许多不同的方法，我想传达的主题是没有像做这件事的最佳方式。你知道，也许Gossip模型，我猜我不应该说是令人敬畏的模型，但也许在社交媒体环境中这可能是去中心化的最佳方式。但是，如果我想构建其他类型的协议，如电子邮件或同步通信或邮件列表，可能有不同的方法来发送和接收笔记，我认为我们只是开始探索不同的方法，无论如何，这只是我的观点。

因此，我想说这些不同的模型基本上是我们必须考虑你解决的问题是什么，以及什么模型会正确解决问题，我认为微博客的事情我想发件箱解决了它，我惊讶地发现活动发布以与收件箱模型相反的方式进行微博客，它也有用，具有不同的属性。

发送人，你知道，联邦到另一个活动发布服务器的人可以切断它，不继续提供那些信息。因此，它不像发布 RSS 源那样，任何人都可以过来获取它。然后还有其他模型，你知道，像聊天服务器模型或现场事件，你去一个中继。每个人都必须一起会晤到同一个中继。可能还有更多我们没有考虑到的模型。

这就是为什么 Fiatjaf 前几周或一个月前写道，将这些东西规范化会很有趣。我坚决反对那个想法，因为我认为我们正在开始探索这一点，我们根本不知道什么是有效的。我完全同意，我认为这将以不同的方式工作，具体取决于你尝试做什么。

关于专题中继，你们有关于像 CC 和 BCC 到中继这样的想法吗？因为你说的像 CC 和 BCC 到中继，这并不能阻止客户端说 CCC，我要将所有中继都 CC 进去，我要构建一个池，但我只是要 CC 一切。

但在那一点上，你正在构建一个相当讨厌和恶意的客户端。那么基本上你正在构建一个垃圾邮件的东西，对吧？但默认状态是，你知道，如果我们想开始构建使用这种新的类似电子邮件的会晤协议的客户端，那么你知道，我假设它不会只是 CC 所有人。那不是整个目的。

就像添加元数据的整个目的是你希望消息到达特定位置。这实际上是远离的，但当你开始做这些事情时，它变得不那么抗审查了。因为你不再将其发送到所有中继，而是将其发送到特定中继，然后你可能会被审查。

所以我认为我想改变人们对此的看法的一件事是，实际上拥有受审查的模型是可以接受的，对吗？每个人都非常关注，我知道 Verer 经常谈论这一点，在他的受审查的社区中，他真的希望它能够跨越许多不同的中继，因此它是抗审查的。这是可以的。但我认为在某些方面，完全可以使用可以轻松审查的协议方式。如果你在公司内部有一个中继，你要确保它只有你的员工的笔记。就像你在技术上审查所有人一样。也许我们，你知道，我认为人们应该改变他们的思维方式。

就会有其他类型的模型，不会完全是去中心化的。你不需要设计协议以便必须将其发送到六个不同的中继。完全可以将其发送到特定的中继。我们只需要更好的方式在笔记上进行通信，以便你不只是在你的特定中继上获取随机笔记。

我对抗审查的看法是，我们需要对一些事情进行抗审查；抗审查是非常昂贵的，你想要它越抗审查，它在协议的结构和架构方面就越昂贵。但我们实际上想要的是抗审查是一个手段，我认为目的是无需许可的创新，我认为我们可以拥有无需许可的东西。对于像你所解释的一些事情，我们可以在中继级别进行局部审查，如果你参与社区，你可能会被审查，如果你被审查，而且你不想参与社区，你可以去其他地方，对吗？

在谈论像这样的社区时，我认为有不同的方法可以正确执行。维克多有他的方法，更注重抗审查，关注社区中继，这个中继是关于这个特定社区的。我认为我们将以各种方式尝试，然后我们将，你知道，这将会像一个思想的市场，其中一些可能比其他更有效，因为从我们现在的角度来看，我们有很多探索要做。

是的，完全是，为了完成之前的思想，这就是为什么我喜欢 NIP 65，因为即使在你成为社区的一部分的模型中，一个基于中继的社区，你被这个中继审查了，参与讨论的人仍然可以选择去其他地方获取你的笔记，如果你被这个社区审查，你可以被社区领导暴露，但人们可以选择仍然从其他地方获取你的笔记，所以这就像社区的一个分叉。

对，你还想说什么吗？

你们认为关于专题中继，你们认为中继是否应该有一种方式来保护自己免受内容的影响，这种规模能够工作吗？

我不确定你是什么意思，但是某种形式的内容审核。

例如，我想运行通常的，例如哲学中继，我只想要哲学讨论。我想要的是我希望能够去 gbobal 并且说不要空投。我只想要哲学讨论。例如，如果我创建了 philosophicalrelay.com 并且人们将其添加到 Damus、primal、gossip 中，他们开始讨论足球，这也会发布到哲学中继，我可以白名单 pub key，说：“哦，是的，这个家伙 25% 的时间在谈论哲学，但我仍然得到了其他 75% 的东西，所以你需要检查每个单独的节点，你们认为这种模型能够工作吗？

嗯，对我来说，它总是回到你需要在节点上做一些标记，比如在内容中标记这是关于哲学的。无论是他明确地将其发送到哲学中继，使用两个概念，或者可能有一种方法来标记主题，比如可能不是哈希标记或者可能可以使用哈希标记；它与哈希标记重叠。它与哈希标记重叠，与这些所有种类的标记重叠。这些想法没有完全不相交。是的，所以中继可以拒绝一切没有哲学哈希标记的东西，或者可能白名单来自所有基于哲学的帐户的 pub key，这可能是我不知道是否是最佳方式。

我认为 Nostr.wine人们正在尝试；他们尝试使用哈希标签为主题的中继，但好像没有成功。

是的，最大的问题是人们会对它们大量垃圾邮件，所以，你知道，我想要在 Damus 中添加的一件事，我不知道我们现在是否离题了，我们正在谈论哈希标签，这将是一个简单的事情，就像也许在节点上的第一个哈希标签是被计算为主题的标签，所以你不能随意垃圾邮件。

抱歉，我正向我的项目说这番话，我早些时候在做一些关于一些称为 info triples 的元数据的东西，所以我正在努力解决这个问题，所以让我们稍微离开一下。好的，很好。

是的，是的，我们绝对需要所有的想法，你知道我认为这样的社区、主题以及如何实现它们，它们应该是基于社区的，它们应该是受审查的社区，这些都是我们现在仍然在弄清楚的思想，但我认为是的，就像 Mike 说的，我们将尝试所有的事情，看哪些工作得最好的社区。

关于你的模型，我真的很喜欢那种电子邮件的思想，比如如果中继有一个像 npub 的身份，大多数时候就像你想，我不知道，你特别想将其发送到特定的位置，因此只是拥有它是很好的，有了身份，但你仍然希望将笔记发送到某个地方，这就是我在考虑的，你知道，你可能希望中继在笔记本身中。

我认为中继具有身份并与身份交流或引用身份而不是 URL 更多地是一种间接方式，它是在说：“我将这个发送到这个 pubkey 中继，这在某种程度上映射到说，嗯，目前在这个 DNS 上，但由于我们无法控制 DNS，这可能会改变，你可能会重新映射，但它仍然是相同的 pubkey，因此你对中继有一个标识，可以移动到不同的 DNS 地址，这是我昨天刚听说的，我们昨天正在谈论这个，因为我在考虑提示以及在 10 年后发生了什么，当 URL 都混乱了，如果你有一个 PA，你可以更轻松地移动它们，就像你可以轻松切换并保留所有的提示一样，而 URL 很难控制对吧。

我认为在 Damus 中你不能做太多的狩猎工作，因为嗯，我有固定的中继，我不想从随机的中继中拉取，它们会随着时间的推移而死亡，无论如何，我是指在 Damus 的早期我们没有进行任何签名验证，因此如果我们使用Gossip模型，那将是一场灾难，因为人们可以随便发送给你，但现在我们确实检查签名，这是其中一个重要原因，但也要知道，在 Damus 的早期，人们会构建非常有缺陷的中继，它们会完全破坏 damas，并且一些是恶意的，我认为 Damus 对那些中继还没有真正加固，因此你可以在配置文件中放一些东西，但是从中继读取，并且你可以破坏用户体验，所以。

当我思考这个问题时，我发现一个很好的例子可以解释我的观点。想象一下，当你访问一个网站时，该网站告诉你的浏览器加载Google字体。这时，你的浏览器就会连接到Google，于是Google知道了你正在访问的网站。但是，我个人并不希望Google知道我的在线行踪，所以我使用了一个叫做uBlock Origin的浏览器插件。这个插件让我能够精确地控制哪些资源可以加载，哪些不可以。虽然我并不在意Google字体的设计，但我并不希望Google一直知道我的位置，所以我选择了阻止它。这种情况在Web客户端中很常见，它们会自动加载未经用户许可的资源。我认为我们不应该重复这种行为。相反，我认为我们需要更智能的客户端。我们仍然可以使用outbox模型，但是让用户来控制白名单，即告诉客户端从哪里获取信息，以及黑名单，表示客户端知道某个中继存在问题，我们不会使用它。我对某个中继是否列在用户的outbox中并不关心；我们只关心是否使用它。

是的，我计划让系统更加去中心化，更倾向于从随机的中继中获取信息。我正在考虑一些列入黑名单的方法，通过一些测试来发现中继的不当行为。如果用户注意到某个中继的问题，他们甚至可以在他们的客户端中编码，使其自动加入黑名单。我在NDK上实现outbox时就已经考虑到了这一点，在同一提交中引入了黑名单，因为我确信这是基本的100%需要的。

在解决damus体验中破坏的问题时，我强调了对抗恶意中继的必要性。用户可能会被欺骗将一个恶意中继添加到他们的配置文件中，虽然这不是自动的，但用户需要保持警惕。我坚持认为用户应该对决策负责，而不是由计算机来决定。

此外，对于恶意中继的限制，我认为它们实际上无法做太多。它们只能向你发送一个事件，该事件只包含一些简单的字段，基本上是一些字符串，并且是否签名成功。攻击面相对较小，至少我目前想不出太多问题。当然，还有一些需要加强的地方，比如中继可能返回广告或者伪造信息。尽管有Web of Trust等机制，但有时候可能会有一些奇怪的情况。因此，在我感到满意之前，我需要加强damus的安全性。

至于在damus上检查中继返回的结果，比如查询其他公钥的返回结果，我并没有进行严格的检查。我有时会检查，但并非总是。由于我是最古老的Nostr客户端之一，所以这方面可能会有些奇怪。但我正在逐步改进，努力解决所有这些问题。在Nostr数据库中，我的计划是使其更本地化，更开放，可以从随机的中继中拉取，并且我考虑在其中构建一些逻辑，以便在Damas Android和其他应用之间重复使用。

因此，我开始实施outbox模型的原因是，当我大约一年前开始编写客户端时，我意识到我希望关注不同的人，但我并不知道他们的笔记在哪里。我知道astral和Damus在内容上共享中继列表，所以我就借此来获取这些笔记，以关注他们。此外，我推荐人们将中继放在nip 5和Fiatjaf中，这实际上是我对NIP的第一个贡献。所以，我认为人们在放置他们的中继时有不同的方式，我刚开始时只是假设他们都这样做，甚至没有注意到其他客户端只是在选择中继作为中继池。

在Damus的情况下，我尝试构建一个去中心化社交网络的证明。有一些中继是由不同的人拥有的，我认为这已经足够了。就像我说的，只需将信息发送到这些中继并从中获取信息。当然，如果你考虑更大、更分散的整体，从长远来看，这是行不通的。这就是为什么Damus可能会过渡到更多outbox模型的原因，不管这些模型现在被称为什么。现在，我们有了炸薯条中继，它们运行非常快。这是我一直在努力做的事情之一，虽然还有一些工作要做，但是这是非常重要的。

实现这个系统并不容易，因为技术上的复杂性很高，而且这个模型相当模糊，不太引人注目。人们甚至可能注意不到你正在进行这样的工作，甚至可以争论这可能会降低应用程序的性能。

你提到你在实施过程中遇到了许多问题，这绝对不是一个简单的实现。例如，我曾经遇到了一个持续了近一年的bug，发现一些中继错误地被分配给我关注的150个人。结果证明，实际上只有15个中继。客户端错误地将公钥分配给了存在数据库连接但分配得分非常低，甚至可能为零的中继，因此不应该进行该分配。要使连接到尽可能少的中继成为最小化的问题，以覆盖我关注的每个人至少两次，以确保冗余，并且中继与个人之间的关联较高，这在某种程度上可能是一个棘手的优化问题。

我认为这种模型最有吸引力的地方，也是我想要实施它的原因，是人们可以运行自己的中继，就像他们可以在家里运行中继一样。如果可以公开访问并且实际上有用，不仅仅是作为备份存在，这对我来说是很重要的。现在，我们没有一个非常有说服力的理由来运行中继。唯一有说服力的理由是备份，但这并不是足够好的理由。但是，如果人们开始采用这种模型，并且所有与你相关的事件都被写入你的中继，那么即使作为备份，它也更加完整。

另一个有趣的方面是我一直在思考中继的隐私问题。尽管Nostr中的所有内容都是公开的，但几乎所有发送到中继的请求都只是特定于该中继的。现在，所有客户端基本上都会查询连接的所有中继的所有内容。因此，你连接的所有中继都能够准确地看到你在做什么，你正在请求什么。如果你访问某人的资料并滚动，他们确实能够知道你每天早上都在查看这个人的资料，你在偷窥这个人，对吧？我认为Gossip协议也可以帮助解决这个问题，例如，我将向这个中继发送一些请求。我知道这三个中继在事件方面非常相似，所以我将进行分页，而不是同时在所有中继上请求所有内容。我会在这里发送一些请求，这样你的行为图谱就会变得有些困难。

整个系统变得更加分布式，对于可伸缩性来说是好事，因为你可以分散开来。我刚刚忘记的一件事是，能够扩展和能够摆脱已经成为审查等中心化事物之间存在差异，而实际上只是无谓地扩展，对吧？可能 50 个中继是我们永远需要的全部，我们不知道。我是说，50 个中继对我来说听起来像是很多竞争，但你必须始终有能力说不，我不喜欢其中任何一个，我想要自己的，我想添加一个不同的，所以你必须有这种自由。并不一定是我们都必须拥有自己的个人中继，但有些人可能会这样做。

我认为，为了让50个中继发挥作用，我们需要考虑Nostr的未来发展，是否会倒闭或者变成一个小众产品，用户规模达到1万或10万人。这也与中继的商业模式有关。当用户数量达到数十亿时，50个中继可能就显得不够了。这引发了一个有趣的问题，因为中继在经济运营中的作用尚未完全明确，特别是在Nostr目前处于孕前阶段的情况下，这是一个尚未解决的关键问题。

目前我们拥有的中继数量实际上比50多得多。Melin Carvalos一直在讨论关于中继和可持续性的问题，他提到中继的数量正在减少。这是有道理的，因为现在运行中继主要作为备份，但是如果Nostr的用户数量增长100倍，就需要更多的专业中继，比如Nostr Wine和Eden。关于中继的投资，像Eden这样的大中继每月大约需要300美元，这在现阶段可能不算多，但如果Nostr增长迅速，投资将会成为一个考虑的问题。

此外，在讨论发件箱模型时，我认为将其与异步模型和电子邮件的想法结合是非常有趣的。通过将中继信息整合到电子邮件客户端中，可以更方便地使用和管理。对于私信中继，我们还没有详细讨论，但有可能有不同类型的中继用于不同用途，比如私信和收件箱。

另一个有趣的点是处理特定类型的中继。例如，我运行的purple page是一个为kind 0和1002以及nip 65服务的中继，客户端可能需要更优秀地选择中继以匹配其执行或设计的任务。这也涉及到需要为中继制定规范，以便客户端能够更智能地选择中继。

最后，关于使用命令结果来自动配置中继的想法，这是一个有趣的方向。在Nostr中添加了命令结果是一个不错的举措，它可以提供关于写入是否成功的信息。通过将命令结果与中继的自动配置结合使用，可能会使整个系统更加智能和高效。

好的，我们可以在这里暂时停下，谢谢你的分享，很有启发性！

---

About YakiHonne:

YakiHonne is a Nostr-based decentralized content media protocol, which supports free curation, creation, publishing, and reporting by various media. Try YakiHonne.com Now!

Follow us

• Telegram: http://t.me/YakiHonne_Daily_Featured
• Twitter: @YakiHonne
• Nostr pubkey: npub1yzvxlwp7wawed5vgefwfmugvumtp8c8t0etk3g8sky4n0ndvyxesnxrf8q
• Facebook Profile: https://www.facebook.com/profile.php?id=61551715056704
• Facebook Page: https://www.facebook.com/profile.php?id=61552076811240
• Facebook Group: https://www.facebook.com/groups/720824539860115
• Youtube: https://www.youtube.com/channel/UCyjDDtWFCntGvf4EyFJ7BlA