引言 我最近发布了Kiyeovo的初始版本——一个去中心化的P2P消息传递桌面应用。我无法强调我在思考群聊时投入了多少时间。我提出的每一种模型都有一个重大缺陷，而这正是“无服务器”方面开始显现出问题的地方。我意识到没有“最佳”的解决方案，我必须做出一些权衡，以保持应用的完全去中心化。 为什么服务器使群聊变得简单 有了中央服务器，您就有一个可信的权威来回答这些问题：这个群组现在有谁？用什么密钥来加密消息，谁应该拥有它？消息的顺序是怎样的？我离线时错过了什么？即使是无法读取您消息的E2E加密应用，仍然使用服务器来解决这些问题。 Signal的服务器存储群组成员名单（并转发消息） Matrix家庭服务器存储群组状态并按照顺序处理事件 他们将群组状态交给新加入的用户，仅仅停止已删除用户接收更新和消息。内容是加密的，但协调（谁在，最新状态是什么，哪个先，您错过了什么）是由中央回答的。 删除服务器后会发生什么？没有一个“地方”可以明确知道成员名单，没有排序机来处理顺序，也没有24/7的邮箱来接收离线人员的消息。 2. 其他去中心化系统如何处理这个问题 — 以及我为什么走了另一条路 有一系列的处理方式，以下是我考虑的一些方式。 (a) 保持一个协调服务器（Signal，WhatsApp，Matrix） 内容是E2E加密的，但一个服务器（或家庭服务器）依然持有刚才提到的一切。群组密钥方案通常是： 发送者密钥：Signal - 每个发送者一个对称密钥，成员离开时旋转密钥 Megolm：Matrix - 每个发送者的逐步会话，在成员离开/加入时旋转 为什么不：这是一个坚决拒绝的选项，因为它包含集中化，这是我的一个非谈判条件。这违背了无服务器应用程序的目的——网络需要在没有“特权”点的情况下继续工作。 (b) MLS / TreeKEM（RFC 9420） MLS是群组加密的最先进技术。每个成员的密钥排列成一棵树，因此当您删除或添加某人时，只会触及树的一部分。换句话说，它的可扩展性非常高——即使在数千人的群体中也能保持快速。 为什么不：MLS需要一个“传递服务”来发送其密钥变更消息。在没有服务器的情况下，通过DHT，同行可以离线……这很复杂。此外，这棵树在大型群组中才真正发挥作用，而Kiyeovo的组较大限制在10人。 (c) 无领导会员 让任何成员添加或删除其他成员，最终通过一些合并逻辑达成一致。权威完全去中心化——没有管理员。 为什么不：当两个人同时更改成员资格时，同行可能会对谁实际上在群中有不同的看法。您可以最终将其合并，但合并规则变得复杂。例如，无法在没有可信时钟的情况下回答排序问题。“X是在他们刚刚发送的消息之前还是之后被踢出的？”如果成员不同意“全局事件顺序”，则没有答案。我曾考虑过设置一个工作量证明层，但那看起来太重了。 (d) 在创建时固定成员资格（例如，Briar风格的私密组）一些P2P应用通过不支持动态成员资格完全避免了这个问题：成员集在组创建时固定，您永远不会添加或删除任何人。 为什么不：这实际上是我的初始想法。然而，没有邀请或踢出的机制对我来说是一个很大的缺点。当我写这个的时候，我实际上在思考我所在的群组有多频繁地改变成员资格，答案是——并不那么频繁。这本来会简化事情，但现在功能已经完成，动态群体运作良好，所以这还是不错的。 3. 我实际上是如何做到的 规则：任何地方都不设置服务器，使收敛变得简单。 3.1 成员资格：一位创建者 每个组都有一个创建者，身份由一个Ed25519密钥识别。所有其他成员都有创建者的密钥，以便他们可以用它来确认更新确实来自他们。只有创建者可以邀请和踢人。想要退出的成员发送一份已签名的离开请求，由创建者进行删除。 优点：没有“两个管理员在分区期间踢了不同的人”的情况来合并——成员状态的合法写入者恰好只有一个。只有一个作者时，收敛变得简单->实际上这与(c)的方法相反。 缺点：创建者是一个单点故障。如果他们丢失了设备（身份）或只是离线——现有成员可以继续使用当前密钥进行交谈，但无法添加或删除任何人（用户仍然可以离开并不接收消息，但其他群组成员将没有验证通知表示X已离开群组）。 3.2 密钥：每个周期旋转发送者密钥 周期只是“群组版本”。每个周期都有一个全组共享的随机32字节对称密钥。消息...