矩阵一周

用户不小心在 Matrix 空间的房间中写入，导致该空间的每个成员都会收到通知。矩阵空间只是普通房间，不支持空间的老客户端的后备方案是将它们呈现为完全普通的聊天室。另一方面，当人们开始在空间中聊天时，支持空间的新客户端的用户界面会非常混乱，因为这是不应该发生的。 （然而，大多数客户不会调整空间中的房间权限以禁止人们在那里聊天。这太容易了。）我弄清楚如何让 Element Web 将空间显示为常规房间，以便检查它（它在开发工具中），给自己管理员权限并调整房间的权限以禁止在空间房间中聊天。一位用户报告了论坛上的虚假禁令，称他们被禁止进入我们的 Matrix 空间，但不知道原因。对用户句柄的快速 Draupnir 查询没有显示出任何有趣的内容。经过一番尝试后，我改为向 Draupnir 查询用户句柄的域。事实上，它找到了一个条目： !foQLZposNt3iEpkl5O:example.org m.policy.rule.server ( m.ban ): … (spam) 显然，我们空间的审核列表上的某个人订阅了禁止该用户的域（看起来它可能是一个单用户个人实例）。我不在房间 !foQLZposNt3iEpkl5O:example.org 中，我认为该房间是发出禁令的政策室，而 Matrix 烦人地不会告诉我它的标题。但它似乎是公开的，所以我尝试加入它来了解一下。我的家庭服务器在尝试加入我时有点卡住，警告 conduwuit_api::client::sync::v3::joined: 新加入房间的时间线为空，但它随后要求另一台服务器回填时间线，然后我只需“清除缓存并重新加载”我的客户端（这也会顺便将我的所有聊天标记为未读，之后我必须再次手动清除），然后我就进去了。该房间就是其中之一社区汇集的政策室，充满了来自 mods 和审核机器人的 m.policy.rule.user 类型的消息，这些消息有时会禁止具有非常明确的用户名的人员和服务器。我搜索受影响用户的域，但 Element 只会搜索 m.messages 类型的消息，因此搜索结果为空。当搜索不起作用时，通常的解决方法是将聊天导出为 HTML，然后对其进行 grep，希望相关消息位于导出的范围内。幸运的是，房间导出确实包括所有消息类型，并且 grep 域给了我七次点击。事实证明，受影响用户的家庭服务器在过去的某个时刻意外地进行了开放注册，从而产生了预期的后果。谜团解开了。我花了大约 40 分钟才得到这些信息。最多应该是两个。后记：两周后，该用户再次联系我，他们仍在为被封禁而苦苦挣扎。我只能看到他们的域名仍然在禁止列表中。我找不到一种简单的方法来对禁止列表进行本地覆盖，因此我们只能取消整个禁止列表的订阅，这可能会使整个社区面临垃圾邮件和滥用行为。当新人加入我们的 Matrix 空间时，他们似乎无法看到其中一个房间，尽管他们被“建议”进入该空间。在他们手动加入该房间后，它确实会显示在该空间的房间列表中。可以从不同家庭服务器上的不同帐户重现该问题。再次删除房间并将其添加到空间中似乎没有帮助。即使是墓碑和重建房间似乎也不是解决方案。但是，如果其中一位空间管理员加入该房间，它会突然再次出现在该空间的房间列表中。当他们再次离开时，房间又重新消失了。我们接受明显的解决方法并继续前进。经过一些例行服务器维护后，Draupnir 停止响应管理命令。根据服务器日志，Draupnir 似乎处理命令的情况很好。一些长时间的调试会话表明，这是 Draupnir 的主服务器（它是那里唯一的帐户）的出站联合问题。更多调试表明，这是 Dendrite 默认配置的问题，该配置会无缘无故地丢弃所有出口 IPv6 流量。注意到并调试这个问题总共花了一个多月的时间，在此期间社区空间没有受到审核机器人的保护。我很高兴我们在那段时间没有受到色情和血腥垃圾邮件浪潮的打击。如今，Dendrite 作为家庭服务器已被弃用，至少它似乎不是开发的主要焦点，而且最近的提交只是依赖项的增加。几年前，当服务器建立时，选择 Dendrite 似乎是一个不错的决定，因为它比 Synapse 更容易部署和维护，并且第一个第二代家庭服务器实施有望拥有光明的未来。不幸的是，在 Matrix 家庭服务器实现之间迁移仍然是一个问题