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

[Joseph P. De Veaugh-Geiss]

Hi all, we are a diverse community with a diverse set of needs, that is 
evident in the responses. There may be a more general discussion to be 
had about formalizing a process for adding/removing services to KDE's 
infrastructure. In fact, there is currently a Phabricator task about 
this, which I will link to shortly in a separate email to keep responses 
to this email specifically about Telegram bridging.

Regarding the current discussion, I think it is important to reiterate 
that Telegram bridging is causing problems, this is not new (see below), 
and whatever our community needs must address that. Indeed the reason I 
got involved now is due to the bridge being down a few weeks ago and 
Paul suggesting I reach out to sysadmins to clarify the situation for 
the community. From what I understand: the Telergam bridging situation 
as it is now is not manageable long-term, and may not even be manageable 
short-term for those dealing with it (see the end of this email).

Since it has been a big part of the discussion the past two days, I feel 
it may help to establish what was recently discussed publicly re 
shutting down the Telegram bridges. I have included an overview at the 
end of this email for those who want it. I hope it is helpful, at the 
very least in establishing common ground. In short: from what I can 
tell, the problems re Telegram bridging were publicly discussed (see 
below), but not in a way that was obvious from the subject line or 
conducive to further discussion, and it does not seem there was any 
discussion directed at the Telegram userbase specifically. I have also 
gone over the kde-community mailing list going back to 2017 to get some 
history about instant messaging at KDE. I figured this may help 
understand why we are in the place we are currently at. There was a lot 
of lively debate, to put it kindly :) And issues about Telegram bridging 
have been brought up going back at least 5 years (see, for example, [1], 
[2]; also some positive changes [3]).

  [1] "Telegram-IRC bridge not working" thread (2018): 
https://mail.kde.org/pipermail/kde-community/2018q1/004346.html
  [2] Reply to "The chat situation" thread (2020): 
https://mail.kde.org/pipermail/kde-community/2020q2/006330.html
  [3] "Telegram Bridge Migration" thread (2021): 
https://mail.kde.org/pipermail/kde-community/2021q2/006884.html

Underlying many of the discussion points the past couple of days seems 
to be a distinction between incoming vs. outgoing vs. internal 
communication (this is the three-way distinction I used in the Akademy 
presentation, there are likely other relevant distinctions, maybe even 
just a simple inreach vs. outreach).

  * /Incoming/: How KDE receives information from the world
  * /Outgoing/: How KDE shares information with the world
  * /Internal/: How KDE exchanges information among contributors

Using this paradigm, it may help to consider which communication 
channels are used for which purposes (i.e., mapping the three types of 
communication to KDE's communciation channels). For example, would you 
agree with the following?

  * Mailing list (long-form discussion): primarly internal communication
  * Matrix/IRC/Telegram (real-time chat): in some cases used for 
internal communication (developer teams), in other cases for 
incoming/outgoing communication (outreach teams)
  * Discourse (forum): primarily incoming/outgoing communication, only 
limited internal communication
  - ....

So, if we need to find a structured way to decide how to allocate 
resources, it seems reasonable to me to suggest those teams with a heavy 
outgoing/incoming focus have good reason to need access to widely-used 
proprietary platforms and corresponding technical support (the 
"exceptions" in the initial announcement). As has been pointed out many 
times, much of the world is on those platforms, as unfortunate as that 
may be.

There may be other teams that have particular needs requiring 
exceptions, and those should also be considered, but maybe there can be 
agreement on the above at least.

Then the questions is: how do we use the resources we have to support 
those teams? I cannot speak to that, unfortunately.

Maybe this helps?!

Whatever we do, please recall that most involved are volunteering their 
time and energy for the love of KDE. We have a diverse set of needs, 
from those of the sysadmins to the developers, from the visual design 
group to the promo team. Let's make sure we try to see the situation 
from all point of views and reply to each other gently with that in mind.

Cheers,
Joseph

== Recent Public Discussion Overview re Telegram Bridging

Nicco is correct that the June thread "Telegram <-> Matrix bridges will 
be removed in September" did not result in a discussion about closing 
the Telegram bridge, despite the subject line. As Nicco pointed out, 
Nate wrote: "If the discussion has not yet started, then it seems a bit 
premature to be making any decisions now based on potential future 
outcomes of said discussion." Although there were some further points 
made about Telegram bridging in response, the thread did not result in a 
community decision-making re shutting down Telegram bridges.

Telegram bridge problems were also part of the May discussion 
"Retirement of IRC Services and KDETalk.net (Jabber)". The subject line 
did not mention Telegram. Email thread starts here:

   https://mail.kde.org/pipermail/kde-community/2023q2/007607.html

The points about Telegram embedded in the discussion from various 
contributors are as follows. (I did not cherry-pick some responses, 
these are all that I can see specifically related to Telegram -- I hope 
I didn't miss any.)

 > Given that we are now fairly well migrated to Matrix, the need to 
maintain our Telegram bridging is much reduced, and i'd therefore like 
to retire that without replacement.

 > Either way, those channels should migrate to the Matrix provided 
bridge if they still need bridging (ideally the Telegram channels would 
be shutdown as they're a significant source of abuse)

 > As [...] pointed out it isn't Mattermost that we use for Telegram 
bridging. Telegram is currently mainly using a mautrix-telegram bridge 
run for us by EMS, this was only ever planned as a short term service to 
aid in getting the users in the unofficial Telegram rooms to migrate 
over to Matrix. Some rooms are still using the legacy Telegram <> IRC <> 
Matrix bridging due to issues with the number of users in some rooms and 
broken permissions on the Telegram side
 >
 > The current situation with Community members using Telegram is that 
the majority also have Matrix accounts that they use to take part in 
other chats. This results in a duplication in users in lots of our rooms 
that has negative impacts on Matrix and IRC having to handle all these 
extra users/connections. The Telegram bridge is also a major source of 
spam coming into us and onto IRC. There isn't anything we can do to 
properly manage this as we have no control over how Telegram is operated.
 >
 > The current plan is for the Telegram bridge to be decommissioned 
later this year. We may consider alternative options for some outreach 
related channels, but within KDE it is redundant

As also noted, there was a (hybrid format?) discussion in an Akademy 
BoF, which many contributors were not aware of. The notes are here:

   https://community.kde.org/Akademy/2023/IM_Infrastructure_BoF

Regarding Telegram:

 > Telegram Bridge
 >   * needs to go away as we lost access to some of this due to it 
being reported as spam
 >   * runs on infrastructure which we could only use for a short period 
of time
 >   * set up new Telegram bridge, but only for external facing rooms
 >       - causes high load
 >       - big spam source, as banning isn't propagated

-- 
Joseph P. De Veaugh-Geiss
KDE Internal Communications & KDE Eco Community Manager
OpenPGP: 8FC5 4178 DC44 AD55 08E7 DF57 453E 5746 59A6 C06F
Matrix: @joseph:kde.org

Generally available Monday-Thursday from 10-16h CET/CEST. Outside of 
these times it may take a little longer for me to respond.

KDE Eco: Building Energy-Efficient Free Software!
Website: https://eco.kde.org
Mastodon: @be4foss at floss.social