Mattermost has no threads either. RocketChat just implemented them in v3.4. Zulip has its own concept of threads, but Zulip frightens non-dev users in my experience.
Invisible scroll bars keep making me miss new messages just because indicators were out of the viewport. Having the browser stall routinely causes full reloads (after a delay, making it more annoying), then the reload is invarialy interrupted by the server due to request overload. Not to mention that the reload is slow already. Long messages show up collapsed, and uncollapsing them often devours whatever text was in the input field, an especially useful feature when trying to write a thoughtful reply cross-referencing multiple posts. Email notifications send out the same message multiple times, and presents author's name the same way as the rest of the text. Constant hitting on the CPU. Confusing notion of threads and forums. I could go on - Zulip is not nice.
It's software with many moving parts, it uses PostgreSQL, Redis, memcached (!) and RabbitMQ (!!). That's at least two more than you'd expect. All these have completely different cluster architectures. Point in time backups isn't trivial either. This makes things like HIPAA requirements harder to implement.
The official way to install it is to run a sprawling Puppet manifest, which is dependent on a number of other tools to do the work. How do I store this in an existing configuration management system? How do I connect to existing databases? Those DBAs were hired for a reason. The documentation on that is less than ideal.
You'd better run in on the recommended Ubuntu version, any deviations will cause the above procedure to explode into a ball of mud.
There is a Docker image, but it's not stable yet, and upgrades become a bit unclear. It would also mean running all those databases inside a K8s cluster, again with their own ways of doing clusters, backup and maintenance.
The kind of organizations which needs to run things on-prem, and will glady pay for the privilege, are also the kind of organizations which have streamlined processes, sysadmins and DBAs and there Zulip isn't a great fit. It seems to be decent software otherwise with some great and unique features.
-Zulip lead developer
Like how do you store a thread to find it later—loudly announce the subject in as much detail as possible with a “SUBJECT:” index prefix? Deep link to put in your wiki and hope slack actually honors those links in a year? Is slack search usable yet?
I've found the anti-thread arguments to be pretty weak.
We’re very excited about it and are currently testing prototypes with the Mattermost community and some customers, with development starting soon after.
We'd love for you to join the Folded Reply Threads channel (https://community.mattermost.com/core/channels/folded-reply-...) on our community server as we share progress updates and gather feedback.
I can also confirm Mattermost has threads, which are likeable but a bit confusing.
Would you be open to sharing them in our feature proposal forum (https://mattermost.uservoice.com/forums/306457-general/sugge...) or join the Folded Reply Threads channel (https://community.mattermost.com/core/channels/folded-reply-...) on our community server?
> SaaS
that's not really a saas though.
a managed services offering maybe, but that would be a differend type of business.
The SaaS offering means that smaller organisations can also get come onboard without going to extra expense of a large scale self hosted installation.
if i want to move my company from slack to element - can i have permissions at the company level (all rooms in a company) and on a per room level ?
We do have support for org wide management in the form of the Communities feature, but we want to completely revamp it to make exactly what you are describing easier. It is the next big thing on the roadmap and I would expect it land in the next few months.
But if you are willing to somewhat alter it, I am sure it'd end up with a overall better setup.
I'm old enough to remember the days when you could use a single client to communicate over many networks. Proprietary protocols are the reason that's not possible anymore, and I sincerely hope that every single company peddling them goes out of business.
It's not simply a chat service. You also have proxied video calls and VoIP. That in itself is far more expensive and resource heavy than decentralized hosters can do at scale.
It's not about proprietary protocols, it's that we already had decentralized solutions that cant protect it's users. Centralization is a requirement at that point if you want it to be popular and scale.
I do appreciate E2E encryption for some narrow use cases, but it is not the end-all-be-all.
Such an arrangement is more or less what happens with key escrow, a feature which I believe at least one self hosted cloud stack offers (sorry I can't remember its name off the top of my head).
Element (formerly Riot), Discord, and Slack are all irc successors; Signal, Whatsapp, and Snapchat are sms/mms successors.
The differences used to be desktop vs mobile, primarily [semi]public group/community chats vs primarily private 1:1, and realtime with presence vs async. As technology has advanced, the differences have shrunk. I'd say the last real remaining difference is that the irc successors have named channels with granular permissions and static invite links, while the texting apps might have a group owner but otherwise give everyone full permissions, and people are usually added directly to the group (not invited).
In short: the texting replacements are geared towards communication with friends (ie, based on who you're talking to), while the irc replacements are geared towards communication, possibly with strangers, based on what you're talking about.
So that's a combined population of ~4,8 million, which is only about 5,7 % of Germany's total of ~ 83 million...
