Zulip Cloud security vulnerability with reusable invitation links

We use it at work. We first switched over to Mattermost, then to Zulip. Mattermost seemed like a clone of Slack and we were initially "satisfied", but didn't see it get improved that much nor noticed any attempts of it trying to tackle other problems. Then they raised their prices to even higher than Slack's, which we took as a bit of dick move seeing as we were self-hosting it + it has nowhere near the experience of Slack. Push notifications in general didn't seem to be that good.

Zulip has a nice spin on the way discussions work with their concept of "topics". It lends itself well to how we conceptualize the discussions across our development teams, without unnecessarily creating many ad-hoc temp channels (something we'd have done on Slack). We're liking it thus far. That being said I do need to check why it's using about 35 gigs of RAM on our server.

35 gigabytes?! How many people are using that thing?

We use a self-hosted Zulip. It's the first chat system to make everyone reasonably happy -- devs, IT, customer service, and most of the execs.

Personally, I like Zulip way better than Slack because of how it does message threads: _channels_ that have conversations in _topics_ "makes sense" to me.

Pros: Server maintenance is blissfully minimal. Message threading that actually works. No server issues or downtime in the past 4 years. (Every time I see a HN "Slack is down" posting, I smile to myself and continue my work day...) It runs great for ~50 employees on an AWS t3a.large instance. Importing all the company's previous messages from Slack worked perfectly.

Cons: If you have people used to Slack, there will be resistance / a learning curve. Knowing, "when do I create a topic?" takes practice. The mobile and desktop apps are not as polished as Slack's. Not as many integrations as Slack. You have to know enough to manage and secure a server yourself.

The Zulip devs accept Github donations, btw, if anyone cares to support their work. (We do; no affiliation other than we're happy to have a private, self-hosted alternative.)

edits: punctuation and adding that instance was a ".large"

We used Zulip at $job[-1] and it was awfully painful. I’ve used nearly every chat client invented since the BBS days, and Zulip was one of my least favorite. We’re using Slack now at $job and I vastly prefer it (even though I still call it “IRC”).

The biggest selling points of Zulip, from the POV of the people who put it in place and truly loved it, were that it’s free/OS software, it has explicit threads as a first class citizen, and that it’s very configurable. All those things are true.

The day-to-day use was painful, though. It was riddled with UX problems, e.g., forgetting state between restarts, inconsistent hotkey support, multi-action use paths for common cases, frequent full reloads of its web view. I’d much rather use vanilla IRC than Zulip.

Slack is just enough of a shim layer on IRC, and with good usability. It has threads, and in use it’s not a problem that you can’t name them like Zulip. The integrations are nice to have (e.g., type `/zoom` to start a Zoom meeting) but not a big deal. The UX is clear and predictable and (mostly) stays out of my way.