On Wed, 2020-02-12 at 16:35 -0600, Michael Catanzaro wrote: > On Wed, Feb 12, 2020 at 2:09 pm, Britt Yazel <bwya...@gnome.org> 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 <bwya...@gnome.org> 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
