自建 Matrix 服务器五年心路历程

共有 146 条讨论

1. 自2017年起配置未变。此后内存占用降低了60%。管理面板虽非必需，但若有则更佳。最初选择Postgres数据库，因为若要使用数十年，我别无他选。当前分配2.5GB内存供10名用户使用，即使增加到10或20用户也无妨，这完全在预期范围内。从未进行过任何清理操作，最近直接导出数据库迁移至OVH的新VPS服务器，搭载NVMe SSD后运行如飞。

   最让我抓狂的是无法删除用户已删除的附件——50GB数据不知能否清理，但考虑到容量，我只能硬着头皮接受。毕竟25年后几TB空间应该不成问题。不过这个功能我真心希望尽早解决，想必连matrix.org服务器团队都为此头疼。

   迁移到更优质的服务器后，除非手机长时间休眠(我猜这是安卓系统的优化问题)，否则通知速度不再迟缓。目前它的稳定性已超越Teams。有位朋友遇到过问题，但移除15台旧设备后就解决了。

   关于Element-X，我曾特别指出“又一次重写”对安卓端的影响，确实导致情况恶化。至今仍不清楚如何修复新旧客户端间的通话和视频功能。目前我放弃推广新客户端，所有人仍在使用旧版，但随着经典客户端进入维护模式，这个问题开始凸显。

   回复

   1. 我曾自建Matrix服务器多年，后来发现任何Matrix主服务器都能在未经认证的情况下随意提供媒体内容。次日我就关停了服务器——我可不想当下载儿童色情内容的代理。

      类似https://my.domain.com/_matrix/media/`<some.other.domain>/`的URL会毫不犹豫地通过我的服务器代理传输不良媒体。

      我 认为 他们已修复此漏洞，但风险仍不值得承担。

      回复

      1. 是的，他们约一年前修复了该漏洞。这是个破坏性变更，要求所有用户更新服务器软件配置。

         回复

   2. Matrix生态的现状还不够稳定，多数人不会考虑迁移。自从他们改用livekit系统搞砸呼叫功能后我就放弃了——呼叫无法使用，我现有的TURN服务器彻底废弃，Matrix沦为极其缓慢的聊天工具。

      我已经受够了。

      回复

      1. 我暂时不会放弃。平台迁移难度太大，且目前鲜有平台能同时提供稳定的桌面端和移动端版本并支持端到端加密。

         但若他们胆敢再次从头重写任何功能，我必将离开。现阶段他们必须坚守现有架构并完善优化。

         回复

         1. 一年多来，没有朋友从Discord迁移到我的服务器，损失不大。我会加入维护更积极的实例，继续参与自己建立的社群和聊天群组。

            回复

            1. 90%的朋友都迁移了，这确实是个棘手的问题。

               回复

         2. https://m.youtube.com/watch?v=z0ULOptq2vk&pp=0gcJCR4Bo7VqN5t…

            他们似乎计划接下来重写桌面客户端。

            回复

      2. 当我用他们的转换脚本将服务器后端从SQLite升级到PostgreSQL时，数据库出现了错误，我最终放弃了。

         或许哪天我会深入研究，尝试通过提取引发错误的数据来修复数据库，但现在这样做真的值得吗？

         2025年运行Matrix服务器能给我带来什么？

         回复

         1. > 2025年运行Matrix服务器能给我带来什么？

            是否存在其他开源、自托管、去中心化的平台，能提供端到端加密聊天及端到端加密群组语音通话——即类似Signal的功能，但无需依赖中心化服务？

            从我的角度(作为Matrix项目负责人难免有偏见)来看，其缺点在于：

            * 服务器仍会暴露过多元数据。不过修复工作正在推进——例如https://youtu.be/Q6NSmptZIS4?t=933用于加密状态事件。

            * Synapse 数据库消耗量依然过高。我在此提出解决方案：https://youtu.be/D5zAgVYBuGk?t=1852，但需完善实现。

            * Element从旧版应用向Element X的过渡并不顺利，导致本讨论串中出现大量抱怨(例如1:1 VoIP与群组端到端VoIP缺乏互操作性，以及新应用的初期问题)。

            * 后量子加密尚未落地；为此筹集资金的过程相当艰难。

            回复

            1. 我认为最大的问题并非上述任何一项，而是如此规模的问题(包括去年修复的许多问题)仍在不断被发现，且需要进行诸如“从旧版应用迁移”、破坏性服务器变更等操作。换言之，系统并不稳定。

               回复

         2. 多年未用matrix.org主服务器，但当年延迟问题严重——根本算不上即时通讯，更像邮件系统。当体验最糟糕时，我决定自建服务器。这显著改善了体验——它终于像即时通讯平台了。如今迁移到OVH后，我甚至能超快滚动浏览数百个附件，所有操作都流畅自如。

            另外我知道主服务器没有在线状态显示功能。除此之外就没啥特别了

            回复

   3. Conduit [1] 支持媒体文件和附件的保留策略[2]！

      [1] https://conduit.rs/ 及 https://gitlab.com/famedly/conduit [2] https://gitlab.com/famedly/conduit/-/blob/next/docs/configur…

      回复

      1. 坦白说这不符合我的使用场景。如果我理解正确，它就像其他保留策略一样，与附件是否被用户删除无关，只是在某个时间点后自动清除所有内容。

         我不介意存储人们能访问多年的文件——如果我想看十年前的搞笑图片，应该能找到(尽管Element的GUI现在在这方面很糟糕)。但我真正介意的是那些用户误传或因故想删除却滞留在我服务器上的内容。

         回复

2. >这还导致跨联合网络的任何发言都无法撤回，对于常被讨论隐私问题的协议/系统而言，这反倒成了讽刺。

   这有何讽刺？世上没有任何协议能强制用户从自有设备删除内容。实现此功能的聊天应用要么是专有软件(用户无法控制其行为)，要么是开源软件——但仅基于口头承诺实现。

   回复

   1. >世上没有任何协议能强制用户从自有设备删除内容。

      但它们要么不签名消息，要么允许撤销签名。Matrix则永久签名所有事件。

      Matrix还会在用户加入时向服务器提供完整的事件历史记录(根据聊天室配置可能不包含消息内容)，即使该服务器的用户无权查看这些内容。

      回复

      1. > Matrix还会在用户加入时向服务器提供完整的事件历史记录(根据聊天室配置可能不包含消息内容)

         关键点在于括号内容：如你所言，若聊天室配置为不共享历史记录，历史消息内容 不会 被共享。

         回复

      2. 这些区别实则毫无意义。在可观察性或否认性方面，跨多个独立Matrix服务器复制的事件与跨独立客户端广播的事件并无实质差异。

         回复

         1. 但通常当你加入对话却无法查看历史消息时，你根本看不到任何相关记录。Matrix服务器却能看到。

            回复

   2. 协议可以强制要求删除。但特定客户端实现可能忽略该要求，或部分用户可能规避该要求，因此这属于较弱的功能，但终究是功能。根据具体情况，它仍可能非常有用。

      回复

      1. 开放协议确实能强制要求，但这终究属于“小指承诺”级别的安全保障。我认为更优的隐私友好型聊天协议设计，应避免在非必要时向大量远程服务器写入数据。不过Matrix的核心卖点在于抗审查特性——这种情况下尽可能复制数据反而更合理。

         回复

         1. >小指承诺级别的安全

            你说得对，但我更倾向用“弱功能”这个术语 🙂 这种设计自有其价值。密码学界总聚焦于全能的伊娃破解密码，以及xkcd漫画里的扳手梗，但我敢断言：商业泄密与私人泄露的多数根源，恰恰在于善意用户缺乏全面追踪的能力，以及俗话说的“三思而后行”。诸如“撤回消息”或定时删除这类功能，纯粹从技术层面看确实可笑，却能奇迹般地挽救用户免于重大失误。

            回复

            1. 向非技术用户解释这类机制很困难。诸如“我们尝试删除消息，但部分接收者可能仍持有副本”的表述既不够理想，又难以让非技术用户理解，更难以设计出令其满意的实现方案。

               因此，若我是矩阵/元素开发人员，当这项功能交到我手上时，我必须权衡它与那些已知可实现的功能——这些功能能让技术人员和非技术人员都对应用程序感到满意并提升体验。

               回复

               1. 这恰恰是WhatsApp的现状。虽然该提示可能已不存在，但过去确实存在几乎完全相同的表述。

                  回复

      2. 协议只能支持，绝不能强制。若我发送“DELETE MSG #4829”指令而你无动于衷，却回复“200 OK; DELETE MSG #4829”，任何观察协议消息的人都无从知晓真实情况。当然，全知者或许会说“但他内部违反了协议，根本没删除消息！”，但按定义，凡是协议内部无法验证的行为，都属于协议之外。

         回复

         1. 确实如此。

            实际应用中，在联合网络里恶意节点最终会被列入黑名单。这虽不提供任何“正式”保证，但…通常效果尚可。至于这个特定的“删除请求”功能，当然应始终视为便利性设计， 绝非安全机制 。

            如同许多工程设计，这始终是权衡取舍的过程。对于即时通讯，采用开放协议的联合架构提供了我最看重的特性：去中心化、可改造性、自主权和开源性。该领域我的选择是Matrix或XMPP。虽然未尝试自建Matrix服务器，但近十年使用的[prosody](https://prosody.im/)实例始终令我满意。

            回复

            1. XMPP的问题在于：当Gmail聊天功能被取消时其网络效应崩塌，且移动客户端长期匮乏优质选择。

               Matrix看似能替代Slack或Discord，但其设计决策如此妥协，唯一解释是他们确实建立了某种(相对薄弱的)网络效应？开源项目依赖Slack或Discord运行(免费/低价套餐即将或已遭撤销)实在有失体面。剩下的IRC网络效应衰减速度则缓慢得多。

               我从未深入尝试托管Matrix服务器，但阅读相关文章后发现——Matrix显然不符合GDPR合规要求。欧盟最终推出的ChatControl法案，加上全球数百项其他法规及美国各州法律，让我认为面向公众的非营利组织或小型初创公司运营此类项目的时代已经终结。(或许开源的未来是：用资金养律师，开发工作则由AI以极低成本完成？)

               回复

               1. GDPR本就因欧盟向特朗普妥协而名存实亡。

                  不兼容ChatControl？这根本不是缺陷而是特性。反正没人想要那玩意儿。不过又是美国游说集团(Thorn)的蠢主意罢了。

                  大型组织确实无法为所有人运行Matrix，但这恰恰是它的精妙之处——人们可以为小群体自主搭建节点。

                  回复

         2. 坦白说我不了解这种定义。据我所知，许多被称为“协议”的东西都严格规定了行动规范，而这些规范恰恰如你所言无法验证。不过我来这儿不是讨论术语的。就算叫它绿奶酪，它依然是个实用功能。

            回复

            1. 没人否认这是个实用功能。我唯一想说的是：开放协议无法强制执行该功能。若你指望以隐私之名实现100%遵守，注定要失望。

               回复

               1. 功能本身可以强制要求，只是强制令无法真正执行。

                  回复

               2. 很好，同样没人声称期待100%遵守！

                  回复

      3. 确实如此，而Matrix采用的是该功能的弱化版本：https://spec.matrix.org/v1.16/client-server-api/#redactions 在正常情况下，该功能理应能在所有服务器和绝大多数客户端上正常运行。

         回复

      4. 人们应该理解任何类似邮件的联邦化系统。一旦发送内容，它就存在于他人设备中。无论是Matrix还是任何端到端加密协议，都依赖于客户端修改数据的承诺。Snapchat事件的惨痛教训难道不该让我们铭记于心？难道我们都忘了？

         回复

         1. “存在活跃敌对行为者”的安全模型，与“偶尔发送不慎信息需删除，且接收者均为朋友熟人而非蓄意收集黑料者”的情境存在本质差异。

            当我在Signal聊天中删除消息时，默认预期是所有聊天成员通过社会契约共同遵守这一规则。

            回复

            1. 不过中间还有许多中间地带的情况，特别是当你将消息传递用于“严肃”目的(如商务沟通)时——虽然不至于严肃到将其他用户视为敌人的程度。例如有时你希望允许人们编辑/删除近期消息，但不允许修改真正陈旧的记录(以防有人试图“改写历史”)。

               回复

   3. 没错，但我们确实尝试过接管硬件安全区，将用户数据(而非受版权保护的公司数据)传输至用户设备。

      蒂姆·伯纳斯-李致力于打造一个可自主选择“遗忘”内容的互联网。至少这是我在2010年代至2020年代初听闻的理念。实现方式在于：将DRM类技术交由用户掌控。

      因此实现隐私设计本是美事，但现实是：许多即时通讯软件刻意制造不便——当消息标记为“仅限一次查看”或“限时可见”时，用户虽无法直接复制，却能通过外部摄像头拍摄低保真副本，甚至实现数据外泄。

      即便是自由/开源软件，也可能被迫使用这些专有安全区，或至少采用用户无法访问的密钥存储机制。(据我理解，这涉及硬件级DRM技术。)

      回复

      1. >蒂姆·伯纳斯-李试图让互联网成为可自主选择“遗忘”内容的空间。至少这是我从2010年代至2020年代初获取的消息。

         蒂姆·伯纳斯-李创造的是万维网，而非聊天应用所使用的互联网。此外，除非你能提供关于其设计初衷是“遗忘”内容的直接引述，否则我完全不明白你所说的“消息”从何而来。

         >实现方式：用户掌握的DRM类技术应能实现此功能。

         若技术掌握在用户手中(即开源状态)，它随时可能被禁用——这正是我先前回复中已阐明的核心问题。

         回复

         1. 我认为他们指的是蒂姆·伯纳斯-李的新项目Solid：https://en.wikipedia.org/wiki/Solid_(web_decentralization_pr…

            回复

         2. >> 至于实现方式：用户掌握的DRM类技术理应能实现。

            > 若由用户掌控(即开源)，该功能随时可能被禁用——这正是我回复中已阐明的核心问题。

            关键在于借助客户端硬件级DRM支持，Matrix服务器可仅向未修改客户端发送数据。若你的客户端修改方式与服务器预期不符？数据将无法送达。

            回复

            1. 你只是用更多词汇重复相同观点。若无法控制硬件级DRM，则Matrix运行仍需依赖专有二进制代码。

               回复

   4. 我也觉得这种观点很奇怪。人们常把隐私理解为“我能为所欲为”。在我看来，删除已发送给他人的内容根本不涉及隐私问题。

      回复

      1. 据我所知，存在某种巧妙的加密方案：收信人能自行验证消息确系发件人所发，却无法向第三方证明发件人身份。这赋予你合理的否认空间——你总能声称是联系人伪造了消息。

         记不清具体算法名称了。

         回复

         1. 没有特定名称，仅指否认机制。我个人喜欢称这种方案为“通过伪造声明实现否认”。其实并不高明——你只需在会话结束后，向通信对象提供伪造你消息所需的一切材料。

            实际操作中是否可行尚不确定：

            https://articles.59.ca/doku.php?id=pgpfan:repudiability

            回复

         2. 该方案不就是双方约定共享密钥并共同使用吗？只要消息用该密钥签名且非我所发，我就能确认是你的消息，反之亦然——但双方都无法证明消息的实际创建者。

            回复

         3. Off The Record聊天软件就采用这种机制。

            https://en.wikipedia.org/wiki/Off-the-record_messaging

            回复

      2. 我个人并不认同，但确实有人试图将“被遗忘权”包装成隐私议题。

         回复

         1. 举个例子，试图清除网络上的复仇色情内容，本质上就是恢复个人隐私的尝试。他人本就不该有权继续窥探他人的私生活。

            回复

            1. 这并非我所指的情况。我认为这类问题在多数地区现行法律中已有规制？

               “被遗忘权”倡导者主张，每个人都应有权要求删除自身过往网络活动的任何痕迹。这不仅包括社交媒体，还涵盖独立论坛、聊天记录、Git提交记录等。

               回复

         2. 即便涉及隐私问题，也无法通过开源软件在技术层面强制执行，因为根据定义，远端用户完全可以运行禁用远程删除功能的分叉版本。

            回复

   5. > 这有何讽刺之处？世上没有任何协议能强迫用户从自身设备删除任何内容。

      你或许注意到，当前存在一股持续推动的浪潮，试图剥夺用户对其“自有”设备的访问权限。

      强制用户删除自有设备内容，正是Snapchat协议的核心理念。所幸Snapchat并未提供操作系统，无法实质参与这场浪潮，但它恰好提供了绝佳的例证。

      你可在此查阅Snapchat漏洞悬赏政策：https://hackerone.com/snapchat。在不可报酬漏洞列表中赫然列着“规避截图检测”——这并非漏洞(因其无法解决)，尽管这恰是其产品的核心卖点。

      有时实力更强的公司也会追求类似目标，并试图采取行动。

      回复

3. 我在最低配的VPS上运行家庭服务器五年，运行良好。优势在于：跨平台兼容、自主托管、功能完备。生态系统中的客户端软件大多臃肿，唯NeoChat例外。到2022年，这些客户端已无法相互通信。今年已将其退役，转而采用传统XMPP协议——运行稳定，通知处理终于得当令人欣慰。

   我们团队高度认可Matrix的开发成果，但遗憾的是项目初期始终回避了核心问题：亟需一个简洁的官方管理控制台或工具来统一管理用户、存储和配置。缺少这个核心组件，管理员与审计层之间就会形成复杂的中间层，从而增加配置错误或资源管理问题的风险。

   回复

   1. 我们最终在数月前通过https://github.com/element-hq/element-admin解决了这个核心问题。

      关于VoIP互操作性——确实，Matrix最糟糕的设计之一就是传统1:1 VoIP通话无法与基于MatrixRTC的多方通话互通。但我们因时间/资金限制未能实现互操作，转而专注完善MatrixRTC功能。(请问XMPP是否支持端到端加密的多方通话？)

      回复

      1. 感谢Aaron的直接回复。很高兴看到这个用于管理的中央界面。最近确实没用过通话功能。Rust客户端在Fdroid平台的障碍之一是设备操作系统版本过新，但在iOS上性能反而有所提升。

         Element的精妙设计在于构建了围绕聊天室的客户端服务生态，而XMPP在某些场景下未能达到这种预期。我计划在制定新的技术应用方案后尽快重新部署。

         新管理界面初见成效令人欣喜。期待未来能整合安全配置检测指引，为不同技术水平的管理员提供完善服务器配置的工具，涵盖TURN协议选择及存储方案等相关功能。

         Matrix与XMPP同样具有深远影响——我认为它不会很快消失。感谢它为我们的组织提供的所有支持。

         回复

      2. 再提个创收思路(你总不会自己没想法吧)：推出Element的白标版本(另命名)，支持按组织范围部署并遵循LTS版本周期。我们乐意为此付费。

         回复

         1. 这正是Element的现有商业模式：https://element.io/en/pro-app和https://element.io/server-suite/pro。

            回复

            1. 网站设计精良，视觉效果出色——坦白说在批评之前我从未关注过白标应用。这个方案确实出色，我认为可以在社区版与企业版之间为中小型组织推出白标层级，并在官网明确标注定价。

               回复

         2. 虽然无法确认当前是否仍支持，但Element托管服务器过去确实允许这样操作，至少针对Web应用是如此(我记得旧版移动应用也支持？)

            以下是相关链接：

            https://element.io/blog/custom-branding/

            https://element.io/blog/a-white-label-messaging-app-to-creat…

            回复

            1. 他们在这款产品上表现出色，直到看到Aaron的回复，我才注意到它。

               回复

   2. 感谢提及XMPP。我从未运营过服务器，但作为用户一直享受其便利。当然也存在问题——比如我当初随意选了个服务器创建首个账号，前几天该服务器竟离线了整整6小时。这种情况下普通用户(即非新手如我)通常会如何应对？

      话虽如此，我非常想听听你运营XMPP服务器的经验。你还在运行吗？

      回复

      1. 将聊天活动和在线状态托付给任何允许免费公开注册的互联网XMPP服务器，并非理想之选。若追求可靠性，请付费使用或选择你认为极具可信度的免费服务器。我未运营任何面向公众的XMPP服务，对此无法提供建议。与Matrix类似，除非你完全掌握相关知识，否则不建议自行搭建——因这些平台在特定配置或暴露状态下存在固有风险。

         回复

   3. 必须承认早期Element X的iOS版本(Rust开发)体验流畅迅捷，可惜我没用多久就放弃了。

      回复

4. 作为老用户，我深切体会到这些痛点——明明只想和好友保持活跃的一对一聊天。每小时数十条消息，持续使用近两年。期间使用matrix.org及X版本前的客户端。群聊(IRC模式)尚可，但这要求本就不高。

   (a) 移动端与网页端之间的加密同步频繁失效/中断，体验极差。频繁弹出“无法解密”提示，只能反复切换设备强行重新同步，有时彻底失效。这些年GitHub上相关问题报告堆积如山。

   (b) 如本文所述，新消息通知及收发存在严重延迟。每天早上登录网页端都要耗费数分钟进行某种神秘同步流程，移动端也常出现相同问题。X版本或许能解决这些问题，我们此前使用的是旧版。

   (c) 清理功能。matrix.org未设置消息保留机制，当我试图提取并删除过往聊天记录时，整个过程体验极其糟糕。仅通过网页端(移动端实际完全无法操作)反复查询加载旧内容，就耗费数个周末共数十小时，最终只能每次批量删除100条消息，单次操作耗时一小时。当清理范围扩展至一年以上时，加载时间持续延长，直至彻底无法加载旧消息。

   对于亲友间的一对一聊天，Signal和DeltaChat的体验远胜一筹。Delta客户端的UI/UX稍显落后但尚可接受——例如无法像Signal那样修改已发送消息中的拼写错误，因为Delta将每条消息视为独立的GPG加密“邮件”而非可重新编辑的数据库对象。

   回复

   1. 感谢提及Delta——https://delta.chat/ 及隐含的https://chatmail.at/

      回复

   2. > Delta无法修改已发送消息的拼写错误

      至少在iOS应用上可以修改，我刚测试过。我运行的是自建postfix/dovecot服务器，不应需要任何特殊配置。

      回复

      1. 值得了解，谢谢——我们当前用户都在安卓设备上，尚未有iOS好友加入。我们使用的是聊天邮件中继。

         回复

   3. a) 这已不是什么大问题了

      b) 是的，X 通过滑动同步解决了这个问题

      回复

      1. a) 具体是何时？我一年前在 matrix.org 遇到过“无法解密”的聊天室故障。

         b) 遗憾的是，X 破坏了其他重要功能，比如音视频通话。当前版本感觉像 alpha 测试版：漏洞百出且功能缺失严重。尚未准备好广泛使用。

         回复

         1. 打开 Element X 后发现它不支持线程功能，我感到很抱歉才创建了这个长帖。

            后来有人告诉我，线程功能隐藏在Labs设置中，但该设置仅允许客户端回复线程，却仍将整个线程内联显示在频道中，占用了聊天界面所有空间，实在糟糕。

            回复

            1. 这不对——Labs中的线程支持功能允许你创建线程并按预期进行导航。

               你描述的是旧版线程的权宜方案，该方案早于实验室中的正式解决方案，后者应尽快退出实验室阶段。

               回复

               1. 我描述的是当前iOS版Element X的实际情况。当有人回复线程时，该客户端无法隐藏或导航至独立线程。即使开启实验室功能后，应用仍将线程内容混杂显示在其他对话中。

                  卸载应用后重新安装，并在进入带主题的聊天室前确保实验室功能开启，此时行为符合预期。

                  因此问题可能在于：切换该设置后聊天室未重新渲染。

                  回复

   4. 很抱歉你经历了糟糕的体验，我也承认过去确实存在诸多不足。但为Matrix团队辩护：我们已在2024年9月左右修复了几乎所有已知的加密问题，新一代客户端也解决了同步缓慢的缺陷。

      关于消息保留问题：https://element-hq.github.io/synapse/latest/message_retentio… 才是你本应/可用于清理那些聊天室的方法。(该功能尚未在Element界面中开放，因我们优先处理了更基础的开发事项)。

      回复

      1. 你好Arathorn，我认出你是核心开发负责人。:) 遗憾的是，当我尝试清理旧消息时，试过这个方法(以及其他流传的API技巧)，当时均未奏效。

         简而言之：Matrix(Element)客户端完全缺乏面向用户的数据保留与清理便捷控制功能，这对我而言是致命缺陷。那次痛苦经历让我深刻领悟——如今测试新功能时，我首要关注的就是“如何从该系统中提取数据”。绝不愿再经历Matrix数据提取的折磨，这已成为我的人生教训。

         回复

5. > 我唯一不解的是数据复制机制的设计。当A服务器用户加入B服务器的房间时，近期房间数据会被从B服务器复制到A服务器，并保持双向同步。

   其设计理念是将房间从服务器中抽象出来，使其以某种形式短暂存在。这种设计既有利又有弊——底层基础设施难以管控托管的社区，似乎已成为联邦制的标志性特征。

   我尝试用Matrix替代Discord的经历表明，这种设计弊大于利，导致高层社区与底层基础设施提供商之间严重脱节。相比之下，Discourse的生态更健康(尽管我期待Discourse推出应用程序，使其社区行为更接近Discord/Slack服务器)。令人沮丧的是，至今尚未出现明确的“聊天版Discourse”来取代Discord。

   回复

   1. > 这导致社区上层与底层基础设施提供商之间存在严重错位

      确实，这个表述很到位。我们在管理员体验中经常看到这种情况。大量管理工具要求“在服务器上运行这个机器人”或“按此配置Synapse”，但对于无法运行任何服务器的人来说，这些操作根本无法实现。当然可以委托他人运行模组机器人，但问题依然存在——这在需要执行模组操作的用户与控制执行机制的管理者之间，始终存在一道阻隔层。

      除非在协议/客户端层面构建出功能完备的模组工具包，否则对于希望用Matrix搭建社区的人而言，这始终是个棘手局面。最隐蔽的风险在于：一切看似正常时，你的聊天室可能突然被血腥图片甚至更恶劣的内容淹没。

      (顺便说一句，我们依然怀念你在Matrix Python聊天室的身影！:-)

      回复

   2. 你也可以尝试Movim。它能搭建去中心化XMPP服务器，客户端支持群组通话，同时具备论坛式发帖功能供用户评论。

      回复

      1. 现有方案很多(虽然我没用过Movim——谢谢推荐我会试试)，但多数社区似乎都聚集在Discord或Matrix上(少数仍在使用IRC，还有些在Slack)——其中Discord的用户体验绝对是最佳。

         回复

   3. > 这里的核心理念是将房间从服务器中抽象出来，使其具有某种程度的临时性

      不，这完全错误。实际情况恰恰相反。创建房间时使用的服务器域名会永久嵌入房间名称中，且永远无法更改。

      回复

      1. 不过这并无实际影响。它只是名称的一部分，即使该服务器永久消失，房间仍可继续使用。

         回复

      2. 我认为他们的意思是房间不依赖于该服务器的持续可用性。

         回复

6. 我作为用户使用Matrix已有数年，运行良好。解密消息的问题已不复存在。X正成为优秀的客户端。经历痛苦的备份周后，几周内我将注销WhatsApp和Telegram账号…

   编辑：好奇Matrix账号数据备份的便捷性。包括对话记录和文件。

   回复

   1. > 好奇Matrix账号数据备份的便捷性。包括对话记录和文件。

      事情没你想象的那么简单。Element客户端虽有导出功能，但需手动在每个聊天室激活，且导出文件存在大小限制——若需保存大量文件可能无法实现。若聊天室历史数据庞大，导出速度也会相当缓慢。你也可以尝试使用Matrix Commander(命令行客户端)，但我同样未能使其完全正常工作。

      回复

7. 我在租用的机房里用Proxmox主机运行Matrix服务器已有两年(还托管了些其他爱好项目，但主要是觉得这玩意儿很酷)。这个部署指南非常棒，安装和维护都很简单：https://github.com/spantaleev/matrix-docker-ansible-deploy

   回复

8. 关于“需要联合”的说明并不准确。我运营家庭专属小型家庭服务器已有数年，从启用之初就禁用了联合功能，至今从未出现过任何与联合功能(或其缺失)相关的故障。

   回复

   1. 我也是如此，不过除非使用VPN，否则仍需将其暴露在互联网环境中。我更倾向于攻击面更小的方案，尤其考虑到当前桥接功能未加密，不过我现在已通过VPN托管服务器。

      回复

      1. 这种批评并不公平。服务器必须暴露在客户端连接的网络中——无论是互联网还是局域网，这与协议本身无关。

         我曾部署过完全运行在企业内部局域网的Matrix服务器，完全不接入互联网，因此它本质上无需暴露在互联网中。

         回复

         1. 没错，但即便作为Web服务，其攻击面依然相当大。存在大量模糊URL，代码也并非十分简洁。

            回复

9. > 虽然技术上Synapse可配合sqlite数据库运行(对于服务器端<10用户的场景初看似乎可行)，但数据库终将损坏。

   有人掌握更多相关信息吗？运行Postgres并非难事，但根据我的使用经验，本以为SQLite应该没问题。

   回复

   1. 我虽未见过太多损坏的sqlite数据库，但由于Synapse当前存储效率低下，最终可能形成恐怖的巨型数据库(100GB+)，其后果无异于损坏。

      我们仅为便于调试才支持sqlite，从未打算将其用于生产环境，现在看来支持它本身就是个错误。

      关于Synapse存储效率及其优化方案，相关讨论可参阅https://www.youtube.com/watch?v=D5zAgVYBuGk&t=1851s

      回复

   2. 我用sqlite搭建双用户服务器，运行数年从未出过问题。

      sqlite数据库文件确实可能损坏，但通常不会发生，除非你对它做了些奇怪的操作。https://www.sqlite.org/howtocorrupt.html

      回复

   3. 我运行基于SQLite的非联合Matrix实例已有十年，服务10-20名用户(部分用户非常活跃)。启用WAL模式时SQLite运行良好，我不确定为何会损坏。

      几年前我们曾进行数据/历史记录清除(我成功迁移了账户)，因为当时切换到conduit.rs配合SQLite使用。我个人更倾向conduit而非Synapse。

      我从未遇到过sqlite的问题，主要都是synapse的故障。最近的改动让我觉得他们完全忽视了小型实例的需求，整个生态系统似乎正在分裂。Element X实在不够理想，它似乎存在的目的就是取代经典Element，而且使用Element X需要某些服务器功能，而并非所有替代synapse的服务器都支持这些功能。

      回复

10. > 虽然技术上Synapse可配合SQLite数据库运行(初看似乎适合<10用户的服务器)，但数据库终将损坏

    希望深入了解此问题。是因Synapse的SQLite支持不完善？具体会出现何种损坏？

    回复

    1. 我使用SQLite作为Synapse数据库(约两年)，从未发现任何损坏现象。我活跃于20-30个频道，其中多数频道拥有1000-2000名用户，当前数据库大小为8.8G

       回复

11. 我曾断断续续尝试使用Matrix。早期我曾是它的高调支持者。遗憾的是，它似乎仍未解决我当初遇到的根本性问题。或许该尝试其他方案了

    回复

12. 作为研究过基于Matrix分叉开发新型聊天服务的人，很高兴看到有人深入探讨其后台运行机制。感谢分享。

    回复

13. 题外话：我在Telegram里有几个超大型群组(使用7年以上，含大量图片)。Matrix(Rocketchat或其他替代方案)能否提供类似的存储功能(并附迁移脚本)？谢谢

    回复

14. 补充一个数据点：我最近几个月一直在自建一个(微型)Matrix服务器。我对使用Docker进行自建服务器相当熟悉，因此选择不使用Ansible脚本，希望这样能让我的配置更简单、更易于维护。奇怪的是直到Synapse运行起来后才发现ESS的存在，但基于类似考量，Kubernetes本会成为项目终结者。

    这段时间里，我执行了数据库迁移(默认使用sqlite，但MAS需要postgres)，尝试迁移到MAS(需要使用Element X)但失败，还浪费了几天时间折腾coturn和eturnal却毫无进展——涉及NAT时通话依然无法接通。我不得不告诉新用户，在我搞定MAS之前，请忽略安装Element X的建议。

    这里存在大量基础改进空间，即便更新文档引导潜在服务器管理员采用当前推荐配置方案也会有所帮助。

    回复

15. 过去几年我一直在小型VPS上运行Synapse，部分桥接功能也已实现。虽然过程中遇到不少波折，但它仍是我的日常主力设备，另有约五人也在使用。

    最近我在新VPS上部署了ESS社区版，部署过程轻松许多，令人惊喜。不过由于它采用Kubernetes等我不熟悉的技术，要实现我习惯的桥接功能需要更多学习。ESS作为新生项目，目前新手友好的教程还不多。

    我依然保持乐观。

    回复

16. 简而言之：自建服务器并非因人们失去兴趣而消亡，而是因其复杂性已失控。

    这篇文章揭示了曾经轻松有趣的业余爱好如何演变成全职维护负担。Matrix这类系统功能强大，但其复杂程度已让资深工程师都难以稳定运行。结果是人们逐渐回归中心化平台——并非出于偏好，而是便利性持续压倒自主性。这提醒我们：用户自主的互联网理想与现代软件现实之间的鸿沟正在扩大。

    回复

    1. 确实如此，这令人遗憾。我认为这是Matrix计划在实践中未能完全实现的领域之一。问题不仅在于管理复杂性，部分根源更深植于设计本身。几年前初次使用时，我以为他们的愿景是让大量用户运行小型服务器。但协议的全复制特性加上服务器软件的资源需求，使这种模式难以实现。即便技术爱好者，若得知数据库可能膨胀至数十GB，且Synapse对内存和CPU的消耗也不小，恐怕也会望而却步。

       或许未来随着实现方案的改进，部分问题会得到缓解，小型运营商运行自有服务器将更具可行性。但届时建立信任将更困难——太多人早已将其视为臃肿或不稳定的系统。我认为当初若能以精简模式起步，在系统演进至后期阶段前保持其极客小众属性，会是更明智的选择。

       回复

    2. 近年来部署确实变得简单许多。docker-compose已成为事实上的服务器“应用安装”标准，任何Linux系统都支持它。这包括Truenas/Unraid这类图形化管理界面，以及Dockge这类优秀的运维工具。

       Matrix背后的公司虽瞄准超大规模服务器，但若你关注非联合的私有实例，会发现存在更简洁的“单二进制”项目，甚至可使用基于文件的sqlite/rocksdb数据库。部署这类项目简单至极——实际上你甚至无需docker，仅需systemd服务，更新时切换二进制文件即可。

       回复

       1. 若需简易的 Matrix Docker Compose 方案，可直接使用 https://github.com/element-hq/element-docker-demo。

          Element将ESS社区版打包为Kubernetes Helm图表的原因，纯粹是为了使官方支持的发行版尽可能贴近我们为大型政府技术客户提供的支持环境——而Docker Compose显然无法满足这种需求。讽刺的是，这意味着ESS社区版虽然相当稳健(即便缺少扩展功能)，却需要运行K8s作为代价。

          回复

    3. NixOS同样能轻松实现。现有synapse、livekit等模块(MAS模块仍在Pull Request阶段)，配置过程相当可行：https://wiki.nixos.org/wiki/Matrix

       不过仍需具备操作知识(手册可提供帮助)并完成组件衔接(理论上可通过nixpkgs模块实现自动化，但显然无人着手)。配置完成后即可轻松使用。

       我愉快地运行着自己的家庭服务器已有五年多，过程相当简单。

       回复

       1. 是啊，但你得用NixOS系统——对普通用户而言，它不仅本身就是Linux系统(这本身就够难的了)，还叠加了Nix架构，这又需要额外的学习成本。

          而且根据你的描述，你是个技术控。我严重怀疑普通市政厅职员会自己搭建Matrix服务器。

          回复

17. 我还以为XMPP已经够糟糕了…

    回复

    1. 相比Matrix，XMPP体验确实出色。几年前我曾短暂托管过Matrix服务器，当时系统状态糟糕，如今似乎仍是一团乱麻。我尽量避开它，但某些社区却坚持使用。

       它该彻底消亡了，这样人们才有动力用更优方案替代它。

       回复

       1. > 我尽量避免使用它，但不知为何仍有社区在用。

          所谓“不知为何”，至少对我所在的团队而言，是因为它对我们而言坚如磐石。我们毫无更换的理由，自然继续使用。

          回复

       2. 人们正积极用更优方案取代它，那方案名为Matrix 2.0。

          回复

          1. 这完美契合Matrix的理念——一切都在不断重写或被新版本取代，而新版本往往只实现一半功能，原版甚至还没完成。

             回复

             1. https://www.jwz.org/doc/cadt.html

                请复制粘贴链接，否则彩蛋内容可能冒犯某些人 😀

                回复

             2. 比起死守那些明知无法令人满意的东西，我更欣赏这种做法。

                回复

          2. 他们打算在2.0版本修复Matrix的根本问题吗？还是该等3.0？

             回复

             1. 你能说得更明确些吗

                回复

                1. 当然可以，正因如此链接里才多写了几句关于Matrix的问题。

                   回复

                   1. 太好了，现在更明确了——我可不会回答你。

                      回复

          3. 一年前刚推出时我试过，当时没用。现在稳定了吗？

             回复

             1. Matrix 2.0？

                还差一点，但官方承诺下个版本就是Matrix 2.0

                回复

                1. 我猜是宣传为Matrix 2.0客户端的Element X没用。

                   回复

                   1. 现在能用了，我已连续数月每日使用

                      回复

    2. 十多年来自建ejabberd仅遇到过一次问题(因未仔细阅读文档，在达到存储限制时被迫从mnesia迁移至sql)。

       确定所需XEP规范曾颇费周章，如今已简化许多。现在我通常定期查阅Prosody示例[1]，其中按“必备”“推荐”‘可选’“其他”分类列出扩展功能，便于快速匹配ejabberd所需模块。

       1: https://prosody.im/doc/example_config

       回复

       1. 我是Prosody开发者，很高兴得知这个示例有帮助 🙂

          最新版本中我最喜爱的微功能之一是新增的'prosodyctl check features'命令，它能从多维度验证配置是否符合当前最佳实践。

          尽管我们精心维护默认配置，但用户升级时往往保留原有配置文件(我们通常建议这样做，以确保向后兼容性)。新命令能帮助升级用户更轻松地确保，随着建议方案的演进，他们仍能获得预期体验。

          显然这难免带有主观性。许多用户欣赏Prosody的一点在于，即使不遵循主流做法，您 仍可 随心定制。例如若您完全不在意多设备同步，完全可以禁用消息缓存功能。不需要音视频通话？没问题！

          回复

    3. 现在你感觉问题翻倍了。这就是新标准带来的体验。这属于XCD #927还是其他问题？

       回复

       1. XMPP已有26年历史，Matrix才11岁。

          回复

18. > Synapse是唯一支持桥接方案的选择

    至少目前并非如此。替代服务器实现方案Continuity及其前身对桥接支持得相当完善。

    回复

    1. 今日我通过Tuwunel搭建了Whatsapp和Telegram桥接。根据mautrix-whatsapp配置文件显示，Dendrite同样应能兼容，看来几乎所有服务器实现都支持桥接功能？

       回复

       1. 前Dendrite用户：是也不是。技术上Mautrix确实能与Dendrite兼容，但仅限部分功能。以Mautrix-Discord为例，我基本实现了私信功能，但仅限私信：服务器桥接始终无法正常工作。老实说我不完全清楚原因，但Dendrite已不值得再关注。这是条死胡同，服务器从未真正稳定运行。直至停运前夕，所有Mautrix桥接功能都未能达到实际可用水平。

          回复

19. 过去一年半左右，我一直在Docker Compose环境中自建Synapse服务器，采用bunkerweb(原名“bunkerized nginx”，更准确地说明其设计理念)作为反向代理，搭配eturnal实现TURN功能，并使用PostgreSQL数据库。近期还新增了livekit和MAS模块，以支持Element呼叫及Element X兼容性。整个系统运行在一台2核/4GB内存的小型VPS上，表现相当稳定。虽然每半个月会遇到一次服务器崩溃，但这可能源于bunkerweb并非最轻量级的解决方案(其实它要求至少8GB内存，而我的配置已低于标准)，同时还因为我同时运行着其他软件(邮件服务器、电子书服务器、plex等)。

    作为管理员的体验总体良好，或许源于我最初的乐观预期——它完美契合了我对自建现代化便捷通信平台的需求。据我回忆，配置过程中的多数问题主要由bunkerweb引发(更准确地说是我未能正确配置代理请求，导致4xx和5xx HTTP状态码被劫持)。Synapse本身维护起来相当愉快，但需说明的是我并未对其进行深度调试——基本完成初始配置后便让其稳定运行约一年，之后才添加MAS和livekit组件。

    没错，磁盘占用相当惊人——仅5-10名活跃用户使用1.5年，Postgres的“schemas”文件夹就达到了10GB。这还不包括synapse存储媒体文件(图片、视频)的media_store目录。我的家庭服务器采用联合模式，过去还加入过几个大型聊天室。不过以下链接提到的机制确实有帮助：

    https://matrix-org.github.io/synapse/v1.40/admin_api/purge_h…

    https://github.com/matrix-org/rust-synapse-compress-state

    客户端体验同样糟糕，但关于这点已无需赘述。不过它足够让我的非技术朋友们继续使用——他们虽然厌恶它，但还不至于因此踢我屁股。很想说这证明了Element客户端可用，但不得不承认我的朋友们实在太好心——就算我改用其他通讯工具，他们也会给我写信 🙂 对我这个技术控来说，Element显然没问题。笨拙但管用。我认为客户端只是需要更多时间打磨。

    真正让我恼火的是Matrix认证服务(MAS)，这个独立服务专为Matrix家庭服务器处理登录验证。没有它就无法使用Element X。但启用后，你无法直接在客户端登录——系统会强制打开网页浏览器显示授权面板，完成授权后才返回客户端。但我的情况就是不行 🙁 我发现基于Chromium的浏览器会卡在授权页面，无法自动跳转回Element应用。我只能通过复制URL在Firefox手动打开来绕过，但有次连这招也不管用。

    不过除了MAS的问题，从管理角度看其他功能都运行良好。我认为它需要更多时间积累，毕竟已有发展势头——我注意到许多新项目都在社交/沟通渠道中加入了Matrix聊天室，这往往是除Bug追踪器外唯一的选项。我愿意耐心等待 🙂

    编辑：为同样受困于磁盘空间使用的人添加了链接

    回复

    1. > 运行相当稳定，我每半个月才会遇到一次服务器崩溃

       我没…什么？你怎么可能…啊啊啊！

       回复

20. 运行Synapse数月后发现，所有TUI客户端不是被弃用就是存在缺陷(最初以为能用Bitlbee，安装后才发现根本无法使用)。

    时隔数年再看当前的TUI客户端，情况似乎毫无改观。当年唯一能用的gomuks如今虽经重写，功能却仍未达原版水平。

    我大概就是xkcd 1782最后那段描述的典型人物。

    回复

    1. 顺便提一句：iamb相当不错且未被弃用：https://github.com/ulyssa/iamb

       回复

21. 我从事开源代码开发已逾25年，部署过Hadoop这类极其复杂的系统，但从未见过比这套系统加桥梁更难运维的方案。

    回复

22. 我托管Synapse已有两年，运行始终顺畅。不记得有过重大破坏性变更，多数更新都很平稳。Element客户端本身确实令人头疼，但正在逐步改善

    回复

23. 这不就是托管服务吗？

    回复

24. 我在此前已提及此事，但值得再次强调。大约两年前，我做出了灾难性的选择——将Dendrite作为家庭服务器软件。当时它看似稳妥：据称比Synapse更轻量，采用Go语言而非Python编写，且所有组件都经过彻底重构。它虽不支持全部功能，但免责声明中没有任何迹象表明它即将突然失去资金支持而陷入实质性停更。可悲的是，就在我做出选择不久后，这一切果然发生了。尽管New Vector对维护毫无兴趣，却仍坚持将这款弃置软件重新授权为限制更强的AGPL许可证。真是明智的决策。后来当需要安全补丁时，他们匆忙发布的版本不仅包含漏洞修复，还引入了导致Dendrite每日多次完全停止处理消息数分钟的致命缺陷(该问题数月后才由志愿者修复)。在Dendrite中加入大型联合聊天室耗时之久，让我以为系统彻底崩溃——操作完成可能需要数小时甚至数天！甚至有段时间Element根本不支持Dendrite，导致所有用户被锁在门外。Dendrite从未支持过Element X，旧版滑动同步代理也从未更新以支持新版简化滑动同步，这意味着你只能使用旧版缓慢的同步方式，且无法支持需要该功能的场景。此外，大多数应用服务器在Dendrite上仍无法正常运行。我勉强让Mautrix-Discord运行起来，但仅限私信功能。

    我完全可以继续列举问题，而且肯定还有遗漏。Dendrite从体验良好到噩梦般的转变速度之快令人震惊。

    我意识到Matrix基金会和New Vector的管理层根本不在乎用户被困在彻底崩溃的服务器上，更不会采取任何补救措施(相信我，我绝非孤例。在所有我曾参与的联合聊天室里，总能看到带有dendrite子域名的宿主名。当服务器连接耗时数小时之际，这些域名在日志中不断闪过。)我曾认真考虑过彻底离开Matrix生态，但考虑到自家服务器上还有其他用户，最终决定竭尽全力解决问题。为此我编写了一款尝试将数据从Dendrite迁移至Synapse的工具。这项复杂操作耗费了巨大精力才得以实现。历经数月失败尝试后，我终于在测试环境中实现了无缝迁移，客户端能持续运行并保持在联合聊天室中。当迁移方案达到“足够接近”的状态时，我便在生产环境中尝试部署——结果自然不尽如人意。所有用户账户虽完整保留，但大量功能出现故障。用户确实能留在联合房间内，但我的房间状态迁移显然未能完全准确。尽管如此，通过在运行时手动清理数据库并采用临时解决方案，最终基本实现了迁移目标。我相信自己可能是首个直接从Dendrite迁移至Synapse的人。

    那么迁移到Synapse后，我对Matrix的看法是否改变了？是的。毫无疑问，使用Synapse的体验显著提升。虽然生态系统依然混乱，但Synapse的各项功能都比Dendrite更完善。许多Dendrite无法实现的功能，比如URL预览，在Synapse上都能流畅运行。

    为何不为Dendrite贡献代码？坦白说，我根本不想参与。他们的贡献者许可协议(CLA)糟糕透顶，不会为我特例修改，况且当前形势下他们根本不会花时间审核PR。若要放弃权利为项目贡献，我宁愿成为正式雇员——这不该是社区成员应付的义务。要么修改CLA确保项目 必须 保持开源，要么别指望获得免费贡献。

    为何不公开我的迁移工具？坦白说，首先它质量并不高。若能完善该工具并正确迁移复杂房间状态，或许能为Matrix生态做些贡献——但说实话我甚至不确定是否愿意帮忙。这本就不该成为我的问题。我完全承认是自己的错误选择导致了当前局面，但真心认为这值得原谅：当时没有任何迹象表明Dendrite即将淘汰。相反，所有迹象都指向它代表未来，只是尚未准备好大规模应用。我感到愤懑。为解决这个问题耗费了大量时间，而投入Matrix生态的这些时间似乎注定无法得到回报。

    我不想这么愤世嫉俗，但事实就是如此。这简直一团糟。我甚至懒得去深究使用Synapse时仍存在的其他问题，比如Element和Element X中VoIP似乎存在多种不同的工作方式，以及Element X似乎只支持一种Element桌面版不支持的新VoIP协议。(惊喜！桌面端根本没有Element X…)

    Matrix还有些其他缺点，虽然尚可忍受但确实令人沮丧。它向家庭服务器泄露大量元数据，这虽不算大问题，但确实令人遗憾；连聊天室名称都未加密，显然完全可以做得更好。客户端生态令人沮丧：目前仅Element具备完整功能，虽然它已大幅改进，但我仍更倾向原生应用而非网页视图。(不过若追求功能对等，网页视图似乎是必需的——因为Element桌面版的群组音视频功能似乎直接调用了Jitsi的iframe…)

    其优势在于采用联邦制架构，至少私聊中的消息和文件支持端到端加密，群聊也可选启用。这点我确实欣赏。

    但个人感觉联邦制设计略有偏差。虽然知道这是奢望，但总觉得一对一及小群私聊本应采用近乎点对点的架构。服务器本该用于聊天室和中继。我遇到的难题是移动通知、离线消息和发现机制。曾想过AT协议的模型能否实现私聊的理想状态。有朝一日我希望能尝试原型开发，但深知即时通讯软件的XKCD 927式困境已相当疯狂，若要投身其中，必须确保值得付出。

    或许某天我会不再愤世嫉俗。毕竟Matrix是开源的，就算它没按我期望运作，我又能真正生气到什么程度呢？但这很难。我曾全力投入其中，结果却给自己和无意卷入麻烦的小团队带来了诸多困扰。当初选择Matrix是因为它看似行业标杆，但今后在将任何生态系统引入自身及他人生活时，我必定会谨慎百倍。比如至今我仍未搭建ActivityPub服务器…或许该先观望发展动向，再决定是否介入。

    回复

    1. 这并非借口，但为说明Element目前为何未投入精力开发dendrite，以下是今日联盟中活跃服务器的样本数据：

           2025-12-01
           synapse : 10068 (85.8%)
           管道服务器 : 476 (4.1%)
           树突服务器 : 369 (3.1%)
           连续性服务器 : 303 (2.6%)
       

       更关键的是，树突服务器既没有用户基础，也没有形成真正的社区生态——这与占据剩余11%份额的独立管道服务器家族截然不同。

       Dendrite项目曾试图实现两项目标：能否加速Synapse？答案是肯定的——如今Synapse运行更流畅，Synapse Pro版本速度更胜一筹。能否实现Matrix点对点传输？然而资金耗尽之际，既无客户自发注资，项目也陷入停滞。如今这个缺乏社区支持、客户需求及存在意义的项目，只能处于闲置状态。

       据悉他们目前获得部分资金用于开发点对点基础架构，但这将耗时良久，且树突项目短期内恐难参与其中(甚至可能永远缺席——Element团队似乎将Rust生态投入客户端开发，而Beeper则押注Go语言)。

       归根结底，Element的困境源于其雄心勃勃的技术决策缺乏实际操作和商业层面的支撑。若所有参与Matrix开发者都拥有无限的时间和资金，结果或许截然不同。可惜现实并非如此，Element正为曾经的行事方式付出代价。不过他们现在似乎有所改善。

       回复

       1. 坦白说，我 并不 怪他们Dendrite项目失败，而是责怪他们抛下我们所有人，未提供任何迁移路径。我个人并不在意自家服务器是用Python、Go还是Rust编写的——至少不太在意。从长远看，Rust很可能比Go更优。当初选择Dendrite纯粹因为它比Conduit更成熟(当时Conduit尚未分叉，应用服务支持薄弱，也不支持联合状态)，又比Synapse更轻量。

          我的家庭服务器是否算在369台活跃Dendrite服务器之列？说到底，它现在已是活跃的Synapse服务器(截至11月下旬)，所以肯定不在统计范围内。不过值得一提的是，我几乎从未连接过Matrix.org。或许只要身处有Matrix.org用户的聊天室，仍会被计入统计？

          但假设它基本上就是369台Dendrite服务器，好吧，它们全都卡在那里了。提供迁移路径难道很难吗？我不知道。我的尝试显然不完整，可能还相当不明智。说实话，我对Dendrite和Synapse的理解还远远不够，根本设计不出能正常工作的迁移工具。我对前向极端的计算是否正确？或许吧。我的状态组划分是否完全准确？大概未必。那些出现多重认证事件的房间究竟是怎么回事？我完全摸不着头脑，最终只能删除发现的损坏房间。我只能想象，当初设计Dendrite数据库结构的人，必然也深谙Synapse数据库的运作机制，他们完成这些工作所需的时间肯定比我少得多。

          事已至此，虽然资产负债表会好看许多，但社区层面造成的损害将持续发酵。若Element最终失败，Matrix被其他标准取代，我不会感到遗憾。

          回复

          1. 注：服务器数据源自https://matrixrooms.info/stats。虽非网络全景，但基于公共房间别名发现的服务器及使用其公证功能(可信密钥服务器)的服务器样本，仍具合理代表性。

             回复

    2. > 或许某天我会不再如此愤懑。毕竟Matrix是免费项目，即便它未能如我所愿运作，我又能真正愤怒到何种程度？但这很难。我曾全力投入其中，最终却给自己和无意卷入麻烦的小团队带来了诸多困扰。我曾信任Matrix，因它看似领先方案，但今后在将任何生态系统引入自身及亲友生活时，我必将谨慎百倍。比如至今我仍未搭建ActivityPub服务器…或许该静观其变，待事态明朗再做决定。

       很遗憾你遭遇了这样的经历——对此我只想补充一点：若缺乏维持运营的经济动力，服务终将难以为继。金钱并非我们应竭力规避的邪恶事物，它本质上是衡量个人时间精力与他人资源价值的标尺。

       回复

       1. 在拥有多元利益相关方与赞助者的健康生态中，这种担忧本可减轻。然而，Matrix基金会非但未能获得更多独立性，几乎所有业务都从基金会转移到了营利性公司。显然，事情并未按计划发展。

          我们这些运营家庭服务器的普通用户，既无力改变现状，也无力满足他们的预算需求。对我们而言，Matrix被宣传为开放的端到端加密聊天系统，我们为此买单。我们的购买行为对Matrix基金会/Element公司是否产生实质影响？不得而知。或许有助于推广Matrix扩大用户基数。无论如何，我们已为此押注，可能因此放弃了其他解决方案。

          如今开源的Matrix家庭服务器不得不与闭源商业版本竞争。我仍期待此事能有个圆满结局，但眼下形势确实岌岌可危。

          回复

          1. 我理解大家对Dendrite开发停滞的沮丧，但问题根源并非Element的恶意接管(毕竟Element最初同时开发了Dendrite和Synapse)，而是Element和Matrix基金会都缺乏资金同时维护两个家庭服务器项目。

             > 如今开源免费的Matrix家庭服务器竟要与闭源商业版本竞争

             实际情况并非如此——Element的核心重心始终是常规开源版Synapse，绝大多数开发资源(包括性能优化)都投入于此。Synapse Pro“仅”为政府级大规模部署提供可扩展性和高可用性支持——详见https://element.io/blog/scaling-to-millions-of-users-require…等文档。但支撑这些功能的所有模式设计等工作都归入开源版Synapse。

             回复

25. 遗憾的是，此处存在大量过时信息：

    > 缺乏管理面板

    管理面板位于https://github.com/element-hq/element-admin(但该功能相对较新，许多用户尚未注意到其存在)

    > 图片无说明文字 > > 这很荒谬，虽然(官方？)桥接器支持图片说明，但官方Element应用却不支持。

    Element Web和X版本支持说明文字。(Element Web目前不支持编辑说明，但可显示——显然这已在待办事项列表中)。

    遗憾的是，Element Classic版本已两年半未更新，因此确实不支持该功能。但现阶段旧版应用已停止开发，我们无力同时维护两个版本。

    > 通知延迟

    据我所知，这可能是服务器负载过高导致的问题。

    元素X运行较慢 > 不知为何，它确实更慢。点击对话框后需要0.5-1.0秒才能加载，而经典版几乎是瞬间加载。

    这是数周前修复的安卓系统特有漏洞；EXA版本现应恢复正常即时加载状态(至少在夜间版中如此)：问题源于https://github.com/matrix-org/matrix-rust-sdk/pull/5841 和 https://github.com/matrix-org/matrix-rust-sdk/pull/5854。尚不确定修复是否已合并至正式版本。

    编辑：该修复已在数周前随Element X Android稳定版发布。

    > 对话排序依据…无人知晓。既非按时间也非按字母排序。

    理应按时间排序。

    > 新用户引导流程糟糕

    抱歉，若要使Element X正常运行，必须运行认证服务器(matrix-authentication-service)。

    编辑：若上述内容有误请直接指出，不必直接扣分 😀

    回复

    1. > 管理面板位于https://github.com/element-hq/element-admin

       我认为作者使用的是常规Synapse安装方式，而element-admin没有apt包，需要手动构建且无法更新。

       > Element Web与X支持字幕功能——坦白说这简直两头不讨好

       如果旧版应用有功能A、B、C、D，新版有A、C、D、E，两类用户都会感到困惑。究竟该用哪个版本？在推进新功能前，必须确保与旧版应用的功能完全一致。我仍在等待这一步完成，才能建议用户切换。

       回复

    2. 你声称：

       > 这里有很多过时的信息

       然后却链接到三周前的议题和两个月前才真正存在的仓库？真是令人惊叹。

       若你认为这算过时，恰恰印证了楼主关于Matrix难以部署的主张。

       > 当前旧版应用已停止开发；我们无力同时维护两个版本。

       你这番说辞仿佛在为糟糕的用户体验开脱。但这绝非正当理由。

       回复

    3. 天啊，要是有个没有废物CEO的完整聊天协议，我明天就搬过去。Matrix组织的工作人员根本不懂如何与人沟通。

       回复

    4. > > 入门体验太差

       > 抱歉，但若想让Element X正常工作，你必须运行认证服务器(matrix-authentication-service)。

       我认为这有点离谱。他们竟敢废弃经典认证机制，强制要求部署新服务器组件——只为维持唯一受支持的客户端运行(该客户端至今仍无法像经典Element那样自主管理密钥和会话，尤其在非验证会话即将停用之际)。

       回复

    5. > 若上述内容有误请直接指出，不必直接扣分 😀

       或许这些说法本身未必错误，但它们完全回避了文章提出的其他关键问题(摘自文章标题)：

       * 需要持续清理
       * 数据库失控增长

       * 元素X被推荐为更优的新客户端。实则不然

       * 调用不具备向后兼容性

       更何况，仅因两周前修复了某个漏洞(甚至不确定是否已合并到正式版本！)就断言信息“过时”，未免太不厚道。更普遍地说，信息“过时”的时间节点，对你和实际用户可能截然不同。实际用户期望安装后即刻正常运行。即便存在重大漏洞、协议变更或应用需彻底重写的情况，若这些变化发生在2-3年内，对多数人而言仍不足以认定信息过时。除非系统能持续五年毫无问题地运行，否则这种说法难以成立——而现实显然并非如此。

       回复