@ara4n thanks for all the work you and your team are doing to respond to all feedback, it’s really making riot testing way more engaging and pleasant.
Sorry for opening a can of worms but, GDPR compliance, how are these three options facilitating this?
Edit: Answering myself
Avid Matrix and Firefox user here, obviously not that active a member of the community… I just wanted to point out a crucial difference between Matrix and the other options.
And that is, Matrix is built to be an open, federated network. If you have a Matrix server and allow it to federate, you can talk to anyone on any other federated Matrix server. You can use a single account to chat in a bunch of different communities… and you can self-host your own server and still fully participate in any chat on any other server.
This is vastly different than any other option.
The others are like AOL, Prodigy, CompuServe back in the day – you could send emails to other users of the same service, but in the early days you could not send to someone on a different service. Matrix is SMTP for chat – it lets you chat across networks.
Rocketchat was considering implementing Matrix to allow federation some time back – I don’t know if this is still happening, but the point is, with Matrix I don’t need to have an account for Mozilla, a different account for KDE, yet another account for the other open source projects – I just open Riot and can see all of them.
If you’re doing a closed, silo’d, non-federating service, the points in this thread are relevant. If you’re willing to consider an open chat system that invites collaboration across projects, Matrix wins hands down…
My opinion anyway!
Riot also have markdown support.
I would also add that there are several Matrix clients available too. And also that Matrix allows to bridge to several other protocols, including IRC, Slack, WhatsApp, etc. The IRC bridge works pretty well (I use it frequently). The other are a bit more experimental (didn’t try it, but that’s what I understood).
To make this more explicit, KDE recently adopted Matrix for its chat - https://dot.kde.org/2019/02/20/kde-adding-matrix-its-im-framework . If Mozilla does the same, you can participate in KDE chats using your Mozilla identity, and vice versa – KDE developers can participate in Mozilla chats using their KDE account.
That seems like a huge win to me… And not an option with the other platforms. (How many different Slack accounts do you have?)
… and, another entirely unmentioned feature, End-to-end encryption. Why trust embargoed security discussions to a proprietary service like Slack? With Matrix, you can have secure discussions for a security team, across servers, with no ability for server admins to reveal what is being discussed.
I feel that 1. it is a huge missed opportunity to not experiment
with Zulip, 2. a huge shame to consider a proprietary platform
that is Slack among the 4 candidates. It is still early in the game. The supposed IAM
feature depends on having SAML support, which is only ~100 LOC
away to have the feature implemented . I am not affiliated with
Mozilla or Zulip, but as a bystander I can’t bear to watch this
neglect to happen! I can help with the man-hour to implement the
That’s awesome. Gnome did the same recently. Would be nice if all the big names in the FOSS community (Mozilla, Debian, RedHat/Fedora, etc) also join Matrix.
I find https://chat.inkscape.org incredibly inviting because I have anonymous read access to a wide variety of interesting conversations going on about Inkscape. This inspired me to create an account and join in the fun.
In contrast, all the proposed chat solutions for Mozilla feel like a walled garden.
As per #synchronicity on moznet, Matrix (and Rocket.Chat too, i think?) both have guest access mode which can enable anonymous read-only access. For Matrix, it just needs to be enabled in the server settings in Modular.
We used Mattermost at Mozilla Foundation for a little over a year before the company migration to Slack. We had a lot of non-technical contributors for which IRC wasn’t an ideal candidate. It worked, but wasn’t a favorite compared to Slack.
Mobile support left a lot to be desired at the time, the apps were slow and buggy. It lacked some features and nice-to-haves that you might expect from a more mature platform. Not sure if that is still the case.
I will say, from experience it’s better to have everyone on one platform if you can - although understandably this doesn’t always happen. With the creation of the Slack there was a duration of a few months where contributor engagement was low because employees would understandably choose to just use the one platform. Which led to delayed responses increasingly as time went on.
Contributors ended up being folded into the MozFest Slack, and tied back into the official Mozilla slack through the #contribute-code channel. This seemed to be a good solution, it was never fully tested because shortly after was the transition away from learning products (phase out of Thimble, etc)
Good to know. @ryanwse do you happen to have the list of requirements that were considered when analyzing these tools in the past? It would helpful to frame some conversation here.
I love all three options for an open source code and I like it in the next order:
I think it is more personalized and have a installer to linux and app movil, i like it.
This remember a slack, i very like that has installer in gnu/linux but this is not too much necessary, i think. I don’t like that it isn’t very customizable.
In this I don’t like it too much but it’s not bad, mmmm i like this but it is no my favorite option.
Around 2016/2017, the Mozilla Philippines Community tried to have a self-hosted Mattermost instance. We abandoned the project because:
- Most of the local Mozillians are in Slack;
- Mattermost needs an above average server specs
In my opinion, Mattermost is the better option for us to promote FOSS and at the same time, adopt it as an organization.
After 10 days, here my impressions:
I’ve been daily testing the three options, but I have to admit that I stopped opening RocketChat after a few days, from my point of view its set of of features and UI seem too simplistic for the need we have.
Mattermost seems to have a nicer UI/UX and parity with known slack workflows, but I have to admit when you look a bit deeper, its back-end is not as flexible as I would like it to be. Being have to enforce our CPG and easily handle moderation is a must for me, and it’s seems mattermost is not specially strong on this one (no report, no moderation, no clear way to control a public space where random people will join).
Riot/Matrix initially looked like a less-advanced UI/UX as mattermost, but I have to say that the core matrix team have been collecting all our feedback and even implementing fixes in realtime. This has been a surprise to be and demonstrates a potential for further engagement in case we need paid-modifications to suit our needs. Simple theming and changing some defaults seems to be totally doable, and these were my only cons when talking about the web client.
When talking about backend, Matrix seems to be the most flexible and mature one, not only in terms of moderation tools and policy (which are really strong) but other things like potential federation and integrations.
I suspect a lot of people will provide feedback only based on the main clients UI, but I think that the minor personal preferences we might have can easily changed to fit out needs (specially in the case of riot).
That’s why I would recommend we go with matrix/riot and just understand the minor UX changes needed, since I’m confident the backend will serve us better in the long term than the other options.
I wanted to wait until I post my feedback, but I really couldn’t have done it any better than Nuke just did. I fully, whole-heartedly agree with everything he said.
Going to add more information about Mattermost, specially related to security.
Mattermost is really careless about deps in their project components having vulnerabilities, quick example:
The desktop client is not exception, I have done a few checks time ago and found deps with vuln not being taken care, and is being something that keeps happening from time to time.
Be sure to check the vuln record and how they proceed to deal with this type of issues, for example:
Hope this brings a different point to consider.
To avoid burying the lede, I’ll come right out and say Riot/Matrix is my first choice and it wasn’t close.
Disclaimer: I’ll admit I didn’t give Rocketchat and Slack the same fair shake as the other two. The former due to poor first impressions and lack of activity. The latter due to previous familiarity and bias (against).
In terms of the interface, I’d say Riot and Mattermost are a wash. At first I liked Mattermost’s interface better, but after spending a bit of time tweaking my settings I managed to make Riot look much more appealing and less cluttered. I learned that a lot of these settings can have a server default, so we can fix this for people if we want. But overall they both seem to tick most of the major boxes in terms of usability, and getting into the minor details here isn’t very interesting to me.
The main reason to switch away from IRC is to make it possible to fight abuse. And here Riot/Matrix seems head and shoulders above the others. One feature I particularly liked is the ability to mute users. This means if anyone is experiencing abuse either in channel or in direct messages, they can take matters into their own hands without needing to wait for an admin/moderator to step in. This feature didn’t seem to exist in Mattermost. Matrix also has a handy moderation guide. While I haven’t tested out everything myself, it looks like Matrix supports many ways to deal with spam and abuse. In contrast I searched the Mattermost docs for “ban”, “abuse”, “kick”, “moderation”, “moderator” but none of those came up with any relevant hits.
All that being said, the biggest draw to me is how dedicated Matthew and the Matrix team are to making this work. From standing up the moderation guide, to fixing bugs in near realtime to simply hanging out and answering questions. It’s clear they are dedicated and willing to support Mozilla (at least for the time being). It has been a very pleasant surprise and I think both orgs will benefit from the relationship (Mozilla gets support, Riot/Matrix gets a large user study). The interactions I’ve witnessed so far have made me confident that any problems Mozilla might have with Riot/Matrix will be taken seriously and addressed relatively quickly.
I have several other reasons for preferring Riot/Matrix too, though they aren’t criteria in the doc so I’ll just list them quickly.
- Read-only guest mode
- E2E Encryption (*not quite fully implemented in Riot yet)
- Open protocol / not a silo
- Federation. I know this was a non-goal, but being able to jump into the channels of other open source projects that we interact with (and letting them jump into ours) is useful. If we can enable this without making the moderation story harder, it would be nice to do.
- IRC / Slack bridges (I think Mattermost supports these too)
- Other bridges (not so relevant to Mozilla, but nice for individuals who might want them)
- Several clients to choose from
- Markdown (Mattermost also has this)
But even without all these extras, from my experimentation Riot/Matrix seems like the best choice for Mozilla.
I agree with everything @ahal said. Riot is also for me my first choice and Mattermost my second.
Here’s one thing I’d add that hasn’t been mentioned but I think is important for me.
An advantage with Riot is that they have a native app available for Android and iOS. The other chat platforms only offer a wrapper of their web version. I’ve tested the Mattermost one and it doesn’t offer a great user experience. Personally, the new platform should have a mobile app that is seen as a first-class citizen by their developers
Also, on desktop there’s a few native clients for Matrix that integrate well with the OS they’re targeting (e.g Fractal with Gnome on Linux). It also has a plugin for Weechat if you like terminal apps.
There’s also Matterhorn for Mattermost but the developers have no intention to integrate SAML/SSO connection and that’s a dealbreaker for me.
Matrix aligns with Mozilla Mission compared to other options we have, it is a open protocol that enables interoperability and federation, which is a must needed thing to improve the internet health in the current times.
Hi, everyone: we’re now less than 24 hours away from the shutdown of our chat system trial instances. Tomorrow morning - October 9th, morning Eastern time, and with little or no further notice - those machines will be shut down and permanently deleted . As much as I would love to leave these things spinning until it was time to announce the successful candidate, we’ve made a specific commitment about how user data would be handled on these services and we are going to follow through on that commitment.
We’re grateful for everyone’s participation and the feedback we’ve received so far, and we’ve learned a lot. If you have any information from those instances that you would like to preserve, you need to act on that immediately.
Again, thank you for all of your time, effort and feedback. I’m looking forward to the next steps in the process.