在矩阵中的一个星期 在矩阵中的星期一 一名用户意外地在矩阵空间的房间里发言，导致该空间的每位成员都收到了通知。矩阵空间就像普通房间，而不支持空间的老客户端的回退方式是将它们转化为完全的普通聊天房间。另一方面，支持空间的新客户在里面开始聊天时用户界面会非常混乱，因为这本不该发生。（然而，大多数客户端并没有在空间中调整房间权限以禁止人们聊天。这太简单了。）我发现如何让Element Web将空间显示为普通房间以进行检查（它在开发工具中），给自己管理员权限，并调整房间权限以禁止在空间房间聊天。 在矩阵中的星期二 一名用户在论坛上报告了一个虚假的禁令，表示他们在我们的矩阵空间被禁，且不知道原因。快速查询用户处理程序的Draupnir显示没有任何有趣的内容。在尝试后，我为用户处理程序的域名查询Draupnir。确实，它找到了一个条目：!foQLZposNt3iEpkl5O:example.org m.policy.rule.server (m.ban)：…（垃圾邮件）显然，我们空间订阅的某个管理名单上的人禁止了该用户的域名（看起来可能是单用户的个人实例）。我不在房间!foQLZposNt3iEpkl5O:example.org， 我假设这是禁令所在的政策房间，而矩阵恼人的是不会告诉我它的标题。但它似乎是公开的，所以我尝试加入以找出真相。我的家庭服务器在试图让我加入时有些卡住，警告 conduwuit_api::client::sync::v3::joined: 新加入房间的时间线为空，但它随后询问另一个服务器来填充时间线，接着我只需要“清除缓存并重新加载”我的客户端（这也会将我所有的聊天标记为未读，之后我还必须手动清除）我就进去了。该房间是社区集中式政策房间之一，充满了来自管理员和管理机器人类型的m.policy.rule.user的消息，这些消息禁止某些用户和服务器，有时用户名称随之非常明确。我搜索受影响用户的域名，但Element只会搜索类型为m.messages的消息，因此搜索结果为空。搜索不成功时的通常变通办法是导出聊天为HTML格式，然后在其上grep查找相关消息是否在导出范围内。幸运的是，房间导出确实包括所有消息类型，grep查找域名给我七个结果。结果是，受影响用户的家庭服务器在某个时候意外地开放了注册，产生了预期的后果。谜团解开。这条消息的获取大约花了我40分钟，本来应该最多两分钟。 后记：两周后，我再次接到该用户的联系，他们仍在为被禁而苦恼。我只能看到他们的域名仍然在禁令列表中。我找不到简单的方法来对禁令列表做本地覆盖，所以我们几乎无能为力，只能退订整个禁令列表，这可能使整个社区暴露于垃圾邮件和滥用之中。 在矩阵中的星期三 在为新人员引导我们的矩阵空间时，似乎有人无法看到其中一个房间，尽管被“建议”加入该空间。在他们手动加入该房间后，它出现在空间的房间列表中。这个问题可以从不同的家庭服务器上的各种帐户中重现。重新添加房间到空间似乎没有帮助。即使是墓碑化和重建该房间似乎也不是解决方案。然而，如果某个空间管理员加入该房间，它又会突然出现在空间的房间列表中。当他们再次离开时，房间又消失了。我们接受明显的变通办法并继续前进。 在矩阵中的星期四 在一些例行服务器维护之后，Draupnir停止响应管理员命令。根据服务器日志，Draupnir似乎正常处理命令。一些长时间的调试会话表明这是与Draupnir的家庭服务器的出站联邦问题（这是唯一的帐户）。更多的调试发现这是Dendrite默认配置的问题，它无缘无故地丢弃所有出站的IPv6流量。注意并调试此问题总共花费了一个多月，在此期间，社区空间没有受到管理机器人的保护。我非常高兴我们在此期间没有受到色情和血腥垃圾邮件攻击。如今，Dendrite在作为家庭服务器的角色上已有些过时，至少它似乎不是开发的主要焦点，最新的提交仅是依赖性提升。多年前，当服务器被设置时，选择Dendrite似乎是个好决定，因为它比Synapse更容易部署和维护，并且对于第一个二代家庭服务器实现有一个光明的未来的承诺。