Re: Matrix IRC bridge considered harmful


On April 19th 2020 we completed the server set up configured as agreed. After that, we though everything was done and ready, and as you probably remember we did actually informed the community about the improved services [0]. That the previous answer to this thread make it sound like it has been on hold because of us since then is not correct and I believe it has more drama on it than it needs to be.

We do truly appreciate the services, because you are right that it's beneficial for both organizations and we want GNOME contributors to have the best experience regardless of the service they are using. However, I hope you understand our careful consideration on what steps we follow here, as we care about not putting the community in a position that would be difficult to go back from. This is specially true around branding, external services and official recommendations.

I don't see a reason why we couldn't make the IRC bridge performance ok with this requirements in place, so let's continue working on making that happen as we have been doing.



On Fri, 14 Feb 2020 at 01:00, Matthew Hodgson via desktop-devel-list <desktop-devel-list gnome org> wrote:

Hi folks,

Sorry for the delay in response here - the last 24 hours have not been fun.

Trying to address the main bits of feedback here:

1. The original issue that Michael Catanzaro reported (Matrix->IRC PM going missing) was a legitimate bug in the bridge.  The bridge is meant to display an error if you try to talk to an absent IRC user; this was fixed today and will be deployed tomorrow:  Sorry that you got bitten by this :(

2. In terms of: "We currently have loads of garbage IRC users in the channels after the bridge hosted at was replaced with one hosted at the homeserver." - I thought we'd cleared this up in the days following the migration, and this is the first I've heard of it still being a problem.  It sounds like the old bridge created IRC users on the Matrix side, and then the new bridge bridged them back over to IRC.  It should be trivial to kick out the old bridge's IRC users - please can you give me an example channel/room where this is happening to look at?

3. In terms of bridge performance: we set up a dedicated bridge and server for powered by back in April 2019.  The bridge got put live, but the server was never publicised because we never got a greenlight to announce its existence (plus the go-live was eclipsed by some unrelated security dramas on the homeserver).  As a result, the majority of users have been using the bridge via the public server, which is (unfortunately) often overloaded thanks to the exponential growth we've been dealing with.  However, if folks were actually using the dedicated GNOME server, then it would be an *excellent* experience - much like the one that Mozilla is enjoying currently.  It's worth noting that we provided the GNOME server for free because we want to support the project, but the running costs are significant - it's been very frustrating that the server has not been used.  (It seems that some people have found it anyway over the course of today, to quote someone in "OMG the IRC bridge is SO much faster on this instance.").  I'm hoping that we can get a greenlight to point people at the server, as right now the situation is indeed terrible and it's hurting Matrix's reputation as well as hurting GNOME :((

4. Mozilla *are* running their homeserver federated (as of this week) - c.f. They're countering abuse by using the arsenal of anti-abuse tooling we've been working on over the last year as per and etc.

You may also be interested that the core Matrix team is starting to look seriously at the work going on around Fractal, particularly around E2E encryption, to accelerate E2E encryption for Rust clients in general.  Specifically, we're porting pantalaimon (the Matrix daemon which offloads E2E encryption) from Python to Rust, and we hope that the resulting official E2EE-capable Matrix Rust SDK will be directly usable by Fractal and help the project along massively as a first class native Matrix GTK client (assuming they want to use it! :)

So, TL;DR: we've had a solution to much of the Matrix<->IRC problems since April 2019, we just need to actually use it.

I'm sorry this has taken so long to sort out - I genuinely hadn't realised that things were so bad.



On 13/02/2020 20:28, Carlos Soriano via desktop-devel-list wrote:
Hi folks,

We been in contact with Matthew from Matrix for some time already. I lately didn't have much time to invest on this, so we had have some delays on answering. However, it's our expectation that with the set up that we have right now the IRC bridge should perform as its best, as we are using servers from, the company that maintains paid severs with matrix services on them. We believe our set up is correct, but there might be some miss configuration somewhere, or the current situation it's already the best that can be offered.

We'll update you as soon as we have more information.


On Thu, 13 Feb 2020 at 17:16, Michael Catanzaro <mcatanzaro gnome org> wrote:
On Wed, Feb 12, 2020 at 4:15 pm, Britt Yazel <bwyazel gnome org> wrote:
> Attached is an image of the compact mode + dark theme. Just for the
> record.

The thing is, it really comes down to personal preference. I suspect we
have a lot of people who like web clients, and a lot of people who just
don't. With open protocols like IRC, XMPP, or Matrix, where lots of
client choice exists, you can use whatever you prefer. It's no problem
if you don't like any particular client because you can just use a
different one.

Myself, I like to see GNOME clients: polari, dino, fractal, chatty.
They look good next to our other apps, and vindicate the potential of
our desktop platform. But if we're going to have a web client, at the
very least do it using WebKitGTK, like Revolt does, to stick with GNOME
technologies and avoid bundling Electron.

I'll also suggest: whatever we use, it'd be nice to select something
with the potential to become a widely-accepted standard, like IRC used
to be. Chat has become a failed disaster area of fragmented walled
gardens, and when we have a choice between an emerging standard and yet
another silo, I think there's tremendous value in choosing the standard.


desktop-devel-list mailing list
desktop-devel-list gnome org

desktop-devel-list mailing list
desktop-devel-list gnome org
Matthew Hodgson
desktop-devel-list mailing list
desktop-devel-list gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]