Add in-house matrix bridge - matrix.gitter.im
In light of Gitter going fully open source and more service-agnostic (no longer exclusive to GitHub) in the near future, I'd like to put in a feature request for a first class "matrix-bridge" project, equivalent to the irc-bridge for the IRC protocol.
Chat software is at a critical point right now.
-
Freenode is under the PIA umbrella. While I ultimately think this is a huge win for Freenode (yay for sustainable open source!) it does mean Freenode is a little less free than before. I trust the Freenode devs & PIA to continue to shepherd the Freenode project & community responsibly, but at the same time I firmly believe that competitive alternatives are the best way for any project to "stay true to itself".
-
Slack is a great tool (I use it every day for work), but it's not good for open source. No really, it's just not.
With Gitter going open source, backed by a truly open source company, Gitter could easily become the spiritual successor of Freenode. More user friendly; just as open; sustainable and, lastly, multi-protocol.
I'm aware of #1076 (closed) and matrix-appservice-gitter, but all of these solutions require a degree of setup that most projects can't be bothered with. By far the best way to make the Matrix protocol accessible would be to support it to the same degree that you already support IRC.
Implementation details
Create a Matrix Application Service (AS) to bridge messages between Gitter <-> Matrix.
We can use matrix-appservice-bridge to handle all of the Matrix AS technical details. It is Node.js based so we can directly integrate it into the webapp and be easier to bridge all messages over to Matrix.
We can probably hook into server/event-listeners/bayeux-events-bridge.js
to get a stream of everything new to pass through the bridge.
For reference, here are some docs on Matrix AS:
- https://www.matrix.org/docs/guides/application-services
- https://matrix.org/docs/spec/application_service/r0.1.2
What rooms are being bridged?
As an initial iteration we are going to support public rooms.
Then DM's between Gitter and Matrix people.
For private rooms, the permissions mapping is hard so we will have to do some further thinking.
What do the URL’s look like for accessing Matrix things?
Under a matrix
group/namespace on Gitter:
- For a DM:
https://gitter.im/matrix/@madlittlemods:matrix.org
- For a Matrix room (not planned to support):
https://gitter.im/matrix/!vYjRCIoySolvxmhMJE:matrix.org
- For a Matrix room (not planned to support):
https://gitter.im/matrix/#elements-internal:matrix.org
We will probably need to add a new type of room to support the DM's, type: 'BRIDGED_ONE_TO_ONE'
type: 'VIRTUAL_ONE_TO_ONE'
or create unique URL's for the chat rooms.
What do Gitter users look like on Matrix?
We can make the Matrix ID(MXID) look like @username-5f762fc33936770384932b97:gitter.im
which consists of the username and the unique immutable userId
.
This way we don’t need to worry about collisions because it has the unique userId
which doesn't change between GitLab or GitHub renames. If someone renames, we can just use create the new MXID @my-new-user-5f762fc33936770384932b97:gitter.im
and keep bridging.
The main concern around a collision would be leaking DM's from a previous person. Because the MXID has the Gitter userId
built-in, we can strictly follow the userId
and bridge messages to the true user regardless of their username.
What do Matrix users look like on Gitter?
See https://gitlab.com/gitlab-org/gitter/webapp/-/issues/1076
Are we going to bridge the whole Matrix ecosystem(all rooms) into Gitter?
No, we will only be bridging Gitter rooms.
What about feature mismatches between Gitter and Matrix?
Figure out how to expose threaded conversations on the Matrix side?
Replies
Figure out how to expose reactions on the Gitter side?
Just not worry about reactions.
Possibly just pass through a couple reactions like