Re: Matrix IRC bridge considered harmful

[Matthew Hodgson via desktop-devel-list]

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: 
https://github.com/matrix-org/matrix-appservice-irc/pull/978. 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 matrix.org was replaced with one 
hosted at the gnome.org 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 gnome.org powered by modular.im 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 matrix.org 
homeserver).  As a result, the majority of users have been using the 
bridge via the public matrix.org 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 #general:gnome.org: "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 Gnome.org 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.https://twitter.com/littledan/status/1227603567722319873 
. They're 
countering abuse by using the arsenal of anti-abuse tooling we've been 
working on over the last year as per 
https://matrix.org/docs/guides/moderation/ and 
https://github.com/matrix-org/matrix-doc/blob/msc2313/proposals/2313-moderation-policy-rooms.md 
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.


thanks,

Matthew


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 modular.im , 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.

Cheers,
Carlos

On Thu, 13 Feb 2020 at 17:16, Michael Catanzaro > wrote:


On Wed, Feb 12, 2020 at 4:15 pm, Britt Yazel mailto:bwya...@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 

More proposed release schedule changes

[Michael Catanzaro]

Hi,

We're going to release GNOME 3.35.91 next week. (Tarball deadline is 
Saturday! Please release your tarballs now!) Only problem is, nobody is 
really testing 3.35.90 yet, defeating the purpose of having the beta 
release.


A couple years ago, we've pushed our releases earlier just a bit 
(generally about two weeks earlier than we used to do) in order to make 
it easier for Ubuntu to ship our new stable release. (And Fedora, but 
Ubuntu ships slightly earlier, so it was the bigger driver behind that 
change.) My thinking had been that allowing distros more time between 
our .0 and the distro release date would allow for increased quality, 
since historically our .0 releases have not been as robust as we would 
like. (Note: I mostly focus on Ubuntu and Fedora because these distros 
align their release cycles to ours; nobody else is doing that afaik, so 
our schedule doesn't have a major impact on other distros in the way it 
does on Ubuntu and Fedora.)


Well, I'm starting to think this was a mistake. Quality issues with our 
new stable releases are longstanding problems, but for 3.34 we had a 
particularly rough time. I don't have a record of how many serious 
quality issue we had, but it was a lot; it took until 3.34.2 to resolve 
the most serious of the issues. Now of course we have more problems 
here than just the release schedule, but the release schedule is a 
contributing factor. Thing is, most testing of the new GNOME doesn't 
begin until Fedora branches from rawhide. Well, that happened earlier 
this week, so most testing is only just now beginning for the earliest 
of early adopters. Serious testing really heats up around the Fedora 
beta release. But 3.36.0 is going to be released a week *before* F32 
beta, so we're releasing before testing enters its most important phase!


Now, we don't have too much leeway to change the schedule without 
violating the bounds of our March/September release cadence, which has 
served us fairly well for a long time. So basically I'm just proposing 
that we switch back to releasing during late March/September instead of 
early March/September. If we were to follow roughly the same schedule 
for 3.38 that we did for 3.34, we'd probably release 3.38.0 on 
September 9. But I propose September 23 instead (which is in line with 
what we historically did for most of the past decade). That would move 
us two weeks later than we are now, which I think should allow us a bit 
more time to improve the quality of our release based on testing in 
these distros.


Now, Ubuntu's schedule isn't posted yet, but I guess October 15 seems 
like the likely final release date for 20.10 (third Thursday of 
October), and my guess is beta freeze will be September 28 (last Monday 
of September). That seems a bit tight, but our final tarball deadline 
for 3.38.0 would be September 19, so it would leave one full week to 
get 3.38.0 in before the 28th. Since we normally have three weeks 
between our .0 and our .1, that means Ubuntu wouldn't be able to ship 
our .1 regardless. The main difference should be an extra two weeks of 
bugfixing for the .0 release that does ship, so I'm thinking that 
should only improve quality. Ubuntu folks, please confirm if this 
should work OK for you.


Under this scenario, Fedora 33 beta would likely release with 3.37.91 
and a zero-day update to 3.37.92 available. I could wish for it to 
release with 3.37.90 instead, but I don't think it's possible for us to 
move 3.38.0 any later without causing problems for Ubuntu. Fedora 33 
will release with 3.38.1 regardless of this change (assuming we allow 
it in past Fedora final freeze, which we usually do).


Michael


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Matrix IRC bridge considered harmful

[Carlos Soriano via desktop-devel-list]

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 modular.im, 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.

Cheers,
Carlos

On Thu, 13 Feb 2020 at 17:16, Michael Catanzaro 
wrote:

> On Wed, Feb 12, 2020 at 4:15 pm, Britt Yazel  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.
>
> Michael
>
>
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Matrix IRC bridge considered harmful

[Michael Catanzaro]

On Wed, Feb 12, 2020 at 4:15 pm, Britt Yazel  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.


Michael


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Matrix IRC bridge considered harmful

[Michael Catanzaro]

On Thu, Feb 13, 2020 at 11:14 am, Benjamin Berg 
 wrote:

One could do this comparison properly. But it would need setting up a
private Matrix server for GNOME (possibly without Federation) and then
checking how well it holds up when compared to Rocket.Chat.


gnome.modular.im is already our "private" Matrix server for GNOME. 
Presumably there are no performance issues there?



___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Initiative Proposal: Chat communication platforms

[Link Dupont]

In the spirit of using modern tooling, please direct responses to the
discourse post on this topic.

https://discourse.gnome.org/t/initiative-proposal-chat-communication-platforms/2794

Link

On Thu, 2020-02-13 at 10:12 -0500, Link Dupont wrote:
> Hi,
> 
> We have been discussing the future of GNOME's communication platform
> for years now, and no real progress comes out of it, except for a
> further fracturing of our community. I propose we form a team of
> people, representative of different factions of the community
> (developers, system administrators, engagement & community
> outreachers,
> designers) that are tasked with identifying the chat platform that
> best
> suits our community's needs now, and in the future.
> 
> At a high level, I believe a process like the following may achieve
> this goal:
> 
> 1. Identify a list of acceptance criteria that candidates are
> evaluated
>against.
> 2. Request from the community at large for candidates, in the form of
>something similar to an RFP.
> 3. Review the RFPs against the acceptance criteria, identifying the
> top
>three candidates.
>3a. Identify members of other open source communities who have
> used
>the candidate platform and interview them for their
> experiences.
>3b. Identify members of the candidate's community who could aid in
>running evaluations and/or work through problems that come up.
> 4. Plan and schedule evaluation periods for the identified
> candidates.
> 5. Collect both qualitative and quantitative feedback about each
>candidate.
> 6. Review feedback and decide on a platform to use.
> 7. Create the platform launch process and migration process.
> 
> I volunteer to run this initiative and be on the team.
> 
> 
> Link
> 
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Initiative Proposal: Chat communication platforms

[Link Dupont]

Hi,

We have been discussing the future of GNOME's communication platform
for years now, and no real progress comes out of it, except for a
further fracturing of our community. I propose we form a team of
people, representative of different factions of the community
(developers, system administrators, engagement & community outreachers,
designers) that are tasked with identifying the chat platform that best
suits our community's needs now, and in the future.

At a high level, I believe a process like the following may achieve
this goal:

1. Identify a list of acceptance criteria that candidates are evaluated
   against.
2. Request from the community at large for candidates, in the form of
   something similar to an RFP.
3. Review the RFPs against the acceptance criteria, identifying the top
   three candidates.
   3a. Identify members of other open source communities who have used
   the candidate platform and interview them for their experiences.
   3b. Identify members of the candidate's community who could aid in
   running evaluations and/or work through problems that come up.
4. Plan and schedule evaluation periods for the identified candidates.
5. Collect both qualitative and quantitative feedback about each
   candidate.
6. Review feedback and decide on a platform to use.
7. Create the platform launch process and migration process.

I volunteer to run this initiative and be on the team.


Link

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Matrix IRC bridge considered harmful

[Adrian Perez de Castro]

On Thu, 13 Feb 2020 14:27:21 +, Neil McGovern  wrote:
> On Wed, 2020-02-12 at 20:21 +0100, Alexandre Franke wrote:
> > > My concern would be the "federal" nature of matrix where people
> > > don't need a
> > > gnome.org specific chat account to join a room. Whilst there are a
> > > lot of
> > > arguments for this I'm increasingly convinced it's an anti-feature
> > > especially
> > > if we want to enforce CoC (which, of course, we do)
> > 
> >  
> > That was a concern for Mozilla too. I don’t know the details, but
> > they have a solution for that it seems. See e.g. the Community safety
> > section in the [annoucement](
> > https://discourse.mozilla.org/t/synchronous-messaging-at-mozilla-the-decision/50620
> > ).
> > 
> 
> The solution they're using is federation turned off.

Mozilla has turned on federation on their Matrix instance just this week.

Cheers,
—Adrián


signature.asc
Description: PGP signature
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Matrix IRC bridge considered harmful

[Neil McGovern]

On Wed, 2020-02-12 at 20:21 +0100, Alexandre Franke wrote:
> > My concern would be the "federal" nature of matrix where people
> > don't need a
> > gnome.org specific chat account to join a room. Whilst there are a
> > lot of
> > arguments for this I'm increasingly convinced it's an anti-feature
> > especially
> > if we want to enforce CoC (which, of course, we do)
> 
>  
> That was a concern for Mozilla too. I don’t know the details, but
> they have a solution for that it seems. See e.g. the Community safety
> section in the [annoucement](
> https://discourse.mozilla.org/t/synchronous-messaging-at-mozilla-the-decision/50620
> ).
> 

The solution they're using is federation turned off.

Neil
-- 
Neil McGovern
Executive Director, The GNOME Foundation

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Matrix IRC bridge considered harmful

[Alberto Fanjul Alonso via desktop-devel-list]

The only reason I use matrix is that allows me to not loose any comment
while I'm not connected. If we can recover the IRC log not, there's no need
for it.

If we can log off to avoid people talk to ghost users that's another
improvement.

Hands up everybody that claim IRC is just perfect but have a personal
bouncer running 24x7!

Cheers,
Alberto

El jue., 13 feb. 2020 3:15, Christian Hergert 
escribió:

> On 2/12/20 4:15 PM, Britt Yazel wrote:
> >
> > If I remember correctly our conversation last month, you said you didn't
> > want a web browser open as it provided tabs to distractions. At which
> > point I mentioned the electron Flatpak (which contains no such tabs),
> > but you weren't having it.
>
> I share Nirbheek's viewpoint on this but also find the features that get
> added from having a browser engine to be disorienting. (Animated gifs,
> video, inline images, etc).
>
> The ability to disable all that would allow me to contribute without
> disorientation.
>
> I'm looking for minimal distraction, immediacy when present, high
> signal-to-noise ratio and the ability to walk away and come back later
> without loss of information.
>
> It doesn't have to be IRC.
>
> I would be extremely happy if someone had time to make Polari but on
> rocket.chat. The API at first glance doesn't look terrible, but someone
> needs to have time to take on that battle.
>
> I have enough battles already.
>
> -- Christian
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Matrix IRC bridge considered harmful

[Benjamin Berg]

On Wed, 2020-02-12 at 16:35 -0600, Michael Catanzaro wrote:
> On Wed, Feb 12, 2020 at 2:09 pm, Britt Yazel  wrote:
> > I have had horrible experiences with Matrix/Riot.im. I'm not sure 
> > which of those is due to the IRC bridge or which is due to Matrix 
> > itself, or which is due to the clients, but I really shouldn't 'have' 
> > to know the chat system at that level. My experience has been awful.
> 
> Here is my suggestion: fellow Matrix proponents, let's turn off the IRC 
> bridge ASAP. All we've accomplished by running the IRC bridge is 
> convincing GNOME devs that Matrix is awful. I'm pretty sure that all of 
> this negative feedback is about the IRC bridge.

Yeah, I also think most of the Matrix issues that people see are either
related to IRC bridging or that the public servers we rely on were
overloaded.

So, said differently, I would expect that anyone using a walled garden
Rocket.Chat instance (i.e. chat.gnome.org) without all that baggage
will have a great user experience in comparison. But, unfortunately,
that tells us nothing about which chat system is superior.

One could do this comparison properly. But it would need setting up a
private Matrix server for GNOME (possibly without Federation) and then
checking how well it holds up when compared to Rocket.Chat.


I have no idea which option is superior. And that can be a hard
question as it might even differ depending on whether your focus is on
e.g. short term experience vs. long term technical viability. That
said, I would love to see arguments here (for oragainst each chat
system) that I can compare in a useful manner.

Benjamin

PS: I had a nice chat with the Rocket.Chat person at FOSDEM who was
keen on getting IRC bridging up and running on their side. He said that
when I mentioned that Red Hat had experimented with it. If someone is
serious about this, I can pass on the contact.

> (We also need to fix the fractal bug that causes it to create private 
> rooms set to allow participants to view only messages sent after they 
> have joined the room. I guess fractal is sending the wrong permissions 
> enum value when creating rooms, or something similar to that.)
> 
> On Wed, Feb 12, 2020 at 2:09 pm, Britt Yazel  wrote:
> > So, the last thing I'll say is this. As a project that is trying to 
> > attract more users, many of whom are young, new to FOSS, and or are 
> > non-technology skilled professionals such as artists, designers, 
> > writers, etc, is Matrix really the best option? Or do you just want 
> > it to be the best option?
> 
> It's really the best option.
> 
> The problem with Rocket.Chat is that with only a web client, I doubt 
> very many developers would actually be willing to use it. (At least, I 
> don't think I'm the only one who would be hard no to a web client.) And 
> honestly I have no reason to believe Rocket.Chat will exist in five 
> years. Alexandre says it's another silo, rather than an 
> extensively-documented backwards-compatible protocol like Matrix 
> (although since Rocket.Chat is open source, I suppose it might be the 
> best walled garden among walled gardens). Rocket.Chat doesn't seem 
> designed to unify online communication in the same way that Matrix is, 
> and honestly without a desktop client I'd say that alone leaves it far 
> behind IRC. We need to select something that we can really unify our 
> community behind, something that everyone will like, not something 
> that's only going to be used by people who like web clients. In 
> particular, we don't want to wind up with one chat community on 
> Rocket.Chat and another on IRC, which is where we're heading currently 
> if we keep chat.gnome.org online.
> 
> Michael
> 
> 
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
> 


signature.asc
Description: This is a digitally signed message part
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Matrix IRC bridge considered harmful

[Tobias Mueller]

Hi,

On Wed, 2020-02-12 at 15:32 -0800, Britt Yazel wrote:
> Can you explain to me what the big issue with web clients are? I keep
> hearing over and over again that developers don't want to use web
> clients, either in browser or with Electron, but I don't recall ever
> hearing a "why" in there.
One of my reasons for disliking anything Browser-based is economic. It
takes noticeably longer to scratch all the bits of a Web browser off my
disk than anything else that has been tailored for the purpose.

A corollary is the gigantic trusted computing base. Not only do the Web
projects that I have to deal with pull in ridiculous amounts of
dependencies (most of which of questionable quality or reputation), they
ultimately also require a fully fledged Web browsing engine with all
bells and whistles. The number of lines of code used for some mundane
functionality as IRC is staggering.

And as big code bases tend to produce big binaries, we also need to have
a lot of memory to run those apps. I'm happy to be able to run my
Firefox and Evolution in parallel. I'm dreading to open any other
Browser-based thing because I know that my machine will start swapping
(yes, I do have swap space, because I sometimes I need to have Firefox,
Evolution, and something else running..).

So I'd rather have a bad Gtk (or "native") client than a good Web
client. Also because fixing Gtk-based apps is well within our skill set.

Cheers,
  Tobi


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Matrix IRC bridge considered harmful

[Tobias Mueller]

Hi,

On Wed, 2020-02-12 at 14:09 -0800, Britt Yazel wrote:
> this is not going to be an academically backed response, just my
> personal take.
> 
> I have had horrible experiences with Matrix/Riot.im.
Too bad you missed out on actually mentioning what your experience was.
So it's very hard to relate to anything you're mentioning in this
thread.

Cheers,
  Tobi

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list