[announcement] Telegram bridging to be retired Wed. 20 Sept. | 5 to-dos

[Ben Cooksley]

On Fri, Aug 25, 2023 at 3:12 AM Carl Schwan <carl at carlschwan.eu> wrote:

> On Tuesday, 22 August 2023 08:57:31 CEST Joseph P. De Veaugh-Geiss wrote:
> > Hello KDE community,
> >
> > apologies for cross-posting!
>
> Please let's stop doing that, it's generating a lot of duplicated emails
> for
> everyone. Most people interested in this discussion are in the
> kde-community
> channel and if they are not we should encourage them to join it. No need
> to
> have this discussion in unrelated, purelly technical and low traffic
> channel
> like kde-framework, kde-core-devel or release-team.
>

The cross posting was started to ensure that everyone is well aware this is
going to happen.

As sysadmin I have had far too many people claim they weren't aware of
something even when it was posted to many lists (including this one), so it
is understandable why we are cross posting here.
(A small handful of people even missed the notification about the Invent
server move, even with the heavy handed cross post approach I took with
that...)


>
> > The time has finally come: both Telegram <-> Matrix bridges will be shut
> > down in 4 weeks on *Wednesday 20 September*. Let's start the
> > co-ordination process now so everything goes as smoothly as possible.
>
> As one of the person who pushed quite hard a few years ago to improve our
> Telegram bridging situation, I'm very unhappy with this decision and I
> don't
> say this as a Telegram fan. Far from that, I love decentralized and open
> source social media and messaging platforms, I started developing NeoChat
> and
> Tokodon, I'm also quite involved around email client development and I'm
> barelly using my Telegram account (both for kde or private usage).
>
> So why did I push for Telegram bridging in the past? First of all,
> Telegram is
> an amazing entry point for new contributors. People don't have to adopt a
> new
> messaging app to talk with us, which reduce the barrier considerably.
> Particularly for newcommers, the more step they need to make to start
> contributing and publish their first commit, the higher the chance they
> give up
> midway. And as far I know, we deseperably need more contributors, so we
> are
> shooting ourselves in the foot with this move.
>
> Even people who are contributing for a longer time sometimes prefer to
> keep
> communicating with Telegram, because it's easier or it's just the medium
> they
> use for most their communication and they prefer to keep like this instead
> of
> investing time and changing their habits. As much as I want more people to
> adopt Matrix,  this is perfectly understandable and forcing them to change
> their habits as more change to loose them in the short to middle term as
> active contributor.
>
> Another reason, why I pushed for a better telegram bridge years ago, was
> because even if not everyone switch to Matrix, some people do which is a
> net
> gain in term of contributors and they might even be tempted to improve
> NeoChat.
>
> Now on the technical issues:
>
> >    * Telegram is not Free Software and has never been an official
> > platform for KDE communications. However, it has been used unofficially
> > in a number of areas.
>
> Gmail is also not Free Software and will allow people using a gmail
> account
> (booo) to communicate with us. Sure gmail still use a common standard to
> communicate with us, but using bridges is a somewhat working alternative.
>
> >    * EMS hosts KDE's Matrix instance and the current Telegram bridge,
> > and the majority of issues our community have with Matrix are related to
> > bridges. Due to the huge extra load and poor performance Telegram
> > bridging has in the Matrix rooms, it was agreed with EMS that the bridge
> > would be only run for about a year until people had time to migrate to
> > Matrix.
>
> Why wasn't this communicate before that this was only temporary in
> https://mail.kde.org/pipermail/kde-community/2021q2/006884.html ?
>
> I was completely unaware of that and I'm in the KDE IM ops room, the KDE/
> Matrix support room and in the KDE/Matrix VIP room.
>
> >    * However, instead of people migrating away from Telegram, we have
> > seen an increase in contributors using /both/ Matrix and Telegram, which
> > has doubled the number of users we have to cope with. Having twice as
> > many users as needed in the room slows everything down: longer joins,
> > more state events for each user, higher chances of room state developing
> > problems.
>
> The state events generated by the telegram bridge are in an order of
> magnitude
> less than the state events generated by the irc bridge since the telegram
> users usually don't join and leave a room multiple times a day. And
> similarly
> a lot of IRC users also have a Matrix account. I wonder how many double
> accounts there was actually, because to me it seems the issue was actually
> that there was too many Matrix users in the room which was then causing
> issue
> with the IRC bridge. If we expect 100% (very unlikely) of the telegram
> user to
> move to Matrix, we will likely have the same issues again.
>
> The IRC bridge also has the political issue that we can't see previous
> message
> when joining a room and that Matrix user who are not actively interacting
> in a
> rom get kicked out of a rom after a month, which has been a cause why
> people
> want to keep a Telegram account to avoid being kicked out.
>
> >    * The public Libera.Chat bridge was unexpectedly shutdown, and we
> > have to move rooms over to the matterbridge (ircsomebot) bridge as we
> > work through moving channels over to our own Libera.Chat IRC bridge.
> > This is not as originally planned, which was to migrate to that IRC
> > bridge after the Telegram shutdown.
> >
> >    * The vast majority of spam is from Telegram.
>
> Source needed. I'm in the kde moderation room and regularly do moderation
> for
> our Matrix channel and while we had in the past a few spam wave coming
> from
> Telegram, currently most of the spam is coming from matrix.org and
> libera.chat.
>

I believe this depends on the channels you are in.
For a while some channels (#kde-devel being one of them if memory serves)
were definitely the target of spambots based on Telegram.

It is likely that for a given channel, the dominant side is less likely to
experience spam, while the less dominant and therefore less well moderated
parts will experience more spam.



> >  Due to the Telegram
> > bridge account being reported for spam, the account has lost the ability
> > to do admin tasks in many rooms. At its worst the account was blocked
> > from logging in for weeks, making the bridge non-functional. Since then,
> > rooms often can't be bridged without deleting the Telegram room and
> > starting fresh, but this only has about a 30% success of working
> > long-term. We did not get anywhere attempting to get Telegram to help.
> >
> >    * The current Telegram bridge doesn't work properly so it makes sense
> > to shut it down rather than trying to just change account phone numbers
> > (which would require removing the bridge from all channels then
> > re-adding to a new bridge, with high chance we end up in the same
> > situation in the future).
>
> To me, it would make more sense to spread out the responsability of
> managin
> the telegram bridging into more shoulders. I know some people would be
> interested in helping with the managements.
>
> Alternatively, we could go back to the unofficial Telegram bridging we
> were
> doing in the past. I was happy when it was replaced by something more
> official,
> but that might be a last recourse solution.
>

Given that it appears that for a selection of channels (not necessarily
all) we are going to need to maintain bridges to Telegram, are there any
suggestions for resolving the problems we have experienced with the bridge
being reported as a spammer?

>From what I understand here, a huge part of the interest in getting rid of
the Telegram bridging is because we will now have to take it over and it
has caused us substantial issues (including not working from time to time
and being unreliable - and an unreliable bridge is actually worse than no
bridge at all).


>
> Regards,
> Carl
>
>
>
>
Cheers,
Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-community/attachments/20230825/1015173d/attachment-0001.htm>