Bridging issues between Matrix and Telegram
Note: We love Fractal and know there are other Matrix apps that exist but the core features we are seeking in unifying our two bases is a single app that has support for a web client and a mobile app like Riot does. Fractal, as an example, is currently only a desktop client for GNOME, thus does not fall under our criteria.
At the Engagement BoF I proposed bridging Riot/Matrix and Telegram together as a short term solution to the current community/communication issue that exists with users being in either the Riot/Matrix or Telegram version (e.g. Engagement group), but not being in and/or using both. Currently there are three core issues with this situation:
- Many IRC users naturally have transitioned to Riot/Matrix, a large portion due to the IRC<->Riot/Matrix bridge (albeit buggy), but we must retain a bridge for users that wish to not move from IRC
- Riot/Matrix is a wonderful step forward, especially in that it has a web client and phone app. It is not perfect, however, as there are several known issues and bugs with it (e.g. mobile app issues, IRC users may not always get messages from Riot/Matrix users) deterring more users from potentially joining it. On the other hand its modern appearance and ease of understanding/use is promising
- Telegram is very pretty and convenient (web client/mobile app) but closed-source and proprietary
Having two separate conversations [assuming the IRC<->Matrix bridge is working without dropping messages] simply does not make sense in terms of productivity; our ability to effectively communicate to work on and discuss things together shorts the moment entire groups of people are alienated and miss out on crucial bits of information, simply due to their choice of primary chat apps.
I looked at the Telegram APIs which were nice and easily accessible, and Matrix initially seemed to have good bridging options, including Telematrix and mautrix-telegram on their site. There were, however, a few issues that I ran into:
- No matter the option, it will have to be added into the current cloud infrastructure that we have (having an individual self host would be problematic for several reasons)
- Telematrix, the only bridge of the two in alpha, is no longer maintained (last commit was in March with a rather sparse history even before that) and has quite a few issues that are no longer being worked on.
- There is a very red flag-y Telematrix home server and instance by tchncs that would be easy to use and setup quickly yet I would avoid this as a solution because:
- They are running modified code that is not accessible online, while claiming it is open source
- Their social media posts, especially the ones detailing a multi-day/week long downtime due to switching to a new machine is... interesting to say the least
- They are seeking money for a Patreon for this, with otherwise a very limited history and/or information available online that would affirm they are a legitimate person
- mautrix-telegram is currently still in beta
- I found a blog post where Mikaela also describes issues with Telematrix and proposes using the TeleIRC bridge, however a key part of the post is:
- "Telegram users appear as separate IRC connections draining resources on both matrix.org (running the bridge) and IRC server and freenode has expressed being unhappy about idle connections. In case of SailfishOS Fan Club this meant 300 additional connections. The Telegram users also cannot be sent private messages and all Matrix/IRC users appear as single bot at Telegram, so I don’t think it’s worth it."
After some quick discussion in the GUADEC 2018 Telegram group, Jiří Eischmann (sesivany) looked into and discovered that the Fedora room was using Teleirc. Following the installation instructions it seems a possible road map with this solution for now would be that whoever is in charge of the infrastructure would add the bot and bridge in (simply because whoever "installs Teleirc will have elevated privileges to maintain and administrate the Telegram bot") albeit it being resource heavy. This would be a short term solution.
A more long term future road map would likely be the creation of a GNOME web client/mobile app.