The chat situation

[Christian Loosli]

Am Freitag, 12. Juni 2020, 07:09:01 CEST schrieb Nate Graham:
> The incompatibility in capabilities between IRC, Matrix, and Telegram
> feels like it makes smooth communication between all three all but
> impossible. Maybe I'm wrong about this--hopefully I am! Because I think
> that if we're going to stay with Matrix, we need to somehow improve the
> UX in directions that attract all the people who currently use either
> Telegram or IRC with the goal of deprecating both.

There will always be incompatibilities if you bridge multiple protocols, no 
matter which ones they are. And given the survey results I doubt that we will 
ever find the one single solution that makes everyone happy. 

Others tried, others failed, and I can't see how we could do any better.

> Because if Matrix
> can't be better than the two things it was intended to replace, then
> it's not a success, right?

It was not supposed to replace IRC, but rather extend it, like kate and 
kwrite. 

Unless we run our own, non-federated instance of Matrix and develop two 
clients for it, I highly doubt that IRC can be fully replaced. 

Can't say much on the Telegram end as I don't use that the same way I use IRC 
/ Matrix, but I'm pretty sure power users there will find similar arguments. 

We had that discussion, in length, with surveys and votes. 
So instead of doing this yet once again, maybe we should focus on papercuts 
that can be resolved, and I think most of the papercuts mentioned can.

> If our Matrix instance is sponsored such that requesting support,
> maintenance, or development resources costs somebody else time and
> money, that seems problematic for the prospect of the issues under
> discussion being ironed out. Hopefully there are at least some things we
> can take care of on our side to improve the situation.

I don't see how we could avoid that. Either we run our own instance, then it 
costs us time, or we have a sponsored instance, then it costs someone else 
time. Either we develop fixes ourselves, which costs us time, or we have 
someone else develop them, which costs them time. And in case of it being a 
business (like our matrix instance sponsor sort of is), time means money.


As for the papercuts mentioned: 

- lag and bridge issues could most likely be bettered a lot by what Kenny 
mentioned, but this has to be done by our Matrix folks. From what I 
understand, we did ask them to and poke, but nothing happened, so maybe we 
should poke again. I don't mind the e.V. doing that, I don't mind throwing 
money at it if that is needed, but I think it should be possible without.
We might also have to discuss again how exactly we bridge Telegram, currently 
we do   Telegram <> IRC <> Matrix  while  Telegram <> Matrix <> IRC might be 
more wise. That could start hitting limits on the IRC side, but for the KDE 
bridge these can be raised if needed.

- Registration issues due to the IRC bridge ("can't write to / join channel"): 
We can solve that on our end most of the time simply by not requiring our IRC 
channels to be for registered users only. I recommended that a couple of times 
and helped fixing it where it was still the case. If there are still such 
channels, I also gladly help out there. I am not aware of any, though, so I 
don't know why this came up.
If we do have to force registrations  (e.g. due to a spam attack by someone 
unhappy with KDE) this could be fixed by making the process more straight 
forward on the Matrix end, which requires some development effort in Matrix 
clients, but it can be done, it's not like freenode Nickserv changes behaviour 
often (close to never). 

- Protocol incompatibilities: mostly fixable on the Matrix side, there are 
various feature requests open on their end  (e.g. when it comes to Telegram 
stickers), all of this is feasible since Matrix already stores documents 
anyway, so it can just point a link to the document (graphic, video, whatever) 
for protocols that do not allow it. It also already handles message lenght 
restrictions, not perfectly, but it handles them. 

What always will be an edge case is the different protocols having different 
ACLs, e.g. if we get Telegram spam (and despite Telegram requiring a phone 
number to register, we quite often do get Telegram spam) an admin in the 
Telegram group should handle it. This can be semi-fixed by bridging with a 
connection per connection (which brings other, new issues), so that e.g. 
Matrix could ban a spammy Telegram connection, or IRC a spammy Matrix 
connection (this is already possible), but in the end, we'd probably need to 
find decent ways of administrating stuff across bridges. 

Again, I don't think that switching to a single protocol / product works, 
Mozilla tried, Mozilla communities are now spread over 3 protocols, one split 
in two places. That's hardly what we want to achieve. And I doubt that we can 
bring every person to be happy with one single product, requirements per group  
(e.g. VDG) are simply too different.

> Nate

Kind regards, 

Christian