Zulip 1.8: Free software Slack alternative with email-style threading
blog.zulip.org
blog.zulip.org
The threading, which they sell as the core feature, is nice, and does make it more usable for "important" conversations than purely chronological chat. It also makes it easier to screen out conversations you don't care about.
But IMO the killer feature is the "all messages" view that merges chosen streams in more or less chronological order. It makes it much easier to keep up with what you care about asynchronously without throwing everything into a single stream. And therefore it is easier to put down, and to use notifications very selectively, which mitigates some of the major downsides of company chat.
I haven't used Slack recently either, but as I understand it its "all unreads" feature is much clunkier.
I haven't used a recent version, but I would definitely consider using it again.
Me too.
Back on topic, I really enjoyed Zulip as well. It wasn't perfect, but it very much did feel like they were actually getting the marriage of email and chat closer to right. Slack just feels like a shitty chat client that uses all of my RAM.
Before Zulip we used XMPP for a long time, then Mattermost for a short time (the threading model in mattermost didnt work at all for us), then moved to Zulip and never looked back. I definitely recommend Zulip.
It also supports markdown.
You can try it at chat.zulip.org
Does anyone have experience how this compares to the threading in Flowdock? I like their threading the best between the ones I've tried, but it doesn't allow you to skip or hide threads that aren't useful to you.
I'm still somewhat baffled by Slack's popularity as it's almost as bad as IRC on larger groups.
Is there _any_ service with Flowdock style threading now? XMPP clients? Game chats?
They've added some handy features, and there are more in the pipeline, but the current mobile experience is so bad that I'm having trouble not looking at alternatives. This despite the threading and content model (inbox divorced from chat is amazing) that has kept me very loyal for a very long time.
The fastest way to find out how it works is to go to https://chat.zulip.org/accounts/login/ and click "Log in with GitHub". They really need to make that path easier to find.
That said, https://zulipchat.com/features has a screenshot; and https://twitter.com/b0rk/status/986447131421609985 does a pretty good job of explaining the concept. And https://www.recurse.com/blog/112-how-rc-uses-zulip explains some of how Zulip's model can make a big difference in how an organization communicates.
(I'm the Zulip project leader and wrote the blog post)
I couldn't care less for any other links, because they: are on some other sites that you assume are discoverable by magic.
Now imagine a person who has used Slack, and has never seen your app in their life. They arrive at your landing page. What are the incentives for such a person to download the app? Generic marketing-speak?
Just a quick question... How difficult is it to build, install and run from source? I guess I'm slightly concerned about the "it expects to have the whole machine" in the requirements section. Is that just for your installation scripts, or are there assumptions baked into the server? (Apologies for asking without looking myself!)
Making that build process super easy (if it isn't already) might lower some barriers for the technical crowd (personally I don't like setting up VMs... maybe it's just because I'm old :-) ). Possibly you can leverage more from your free software angle.
In the Zulip development environment, you can build your own release tarball with `tools/build-release-tarball`. Or you can just clone the Git repo and run `scripts/setup/install` directly (similarly, you can use `scripts/upgrade-zulip-from-git` to upgrade to any Git ref, which is great for running a pre-release version or a small fork).
The "expects to have the whole machine" story is just that we need to configure third-party services like nginx, postgres, redis, and memcached, and it's very hard to write configuration for all of those to support Zulip that doesn't carry some risk of breaking an arbitrary third-party app that might have been installed first.
The "world's most productive" phrase is doing you no favours, by the way; it's substance-free marketing hype. It gave a slimy first impression that I had to fight past to try to find out what Zulip was really about. Show, don't tell.
1. https://chat.zulip.org/register/
2. "Sign up with GitHub"
3. "Authorize zulip"
4. Got redirected to "Sign up for Zulip" (https://chat.zulip.org/complete/github/?redirect_state=...)
5. Went to https://chat.zulip.org/ and
6. got redirected to https://chat.zulip.org/login/
7. "Login with GitHub"
8. "Zulip account not found."Why is it so difficult to take some screenshots and put on them on the homepage and/or features page?
The second time (about 3 years ago), I had to convince them that team management and selective sharing were necessary and that we should upgrade to a paid software. This took several months to get approval on, even though it's only like $400 a year for us; thankfully management seems to agree that it is worth the costs now.
To be fair, I don't consider myself very persuasive so it's entirely possible that I just did a really poor job of it.
P.S: I'm trying to create a community for "Bored Hackers", and you can check it out here and say hi! (https://spectrum.chat/boredhackers)
That said, what Zulip lacks right now is polish. Server installation for example is a mess. You basically need a dedicated Debian machine to install it. There is a docker image that I'm using, but it's rather unstable (if I will have to make changes to the configuration, I fear I will have to spend hours trying to fix it). You also NEED to have a SSL certificate which means that testing in a local network isn't as painless as simply installing the server. There's also problems with the search function (it barely works), lacks things like archiving topics (or hiding them), enabling app notifications using their Google Play App requires you to send them an email and a few other things. Their apps also feel sluggish. They have an old Cordova app that is slowly losing compatibility with the server and a new app that is fairly slow. The desktop app is an electron app and it also has some issues.
Thankfully issue reporting is fairly painless.
* Needing an SSL certificate should not really be a barrier. We now have an installer option to use Certbot which works great if you're on the public Internet, and if you're not, we have simple instructions for creating a self-signed certificate.
* Zulip has never had a Cordova app. I assume you're referring to the [legacy Android app](https://play.google.com/store/apps/details?id=com.zulip.andr...), which was written in Java (and is deprecated in favor of [an RN app](https://play.google.com/store/apps/details?id=com.zulipmobil...) which lets us share most of the hard work of mobile development between Android and iOS).
* I'm surprised by your comment about search; we often hear from users that they love Zulip's search. Can you open an issue with more details about what you're seeing? I'm wondering if e.g. search is broken in the Docker image.
As a sidenote, for the Electron desktop app in particular, all the performance issues that we could reproduce went away with the latest update (not because we changed something in our code, but because we upgraded Electron which had upgraded Chromium to a newer version with fewer performance bugs). If you're still seeing issues with app version 1.9.0, I'd love to see a profile captured from the app's developer tools.
Zulip was started as, and basically still was last I used it, a modernization/web-ification of the BarnOwl[1] curses/terminal client for, mostly, MIT's (and CMU's, inter alia [2]) legacy Zephyr[3] IM protocol. (though BarnOwl also has support for XMPP, IRC, AIM, and Twitter). MIT students who were into the zephyr community also tended to like the interleaved-thread with option to narrow to specific filters view. The Subject part of threading comes as largely an accident of Zephyr's implementation[4]
Zulip was acquired by Dropbox in 2014: https://techcrunch.com/2014/03/17/dropbox-acquires-zulip-a-s...
and subsequently open sourced in 2015. Zulipchat.com is a second company formed around Zulip by (OP) one of the original founding members of the pre-acquisition company to (I'm speculating) keep the project healthy and active and give people a hosted option. It is not primarily aggressively pursuing market share, capitalization, etc. That is why it doesn't like price aggressively to compete with Slack, etc. as someone EIT was confused about
I took the time to spin this out from memory, etc. but then I found it was mostly covered (or if you prefer corroborated) here: https://zulipchat.com/history/
Anyway its a good model for organized communications once you get used to it and I'd recommend it if you are in a small enough company/team with enough latitude to experiment with such. It would also be cool to see a decent large public instance as an alternative to ~Mastadon
[2] https://www.quora.com/Where-are-some-places-the-Zephyr-messa...)
[3] https://en.wikipedia.org/wiki/Zephyr_(protocol)
[4] https://stuff.mit.edu/afs/sipb/project/doc/izephyr/html/node...
Slack's threading model is much worse than Zephyr/Zulip's IMO. Especially on mobile. The streams/topics flow in the "all conversations" view is an incredibly intuitive way to keep track of everything that is going on.
Want to find alternative to Slack for open source project since restricting they apply getting annoying and it's would be nice to have single point of registration after all.
It's also probably not super hard to just add a direct authentication backend for Discourse.
Though if we want to have little customization like that does it mean we'll absolutely need to host it on our servers or something like that possible on hosted plan?
PS: Obviously I get that If I manage to push code upstream hosted option will support it, but I suppose it's might take a while.
So if you do it in a way that gets merged (which requires, e.g., automated tests appropriate for an authentication backend) and is configurable for just one organization in a multi-organization server, you would not need to host your own servers.
The first intriguing thing I found was this product is owned by Dropbox.
Slack eating into Dropbox's territory with (decent) file sharing / searching and Dropbox countering with a alternative chat/ threading app is a nice battle.
Anyone got experience with both?
I really thing people are taking this GDPR thing WAY too seriously. They are really only going after the obvious abusers, IMO.
banning users via subnet, hostname, cidr?
These are the things I need in a chat replacement.
I've discussed possibly funding these things for riot / matrix not sure I can afford it, but I know I can't afford not to have these kinds of options in a public chat system.
looking at the features, I'd need a way to have the server download any images / attachments, check for viruses, strip any exif data, before showing preview to the room. (evil actors host an image on their server, post it to the room, and bam they have everyone in the room's ip addy, at that point everyone's router had better be updated.
Looks interesting, and I am looking to replace a java / flash chat system from a decade ago that is yet to be beat sadly.
Zulip's threading is based, more like email, on a Subject which all messages (can) have. Though Zulip subjects are more likely to be one or two words.
In this way threading is tacked on to Slack whereas it is as at the heart of Zulip
ORDEREDSUBJECT
The ORDEREDSUBJECT threading algorithm is also referred to as
"poor man's threading". The searched messages are sorted by
Yes, the REFERENCES algorithm also uses the base subject--but never to override message-id based threading, only for merging together threads that couldn't be joined using message-ids ... or in other words: as a workaround for garbage email clients and services too incompetent to use email correctly.
Well, and for merging together chunks of a thread where you have major gaps in your mailbox, so that reference headers don't overlap enough to make the connection, but the point remains that it's not really a threading mechanism, just a last-ditch attempt to recover a thread where proper threading information is missing, which is fine for corner cases like large gaps in which messages you have in your mailbox, and doesn't change that a sender that doesn't supply reference headers in the first place is incompetent.
In zulip every message belongs to a topic. (Well there is the "no topic" topic, but it shouldn't be used and even if it is it appears exactly like every other topic). So no surprises.
I have used slack (and irc and xmpp) for a long time, and Zulip for 2 months. Zulip is certainly much better for the geek.
Slack user experience is somewhat more straight forward for the naive user not caring about things done "right".
For hacker news readers zulip is likely to be the preferred choice. Expect resistence from your non hacker news colleagues / managers / team members.
Is threading such a big deal that people can't live without it? I honestly never found it useful.
Slack is positioning itself as an email replacement, and to some extent all of these tools are replacing at least some email. Imagine taking 20% of your email and not having subject lines, just authors. What's the "LGTM" for? (Or worse, the sender anticipates that and says "Re @pm at 00:10, agreed" and then you get to track that down.) Or imagine taking your in-person conversations, the ones that you'd eventually want to move to IM to support distributed or remote teammates, and having a rule that you couldn't go up to someone's desk, instead every in-person conversation had to take place at this one water cooler. If multiple people wanted to talk, well, either they can have multiple conversations in front of each other, or they can wait until one conversation is done.
(Slack's implementation of threading, meanwhile, doesn't actually solve the problem that well because of the way it pushes threaded conversations to a side. Imagine email without a reply-all button - it solves some problems and creates so many others. You can and should live without Slack threading.)
... also, another argument that threading matters: you're using a threaded forum right now. Remember phpBB? Would HN be improved by switching to a phpBB-style UI? If you unindented all the comments on this page and sorted them by time, would it be a workable experience?
It's a filtered event stream, where you have 2 tags, "chat room" and "topic". You can see the full firehose with both tags, or zoom in to a room and see topic tags, or filter to just the topic if needed. Slack won't give you the first option, and does the second poorly since you can't see the topic responses inline.
Slack sells itself as a searchable archive. Ideally if someone asks the question a second time, they (or someone else) can look up the answer. Direct messages mean conversations don't get publicly logged, which is a serious negative for the company.
> Also if you have some specific topic you would like to discuss like k8s or linux there should be specific channels for that in a company.
My company has three channels for GitLab, Git, and software development / build infrastructure, which sort of seem like overlapping topics already. But even with this split, we regularly have multiple conversations attempting to happen.
Think of, say, JIRA queues vs. tickets. We also have three separate JIRA queues for GitLab, source control, and development tooling, but we still use separate tickets in each queue, not one general-purpose ticket for all GitLab discussions.
It's hard to describe the benefits of this system to someone who's only ever used linear chat (or linear chat with weird thorns sticking out periodically, like Slack). On Zephyr, which is what Zulip was modeled after, I was in chat rooms that created a separate topic for each development issue and each customer support ticket, which made it easy for different groups of people to work on different things and still stay in the public chat room, and also extremely easy to go look up history later. Searching for things related to a ticket or a pull request in Slack is basically impossible.
These problems aren't obvious because people learn to work around them, mostly by avoiding public channels and IMing their friend, talking in person, keeping things in email or an equally high-latency system like JIRA, etc. But they're still problems that a good tool could solve. (Plenty of companies would say, we don't have group chat at all, we're working fine with email and person-to-person IM; probably you'd tell them that having something like Slack would be worth trying.)
(I'll also add that I recently spent over a year working from home where most of my interactions with other team members was through slack, so I'm fairly experienced there.)
Perhaps you want to give more context, but I did nothing on the readthedocs page other than look for the link.
But you need a functioning team/community using it to see how it works.
Mobile is different. From what I hear the Slack client is better/easier to use than the Zulip client. Haven't used either of them myself.
eg, my mattermost clone is https://mm.nqzero.com
just use a fake email (it's unused) and try it out. every time there's an announcement in this space i go to the landing page and am disappointed that trying out the product appears to be semi painful
Claims like these are really off-putting. Is it done for SEO purposes?
It's very expensive compared to slack though. I thought it would be priced closer to the cheaper alternatives (around $2).
Microsoft teams is around 2$ per month (for the most basic Office 360 plan... else free).
Hipchat is 2$ per month
It supports bots, so you can easily integrate your git / trello / etc.
Also they burning VC money and don't yet have proven business model so investing time in adopting it for non-gaming seems like strange decision.
As a result, for most folks, installing a security/bugfix release Just Works with a few seconds of downtime. For a release like this one with 3000+ commits, dozens of database migrations, and tons of new features, our largest sites found it Just Worked with about a minute of downtime while the database migrations were running.
If you really care about availability like we do with zulipchat.com, it's possible to have downtime be seconds even with the database migrations, but that requires a bit more expertise on how Zulip works than we think it's fair to expect server administrators to learn, so we don't recommend that to most folks.
So the main downside in this space of self-hosting is that zulipchat.com runs very close to master, which in practice means you'll get new features on zulipchat.com first (though folks running their own server can always upgrade; you just end up on the hook for the work). On the flipside, self-hosting is better for i18n (since our volunteer translators generally make sure languages get to 100% around a release, but new strings may not get translated for weeks after the code gets into production on zulipchat.com).
EDIT: There seem to be some folks who have done that already:
https://github.com/galexrt/docker-zulip/blob/master/README.m...
Otherwise perhaps phacility-hosted (so cloud) Phabricator, wherein it is mostly (a less unified UI) project management system but has the realtime chat component available in https://www.phacility.com/phabricator/conpherence/
> You’ll need an Ubuntu system that satisfies the installation requirements.
So if I'm using RHEL, Fedora, Arch or any other Linux distribution, tough luck. If they're supporting only Ubuntu, they could have at least created some deb packages.
There is an install script, but no details about what's going on under the hood or explanations of how to do it manually; what other software is required, e.g. for the database, how Zulip uses it, what libraries or other kind of dependencies it has, etc.
[1]: http://zulip.readthedocs.io/en/latest/production/install.htm...
I recently had to test a complex Django-based Document Management System: https://www.mayan-edms.com/
The install was a breeze. Even with very little experience with Docker it took me a matter of minutes to fire up a Digital Ocean droplet, paste in a few commands and have a fully working install.
Every open source web app should have some equivalent that is as simple as this.
Yes. Exactly what I wanted.
> What if you wanted to use Apache instead of nginx or a custom compiled Python interpreter or PyPy?
Then I would have read through the Docker config and figured out how to change it.
SaaS itself is the cancer killing usable software installations, not the other way around, IMO.
SaaS software often hits a sweet spot for one set of customers and then it is updated to match the needs of a new set of customers. Conflict can arise and the first set of customers abandon the product or are unhappy. When customers can deploy the software themselves they can decide to stay on the old version.
Of course this is often a terrible decision because customers get stuck on the really old version, experience security issues etc., but when it is managed appropriately (i.e. just strategic software for a business) it can work out. Managing lots of individual packages is a cottage industry for IT teams in big companies so they often undermine efforts to do this right.
This can be annoying from the sysadmin perspective, since there are now multiple operating systems to take care of, but at the same time, the developer may not be able to produce builds for all distros their users would like.
Ubuntu is a fine choice IMHO, given the above. But yeah, some debs / ppa would be nice.
Quick, which containers have libfoo in them? What version? Do you have a complete build process for them, or did you download the container from somebody else? Is it a clean libfoo, or did somebody clone it into their own tree and has later made modifications to it?
And that's really quite "annoying" from the sysadmin perspective, which makes it annoying from the devops perspective, which should make it annoying from your whole IT infrastructure perspective.
https://zulip.readthedocs.io/en/latest/overview/architecture...
(and get a lot more detail if you browse around the rest of our 120K words of developer documentation).
I have a great deal of Debian packaging experience (I used to maintain over 100 Debian packages for MIT's Debathena project, mostly powered by the config-package-dev project that I'm a co-author of; and then later 20+ in Debian itself as part of getting Sagemath into Debian; and I maintain the handful of Zulip dependencies that we ship versions of in our Ubuntu PPA), and so I have a pretty good sense of what does and doesn't work well with the Debian (and RHEL) style packaging models.
I'd love to support native packages for every platform, but it's a huge amount of work (especially on the maintenance side, since one needs to do QA for each platform's upgrade process) that comes out of the time we can spend on making Zulip a better product. And the result is likely to be less good error-handling; I'd rather have an installation/upgrade process that just works (and if it can't because of some problem beyond our control, like the server not having enough RAM or disk, gives a clear error message that explains the problem to the user) but is limited to one platform (which anyone can easily get; virtualization is 20 years old at this point!), than support lots of platforms but be constantly fixing little issues with the other ones.
Which isn't to say that we won't support e.g. RHEL in the future (we probably will), just that it's costly to do so, and the "Use an Ubuntu VM or container" solution works pretty well for most folks.
That said, we're open source (and an open community!) and anyone who's worked with Zulip knows that I'm very happy to provide detailed technical advice and do code review to help things like this happen.
I'm familiar with RPM packaging, so I feel you pain.
I understand that you don't have native support for every platform, after all you probably don't support Windows :-) What puzzled me was the lack of instructions, so that others could at least try making Zulip work on their system.
[1]: https://zulip.readthedocs.io/en/latest/development/setup-adv...
Ugh, NO! It's Premises. Get it right, Zulip! (and the countless people who screw this up every day.)
I am currently looking into Rocket.Chat which is based on Meteor (NodeJS) and MongoDB, a stack which, for me, seems better suited for this kind of app. But hey, I don't know, I haven't done performance tests or anything.
Does anyone know about any hard limits with either Zulip or Rocket.Chat?
regarding scaling.
Relevant info- Zulip is designed for ~15k users with real-world tests of 3k users. Not sure about concurrent users.
After a month or so of mumbling and grumbling on MM we went to Zulip, and brought on another dozen or so designers and PMs. Zulip lasted about 6 months before management implemented Slack company-wide and rolled out for the other 100 sales and support teams.
Zulip was the best for engineering, by far, but it was doomed from the start because the UX wasn't as simplified and polished as Slack. It didn't Just Work, you had to think and use it properly to see the benefits.
Back to your question: no limits I know of, and a t2.medium was 90% idle for an active team up to ~50 without a hitch. I think the docs (or launch announcement?) mentioned a large deployment around 1k, but I can't remember the details. You'll definitely want to test your expected configs and hardware to be confident.
For Zulip's scalability, see https://zulip.readthedocs.io/en/latest/production/maintain-s...
If you're Facebook or Google scale, you may need something with a different performance characteristics, but 99.9% of the world doesn't. Except that even Facebook doesn't: as I understand it they still use carefully sharded MySQL.
Regarding Postgresql, are you denying that relational DBs are less suited for write intensive tasks than say a NoSQL DB like MongoDB is? And couldn't a chat with thousands of users be a more than average write intensive scenario?
So is that what you've supposed to do when you become a parent? Stop doing everything else for two months, than never look at your child again? (Not saying the person did this.)
On what basis do you even suggest that that's what happened? They say that they took 2 months off after the birth of their child (which seems reasonable) and then had to catch up on their messaging when they got back.