We Switched to Mattermost

Note: you do need to flip the feature flag to try it out: Account Settings > Display > Collapsed Reply Threads (Beta).

I self-hosted a Matrix server for family chat reasons but the encryption key changes (Let's Encrypt) and frequent need to re-login became a hassle for me and the "membership group" at large. Tried out Discord, haven't looked back.

My mother-in-law even created her own Discord "server" (all done very easily in-app) with no help from anyone.

Very slightly worried about content not being in my control, but shopping lists, pictures of the cat being cute, and requests to pre-heat the oven aren't high on my snooping paranoia list.

That said, personally i use Rocket.Chat, which has been pretty easy to self host: https://rocket.chat/

I'm sure that someone who has experience with both could drop by and share their experience, but if nothing else, it's at least nice to have these options to choose from.

Either way, i can definitely confirm that most of these platforms indeed are very well off on smaller VPSes, as long as you don't have too much data in them (think file uploads rather than just messages).

Getting more support for something like that in the company that i work in, however, is another story entirely. For a while they tried Nextcloud Talk, but it was a bit too barebones: https://nextcloud.com/talk/

And ever since, sadly, there has been little to no interest in setting up another self-hosted platform, even if there are teams whose old messages are eaten away by Slack's limitations, the management seemingly having little to no interest in paying a bit of money for it.

Now that's an achievement I rarely hear, Here I am ostracized from the family and friends for not being in their WhatsApp groups.

Mattermost Team Edition is designed for teams (I.e. groups of people that work together and trust each other) and there were issues when Team Edition was deployed to unintended use cases—-like hosting hundreds of users, saving millions of posts, or other scenarios outside of what a team was meant to do.

Admin adviser was meant to help admins who hit those scenarios, and some of the advisory in scenarios Team Edition wasn’t intended to handle was for the Enterprise Edition. It sounds like that came across the wrong way and we should revisit.

Note: I think a fair chunk of admin advisor was paused a while ago. Not sure how much is running these days. Regardless we should take a look.

And now when you enter the system console, the very first thing you so is the Upgrade to Enterprise Edition CTA button. It concerns me that they'll keep pushing free (OSS) users towards the paid product. They've eroded some of our trust and given the choice we'd probably go in another direction in the future.

At the same time, if people are using our open source project to showcase their work, I am a fan.

We definitely do that ourselves talking about React, React Native and Golang :)

Can someone from Mattermost comment on that?

[1] https://github.com/42wim/matterbridge

On 1), our SaaS version is equivalent to our higher end Enterprise Edition E20 and aimed at larger orgs. For small orgs we have the open source version that can be easily self-hosted. That said, it sounds like price is material for you, so maybe there’s something we can do at a lower price tier, with features closer to our open source product.

On 2), Focalboard is still in its early days. We are using it internally and with early adopters of the open source version and are pretty excited about where it could go—replacing Trello, Asana, Notion, Jire, Confluence on-prem and as SaaS in the long run, and on an open source platform you can customize.

Our hope is in future there could be a “Why we switched to Mattermost and Focalboard” with a blog post on replacing a fair chunk of the collaboration stack with an open source alternative that could be extended.

https://github.com/mattermost

The clients though... whooo boy. Element is so bad that it hurts to use it. The worst part is that it doesn't have a singular major flaw, it has a hundred tiny issues that are just a bit wonky.

Really not sure about that. I work at an MSP/MHP that has infrastructure everywhere ( multiple DCs, AWS, Azure, GCP, OVH, etc.) and recently we had a huge network outage at a few of our on-prem DCs due to a firmware bug in some redundant networking equipment. Having the communications software "in the cloud" allowed collaboration on fixing and communicating about the issue.

Sometimes it's a good idea not to have all the eggs in one basket. In a similar vein, if your "on-prem" is dead, how do you access the documentation helping you debug/connect/etc.?

I worked on a couple of teams, and somehow no IT team could make the chat apps run reliably: we always had disconnects, terrible loading times, lost messages and we had to jump through hoops to enable the most basic integrations. No regular updates, outdated apps that are years behind in looks, features and integrations.

Whenever we just simply used Slack, it was snappy, reliable, and it was easy to set up connectors for different external services.

This means:

1. You limit your attack surfaces. Threats on your LAN, WAN or Internet can't communicate with the user computer or the server, e.g. they can't be landing points (attack surfaces) for malware or ransomware.

2. You isolate any damage In a full zero trust architecture, if one app is compromised, then there is no network for the virus to leverage to spread. For example, a ransomware loader can't call home to acquire more robust functionality, and can't find other data on your network to infiltrate and encrypt. This is because the loader is not on a 'trust' network in which it has access simply because it found its way into a network.

Other solutions are open to networks (large attack surfaces) and are susceptible to spreading attacks (as they spread through the 'trusted' network).

So one cannot use e.g. slack channels to shout to everyone about some problem. The usage pattern should be closer to email or an issue tracker with only involved doctors and nurses added to each patient or case. Email is of course unsuitable because of how easily information can slip out unprotected.

Unfortunately, doctors are people like the rest of us, use whatsapp and facebook to ask thousands of colleagues for help with their patients. Totally against the law.

It was easy to just whip up a Docker container with it with the help of our IT folks and then it's go time.

We managed to get the on-site license approved by appealing to the corp's high focus on security (the head of security was ex-military, so he was _strict_ about security). Slack would've been WAY too expensive to get approved.

All this before the penny-pinchers figured out that Teams would've been free. At that point Mattermost was integrated into dev processes everywhere and it was too late to move out.

But this is just UI candy, could be implemented in an IRC client too. From a protocol standpoint, what IRC really lacks is the consistent handling of chat history. I can imagine IRC handling this too; every registered user could always be "online" on the server, and therefore receiving all messages, and when their client actually connects, they would see the messages similarly how the IMAP works for email. But this is really reaching now, isn't it? Why not just use something that's similar in spirit, but actually updated to the moders internet, like the Matrix protocol?

Instead Slack & co add server side search and effectively turn company chat into a eternal meeting with random participants.

We go back and forth on whether we should have a .org and a .com, curious as to your thoughts.