吉特现在母语为Matrix
自从我们宣布Gitter即将加入Matrix以来仅两个多月，我们非常自豪地宣布Gitter已正式启用真正的Matrix本地连接：现在所有公共Gitter会议室都可以通过Matrix本地使用，并且现在所有Gitter用户都可以使用因此，如果您想加入官方的Scala语言支持室https://gitter.im/scala/scalafrom Matrix，只需转到#scala_scala：gitter.im和* boom *，在！
这意味着Gitter现在在gitter.im上运行一个Matrix家庭服务器，该服务器公开了所有活动的公共房间-因此，如果转到（例如）Element中的room目录并选择gitter.im作为家庭服务器，则可以直接跳入：
进入后，您可以在Gitter端和Matrix端的用户之间透明地来回聊天，而不再有丑陋的“ Matrixbot”用户来回伪造消息-这些是“真实”用户，直接交谈彼此之间，每个公共房间中的每个公共消息现在都会自动暴露给Matrix。
因此，突然之间，以前只生活在Gitter中的所有开发者社区（Scala，Node，Webpack，Angular，Rails和成千上万的其他社区）现在都可以在Matrix上的任何地方使用-以及从Freenode和Slack桥接的社区； Mozilla，KDE，GNOME社区等本地Matrix社区。我们希望通过Matrix将所有内容粘合在一起，将迎来一个开放和碎片整理的开发人员协作的新时代，有点像我们过去在IRC上的经历。
对于移动Gitter用户来说，这也是个好消息-因为最初的移动Gitter客户一直处于持有状态，并且Gitter的本机Matrix支持意味着他们现在正式弃用了Element（或其他任何移动Matrix）客户）。
现在，这是Gitter对Matrix的原生支持的第一个切入点：自从Gitter加入Element以来，大部分时间都花在了从Gitlab到Element的迁移上，到目前为止，连接Matrix确实只有一个月的工作。结果是：所有重要功能都可以使用，但是还有一些尚待解决的问题：
将完整的Gitter成员身份列表同步到Matrix。目前，随着人们说话，成员身份逐渐同步
可以从Gitter加入Matrix上的任意房间。这可能会消耗Gitter上的大量资源，我们也不急于将所有Matrix镜像到Gitter。当Gitter与Element合并为一个纯Matrix客户端时，将解决此问题。
桥接反应。 Gitter今天还没有这些功能，我们宁愿将它们添加到Gitter中，而不是将它们添加到Gitter中。元素在一起。
有关更多详细信息，我们强烈建议您从Gitlab上直接查看本机Matrix史诗，以获得直接从煤层获得的未变色真相！
就这项工作而言，Gitter是一个很好的案例研究，它说明了如何轻松地将现有的大型现有聊天系统插入Matrix。
添加“虚拟用户”，以便可以在Gitter中正确建模和表示远程Matrix用户：https：//gitlab.com/gitterHQ/webapp/-/merge_requests/2027/diffs。只需在您的聊天消息/帖子/推特架构中添加一个virtualUser属性即可完成此操作，该属性包含mxid，displayName和avatar作为您的author字段的替代项。然后，只要在作者上可用，就显示virtualUser。
将应用程序服务添加到Gitter以桥接＆amp;中的流量矩阵外：https://gitlab.com/gitterHQ/webapp/-/merge_requests/2041/diffs此＆＃34;应用程序服务＆＃34;在很多情况下都会为您预先打包，因此例如，您可以简单地放入Node.js应用程序中的matrix-appservice-bridge之类的库，并且为您处理所有Matrix对话的复杂性。
第一步是将虚拟用户的概念添加到Gitter中。我们还可以为出现的每个新矩阵ID创建一个新的Gitter用户，但是将它们标记为虚拟用户会更干净一些。
弄清楚如何平衡进出Gitter的矩阵流量。通过我们现有的负载平衡器设置（ELB），可以免费传播入站负载，在该设置中，我们已经有8台运行gitter.im各种服务的Webapp服务器。我们只需在每个Web和api进程旁边的服务器上运行Matrix桥接器，然后负载均衡器的matrix.gitter.im就会扩展到服务器。
然后，来自Matrix的事件到达负载均衡器并到达其中一台服务器（处理事件时不重复）。
如果发生了Gitter上的某事，则该动作将在一台服务器上发生，我们只需将其传播到Matrix（无需重复或锁定）即可。
应用程序中已经有实时websockets和Faye订阅，一旦发生任何更改，这些订阅都由Mongoose数据库挂钩支持。当我们在Gitter上收到新信息时，我们只是利用了同样的东西就可以将新信息桥接到Matrix。
连接官方的Matrix桥接matrix-appservice-bridge库，以使用Gitter现有的MongoDB代替nedb进行存储。
弄清楚如何为gitter用户的mxid命名空间：最好让人类可读的mxid，而不只是服务中的数字userId。
但是，如果人们可以在您的服务中更改其用户名，则您将无法在Matrix上更改您的mxid。将来，我们将在Matrix中提供可移植帐户来支持此功能（MSC2787），但遗憾的是，这些帐户目前仍是蒸气软件。
如果您在用户重命名用户名时天真地切换用户的mxid，那么最终可能会泄漏mxids之间的对话历史记录（！）
因此，我们使用@ username-userid：gitter.im作为Matrix ID，以使其更具可读性，而且具有唯一性，因此可以进行任何重命名而不影响任何内容。
对于会议室别名，我们决定将我们的社区/会议室URI语法更改为下划线，以表示会议室别名#community_room：gitter.im
使用户和会议室数据保持同步我们还没有到达那里，但是数据来自同一个Mongoose钩子，我们可以在Gitter端更改时更新桥接数据。
同时，gitter.im的Matrix端由Element Matrix Services托管，并且是一个普通的Synapse，通过Application Service API与Gitter进行通信。另一种架构是通过将“ homeserver库”嵌入到Gitter中，使Gitter直接与Matrix联合（例如，嵌入Dendrite）。但是，鉴于Dendrite仍是beta版本，并假定它自己存储数据（而不是持久保存在Gitter的mongodb等现有后端中），因此我们选择了一个更简单的选项。
在《本周的矩阵》中的Gitter更新中，看到每周如何播放这种情况真是很有趣：您可以从字面上跟踪进度并查看在10月9日，10月23日，11月6日，11月27日之间集成如何生效最后是12月4日
非常感谢Gitter的首席开发人员Eric Eastwood和该项目的幕后策划者，也感谢Half-Shot和Christian，他们一直提供Matrix桥接团队的所有支持和审查。
首先，我们将通过上面列表的“剩余内容”部分进行工作：杀死旧桥，整理铅垂的房间，连接DM，将旧的Gitter历史记录导入Matrix等，然后这应该我们在Gitter＆amp; A矩阵。
从中长期来看，Element / Gitter联合团队分拆维护两个备受瞩目的Matrix客户的努力根本没有效率。我们的计划是将Gitter的功能合并到Element（或Element的下一代）中，然后-当且仅当Element与Gitter达到同等地位时，我们才希望将gitter.im上的部署升级到Element的Gitter定制版本。不可避免的副作用是，我们将向Element添加新功能，而不是Gitter。
即时观看实时房间（不到一秒钟即可将Webapp加载到拥有2万用户的大型房间的实时视图中！）
我们建议在MSC2775上进行快速窥视（通过联邦上的延迟加载状态），并在MSC2753和MSC2444上提出新的窥视API（甚至由Dendrite实施）
社交登录，可通过GitLab，GitHub＆amp;进行无缝注册。朋友几乎登陆了Element：https://github.com/matrix-org/matrix-react-sdk/pull/5426
几周前，由于akissinger和thosgood，KaTeX支持进入了Element Web
尚待改进的唯一方面是更紧密的GL / GH集成以及更好的搜索引擎优化的静态档案。
因此，我们的计划是破解其余的功能奇偶校验，然后合并Gitter＆amp; 在一起的元素-同时继续将世界其他地区纳入Matrix :) 我们生活在激动人心的时代：基于开放标准的可互操作的通信再次兴起，我们希望Gitter在Matrix中的新生活是跨项目开发人员协作新时代的开始，最终摆脱了我们经历的分散 最近几年。 最后，请务必通过Gitter或Matrix（或发送邮件！）给出有关集成以及下一步工作的反馈！