Zulip 2.0: Open source team chat

> I find it helps us have real discussions, as compared to other types of forum (and I've tried a bunch).

Have you tried a modern forum, like Discourse? I'm trying to understand why many open source projects opt for chat platforms instead of a forum. Why are you resignating public and search engine accessible discussions?

Linkability is a really big deal. You can get it with IRC if you keep public logs, but getting a link is definitely harder than if you have a fully-integrated system like Zulip, as there’s no standard way for the client to sort it out.

At FastMail with our group email system Topicbox, we put a link to the archives for the current email in the mailing list footer, and that’s the favourite feature of quite a few of us in the company, and we’ve heard similar from our customers too. (Not sure why Mailman doesn’t do this, it’s super useful.) This gets around the need for a single frontend. Something IRC-like could work that way if each line sent included a URL, e.g. in JSON {"speaker": …, "url": …, "time": …, "text": …}. I have no idea at all if the likes of Matrix can or do work that way.

You get bonus marks on a feature like this if it includes meaningful content in the URL, e.g. Zulip’s URLs, although a tad ugly, include the stream (a slug) and topic (slightly weirdly encoded rather than slugified, but still present and readable). That way I can look at a URL and have a fair idea what I’m getting myself into. (URLs are definitely UI.)

Interesting idea; it's not something I'd thought about. I definitely figuring out what SMTP server to use is the hardest part of Zulip server setup, and I had believed there was nothing we could really do to make it easier. I guess the concerns I'd have are:

* Do people running on-premises actually want us to be an intermediary for all the emails their Zulip server is sending? I would imagine if they were happy with that, they'd be happy to just use Zulip Cloud.

* How does 3CX avoid this service requiring them to do a bunch of anti-spam work?

I do believe that the SourceHut project is investigating ways of simplifying the process of self-hosting email, for the purpose of using it to power a self-hosted forge platform. I feel like there's a decent chance of a large overlap in needed features and goals. The SourceHut folks are highly reachable on Freenode in #srht and other places.

Yes, there are several major things planned (in addition to the fact that every release touches dozens of smaller UI things; you should see what the Zulip 1.3 settings UI was like!). A few notes:

* There's active work on replacing the top-navbar/search area with something nice and clean that displays the stream description, number of subscribers, and other details.

* Our current visual density is really good for power users, but . zooming to 110% makes some people a lot happier and makes Zulip look more modern. We're working on changing the default visual density to look more like that, while leaving the current styling as an option for power users.

* You should try the night theme (in "display settings") -- a lot of folks who are picky about design prefer that one.

Thank you for voicing this concern. There is something satisfying at a deep, almost visceral level about Slack's UI/UX (whatever else you think about it's ability to search/organize information). As someone looking for alternatives, it makes the transition seem very jarring because almost nothing looks as good.

I'm trying to convince a team to go to Zulip but the design adds an extra roadblock which makes it just that much more of an uphill battle.

I was part of the un-slacking task force at my previous job. We gave Rocketchat a test run, but ultimately decided it was just a less-polished Slack. We also took Twist for a spin, which I really enjoyed. However, our support department relied too much on real time chat to abandon it completely. Zulip was a really nice compromise that I highly recommend.

If every Slack post had to be either the start of a thread or a reply to a thread, you'd basically have Zulip. The hardest part is conditioning everyone to use good thread names and not establish topics that are overly broad or narrow.

I think better would be just to try both and let the team decide. 1-2 weeks each.

We have migrated from HipChat and 1st we tried was Stride then Zulip, where we stopped.

Main complaints regarding Zulip were (are) Windows client not stable, UI a bit clunky.

Since you mentioned 100% remote, don't you think Zulip has advantage over other chat apps because of the asynchronous nature of conversations? Zulip team is also fully remote. We have core team members in North America, Europe and Asia all using solely Zulip for communicating. We don't do video/audio conferencing. All most all the decisions are made via text chat thanks to the wonderful asynchronous nature of Zulip threads :)

Zulip also has a terminal client.

There are pretty serviceable native GTK and Qt Matrix clients nowadays.

Not yet. https://github.com/zulip/zulip/issues/3618 is the issue for it if you'd like to follow it.

Oh god, that's terrifying. Then I'll see "Why haven't you read my message? Why are you ignoring me?" all the time :(.

Probably one of our users can better to attest to this than I can, but it's really easy for someone with that background to maintain. For installation, we've put a ton of effort over the years into making all the commands Just Work if you copy-paste them, adding custom error messages if you run something as root you shouldn't, etc.

And we put a ton of effort into making the upgrades, even for major releases like this, be a single command that Just Works for almost everyone.

I know this because I personally respond to every single report of issues installing/upgrading Zulip and have been making changes (even if the issue is basically user error) after most of them to help ensure they don't happen again for a few years now.

That said, if you don't want to deal with doing that work, Zulip Cloud is very reasonably priced for situations where all the users are employees (compared to payroll, it's effectively free) and for other use cases, we have steep discounts (e.g. free for open source, a huge discount for education, etc.).

As a test about 6-7 months ago I set up a Zulip server on a VPS to test it out. Because it was a test I can't speak to scale, upgrading, or maintenance, but I would hope most any VPS would easily support ~30 users. The install process was unmemorable. I just had another look at the docs because I couldn't remember the process was. This is probably the best endorsement that can be given because the worst-case would be hunting down dependencies and having to compile stuff and tweak config files and it taking up most of a day or two. Instead, it was probably less than an hour from going to my vps' website to provision a new server to logging into Zulip from the client on my phone. I don't see any reason not to try yourself.

I'm not sure of your proficiency, but if this is a public-facing server you may want to either go with their paid service or hire someone to do the initial setup and walk you through maintenance since there's more to securing a server than just installing and getting it working.

I believe it's the second :). (All replies from a channel go into a never ending thread that goes on forever.)

iirc there is a server side setting to disallow messages without thread.

I run a Discord server and this drives me mad. Since Discord doesn't have threads, everything is in the main chat. I know for a fact I'm going to die by being buried in notifications because people can't wait 1 minute to type a response, they need to send each half sentence on its own. Meanwhile, all of my statements appear late because I've taken the time to put the entire thought into one message.

I've heard Zulip is much better about threads, but in Slack there are some annoying things about them. Everything is crammed into the sidebar, so reading log snippets suck. Also, I noticed people will often post their initial message, then a @here with slightly more info in the same channel. I'm not sure where to begin the thread from. I haven't been able to intuit the rules for alerting people or uploading things like images into a thread.

> They litter the stream by making sentences instead of paragraphs.

You may find this old conversation amusing:

https://news.ycombinator.com/item?id=11239614

> What I don't understand is how could Slack not see this as an issue?

Similar issues exist in email communications. I feel like these are really more just issues with the person's ability to communicate. Perhaps the technology can help, but I'm having trouble imagining how.

Unfortunately, I've tried to educate some of these types of users that I know (e.g., showing them that Slack's formatting options exist, are easy to use, stop quotes from randomly getting turned into smart quotes), but IME communications skills are one of the last things people are willing to accept feedback on. I find it often just gets acknowledged "oh, that's great, thanks!" and then promptly ignored (no change in behavior).

We did recently improve how notifications are delivered on Android, about 1-2 weeks ago. Keep an eye on if you are still having issues, I hope the delay is resolved.

I haven't found this a problem. We tend to just have general topics, like very often the "what's everybody working on this week" topic.

you don't have to use a topic by default... another option is to have a default topic like `general`

This is a common confusion from folks who haven't really used Zulip. You don't need to think about the subject for every message, because 95% of messages you send are replying to an existing message/conversation, and you don't need to think about topics to do that.

For those messages where you are effectively changing the topic of conversation, in Zulip, rather than starting your message with "On another note," or a similar phrase to communicate that you're about to say something unrelated words, you instead just send your message to another topic.

And if there are multiple conversations happening at overlapping times, Zulip's model often ends up saving you from having to say "@fred yes" in your reply to indicate which question you're answering "yes" to, because it's obvious from the structure.

You can argue it's slightly more work for the person sending a message to type a topic when you bring up something unrelated, but it's certainly not much, and it's only relevant to a small fraction of messages that one sends. Whereas what Zulip's model saves your organization is every one of the N users who can have to read the conversation needing to spend much more time and mental effort in order to understand what conversation(s) happened while they weren't looking at chat and whether there was something that needs their attention.

Having hundreds of messages with no way to tell them apart is an absolute nightmare. Zulip doesn't require a subject for every message, but it does impose some discipline, and that's a good thing.

I am a newbie in this area, but could Zulip use machine learning to come up with a relevant subject or topic name? I am not sure how it would work though, since it might be required BEFORE you send messages, and you may not want to change it frequently after that, because people should not memorize the changes all the time, it would backfire I think.

But still, does it make sense in any way that I cannot think about right now?

You haven't used team chat for work? Then, things tend to happen chronologically, like, step by step problem solving, or doing something together. In such situations, it can be more important to find the most recent comments, than to find any "best" comments.

It's about what matters most: Knowing what's happening right now, what everyone is doing, what one is supposed to do next. Then, chronological team chat. Versus finding the best comments, e.g. when discussing a news article, or pro and cons about an idea.

We were using Slack at my last job, and it was great (now I don't like Slack any longer though, not after they added their weird threading. I like Zulip instead). Slack & Zulip = good sometimes, HN = good for other things.

We actually are working on a one-click Digital Ocean installer right now!

See https://github.com/zulip/zulip/pull/11622 for the code; it should be in their marketplace in a few weeks.

That said, if you make just a Digital Ocean VM and run our install script, it'll Just Work and you'll get the same experience after like 10 minutes of non-interactive installation.

https://zulipchat.com/help/moderating-open-organizations has some of that info. Zulip doesn't have IP-level banning or moderation tools (at least not at the organization admin level; maybe you could hack something together if you were self-hosting).

We make heavy use of threads in slack for anything serious at my work. #general and #random are a mess of course, but that's kinda their point.

So, philosophically, as a former MIT cryptography grad student who spent a lot of time in Ron Rivest's office, I'm unwilling to offer a cryptographic guarantee like "E2E encryption" if it doesn't actually provide the security guarantees that any reasonable user would expect when they heard that phrase.

Zulip encrypts all content in transit using HTTPS, which protects against a pretty wide of potential attacks to the privacy of one's messages. We put a lot of effort into ensuring messages aren't sent to the wrong users (one surface-level detail here is that our backend codebase has ~97% test coverage; which becomes 100% for views, validation, and other security-sensitive code).

The big thing that these techniques don't protect against which E2E encryption is supposed to solve is a malicious/compromised server accessing message content. But I'm also not convinced there is a viable solution supporting desktop+web+mobile+terminal apps that can prevent a malicious/compromised server from getting access to message content.

Just to highlight one of the issues, if you're using a webapp, the server itself is what tells your browser what code to run. So, if the webapp can display decrypted message content in a browser, a hacked server can just deliver JS code that causes the browser to fetch every single message of history your browser client has access to and send them back to the server unencrypted. I've thought at times about whether a trusted browser extension could help, but I don't think it can. I imagine the various "E2E encrypted" apps address this issue by just not offering a webapp.

Even if one were willing to abandon having a webapp for this feature, the really hard problem with doing E2E encryption is key storage and distribution. What process do you need to use to move your secret key between different devices safely (or do you just lose access to your history when your phone dies)? How do new users who get added to a stream get the secret key for that stream? Maybe there's a Keybase integration that would solve this (I actually have exchanged a few emails with the Keybase team about this concept).

e2e encryption is an anti-feature for many. In places where an internal team chat is needed (i.e. companies), the ability to log and audit conversations is a requirement. I agree it might be nice if it was optional, as long as it can be disallowed globally by a server-side setting.

Lots of feature/change requests.