群聊在去中心化系统中应该如何运作？

简介 我最近发布了 Kiyeovo 的初始版本 - 一个去中心化的 P2P 即时通讯桌面应用程序。我无法强调花了多少时间来考虑群聊。我提出的每个模型都有一个重大缺陷，这确实是“无服务器”方面开始受到伤害的地方。我意识到没有“最佳”方法可以做到这一点，并且我必须选择一些权衡以保持应用程序完全去中心化。为什么服务器使群组变得容易 有了中央服务器，您就有了一个值得信赖的权威来回答以下问题：现在谁在这个群组中？什么密钥对消息进行加密？谁应该拥有它？消息发生的顺序是什么？我当时处于离线状态；我错过了什么？即使无法读取您的消息的端到端加密应用程序仍然使用服务器来解决这些问题。 Signal 的服务器存储组名册（并转发消息） Matrix 主服务器存储组状态并订购事件 它们将组状态交给新添加的用户，并简单地阻止已删除的用户接收更新和消息。内容是加密的，但协调 - 谁在，最新状态是什么，最先发生的事情，你错过了什么 - 得到集中回答。删除服务器会发生什么？没有一个“地方”可以确切地知道名单，没有用于订购的排序机，也没有为离线人员提供的 24/7 邮箱。 2. 其他去中心化系统如何处理它——以及为什么我采用了另一种方法 有各种各样的方法，下面是我考虑过的一些方法。 (a) 保留协调服务器（Signal、WhatsApp、Matrix） 内容是 E2E 加密的，但服务器（或家庭服务器）仍然保存刚才描述的所有内容。这里的组密钥方案通常是： 发送者密钥：信号 - 每个发送者的对称密钥，当成员离开 Megolm 时轮换密钥： 矩阵 - 每个发送者棘轮会话，在成员离开/加入时轮换 为什么不：这是一个硬通行证，因为它包括集中化，这是我不可协商的事项之一。这违背了无服务器应用程序的目的——网络需要在没有“特权”点的情况下继续工作。 (b) MLS / TreeKEM (RFC 9420) MLS 是最先进的组加密技术。每个成员的密钥都排列在树中，因此当您删除或添加某人时，它只会触及树的一部分。换句话说，它具有很强的可扩展性——即使在数千个群体中也能保持快速。为什么不呢：MLS 需要一个“传递服务”来分发其密钥更改消息。在没有服务器的情况下，通过 DHT 来完成这件事，其中对等点可以离线......是很多。而且，该树仅在大群体中真正获得回报，而 Kiyeovo 群体上限为 10 (c) 无领导成员资格 让任何成员添加或删除其他成员，并最终通过一些合并逻辑收敛。权限是完全去中心化的——根本不需要管理员。为什么不呢：当两个人同时更改成员资格时，其他人可能会得到关于该组中实际成员的不同照片。您最终可以将它们合并在一起，但合并规则会变得很棘手。例如，如果没有可信的时钟，就无法回答订购问题。 “X是在他们刚刚发送的消息之前还是之后被踢的？”如果成员不同意“全球活动秩序”，则不会有任何答复。我曾考虑过建立一个工作量证明层，但这似乎太重了。 (d) 在创建时修复成员身份（例如 Briar 风格的私人群组） 一些 P2P 应用程序通过不支持动态成员身份来避免整个问题：成员集在创建群组时是固定的，并且您永远不会添加或删除任何人。为什么不呢：这实际上是我最初的想法。然而，没有受到邀请或踢球对我来说是一个很大的缺点。当我写这篇文章时，我实际上在思考我所在的团体多久更换一次成员资格，答案是——不那么频繁。这本来可以大大简化事情，但现在它已经完成并且动态组可以工作，所以这非常好。 3. 我实际上是如何做到的 规则：任何地方都没有服务器，使收敛变得微不足道。 3.1 成员身份：一名创建者 每个群组都有一名创建者，由 Ed25519 密钥标识。所有其他成员都拥有创建者的密钥，因此他们可以使用它来确认更新确实来自他们。只有创建者才能邀请和踢出。想要退出的成员会发送签名的休假请求，创建者会应用删除操作。优点：不存在“两个管理员在分区期间踢了不同的人”的情况来合并——只有一个合法的成员状态编写者。当只有一位作者时，收敛很简单 -> 这实际上与方法 (c) 相反。缺点：创建者存在单点故障。如果他们丢失设备（身份）或只是不在线 - 现有成员可以继续使用当前密钥进行通话，但不能添加或删除任何人（用户仍然可以离开并且不会收到消息，但其他群组成员不会收到 X 离开群组的经过验证的通知）。 3.2 密钥：每个纪元轮换的发送者密钥 纪元只是一个“组版本”。每个纪元都有一个由整个组共享的随机 32 字节对称密钥。消息