Very differently. Slack does threading on the basis of replies to a message and hides/collapses those under a thread, showing them only to people who expand and notifying only those who are already involved in the thread (by replying to it or being OP)
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
Threading in email works via message-ids and references to preceding messages, nothing to do with subjects. That is, except as a workaround for garbage email clients and services too incompetent to use email correctly.
I mean, depends on your MUA in practice. I think by standard for server side threading— https://tools.ietf.org/html/rfc5256 — "base subject" is definitely a valid consideration. I only skimmed though. :-) feel free to extract a spec, I'm curious (but not enough to read 19 pages right now)
ORDEREDSUBJECT
The ORDEREDSUBJECT threading algorithm is also referred to as
"poor man's threading". The searched messages are sorted by
In other words: as a workaround for garbage email clients and services too incompetent to use email correctly.
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 Slack threads are an annoyance. They lead to missed answers and discussions, because they are rarely used in average user groups. When they are they default to private only for the writer and appear out of the natural flow for the reader.
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.
In busy channels in medium-sized companies, lack of threading is a huge pain: person A says "Hi, I'm trying to do X, how do I do this," person B says "Hi, I'm getting error message Y" 2 minutes later, someone shows up 5 minutes later and says "Have you tried installing this thing" and they were talking to B about solving Y but A tries to install it and use it for X and then everyone is confused and wastes time.
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?
Why not to use direct messages for the example you gave ? Or even better reply to the message itself which creates semi topic under it ?
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.
You can reply to exact message in slack. Ive been using it for over a year in a company hiring few thousend people and we had no issues you describe here...
"Reply to the message itself" is what Zulip does best, and where Slack is lacking. I have to zoom in to a thread to see what's going on with it, I can't just follow the main room and see the tag for a sub-thread interleaved.
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.
> Why not to use direct messages for the example you gave ?
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.)
It's one of those things that I didn't realized was a big deal until I experienced the alternative -- I just signed up, tried it for less than five minutes, and I'm already sold on this over Slack.
(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.)
Threading done right or wrong in in slack doesn’t really matter. What matters is if your point gets across. Sometimes that’s fine via threads. Sometimes threads get in the way.
You could alternatively OAuth sign up for the chat.zulip.org server used for project development and see the feature in action there (https://zulip.readthedocs.io/en/latest/contributing/chat-zul... ) so long as you kept testing traffic to the `#test here` stream :-)
We used to do that, but it turns out that having the Internet visit your chat community without any briefing isn't the best plan. Linking to the ReadTheDocs page has helped a lot in making sure people joining the community have some sense as to what to expect (e.g. that it's at times running a super beta version of Zulip, or that people are doing actual work, that we have a code of conduct, and you should send your test messages to #test here).
We used Zulip (then a commercial product) at FoundationDB, and really liked it. We had teams in two cities.
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.
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.
Same here. We're a company with about 50 people and deal with a lot of operational chatter. The threading model of Zulip works really great for us.
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.
> 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.
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.
As news about Slack becomes fewer and farther in-between, reminders of how much more usable Flowdock was also fade from view. I'm left with a dead emptiness in my heart and a general pessimism about corporate communications.
Is there _any_ service with Flowdock style threading now? XMPP clients? Game chats?
Unfortunately they've taken a left turn on the quality front, at least for the iOS app. It was unmaintained and slightly buggy, but then it became maintained and slow, power-hungry, and extra-buggy, and new versions usually don't make it better. At least the macOS desktop app is still based on WebKit rather than Electron, so it doesn't guzzle battery.
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 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.
It has @mentions, notifications, and the ability to have some Google-Docs style inline comment threads, so depending on the use case I'm not sure you'd totally miss it
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/
Another threaded slack alternative I've found enjoyable is Spectrum. (https://spectrum.chat) They've recently open sourced as well, (https://github.com/withspectrum/spectrum). Their design is appealing, and I can see a lot of work being done on the platform. Not affiliated or anything, just a fan.
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)
I feel like a little background would help this thread. I vaguely know/knew some of the founders, but am not really in touch anymore
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]
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
They offer free hosting for open source projects. It has been really great for Mixxx (floss DJ software), allowing our ~10 person distributed dev team to work together much more effectively.
We're coming from Freenode as our only real-time communication so the difference is night and day. Slack is a no-go for many due to not being FLOSS and I'm concerned about vendor lock-in if they were to stop being so generous or run out money and shut down.
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.
> The project survived my becoming a parent in December and taking 2 months off to bond with my baby daughter Lily. For me, it was a great stress test of Zulip’s catch-up experience; I was able to catch up on over 20,000 messages of chat history when I returned, following up on more than 100 conversations that needed my attention.
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.)
Explaining my downvote here: this doesn't add anything valuable to the conversation. Either you have a defensible point or you don't; this sort of behavior suggests that you are more interested in having an argument than a discussion.
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.
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
It's really hard to get a sense of how Zulip works without any screenshots or videos anywhere on zulip.org, just general descriptions like "the world's most productive group chat" and "email threading model."
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.
We're definitely planning to provide a slick explanation on zulipchat.com. Using chat.zulip.org is helpful, especially if you visit a day later and read the message history; since you really only experience Zulip's magic properly when catching up on a bunch of unread messages (the `n` hotkey in particular is super great).
That one single screenshot shows... a chat I presume? Which looks marginally worse than Slack.
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?
Given that it's free software, it might be worth making the install instructions a little bit more visible. At least then people can whip up a VM and try it on their own. The instructions[0] look straight forward, though I haven't tried it.
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.
Building one's own release is easy. Before I get into how, you should be linking to https://zulip.readthedocs.io/en/1.8.0/prod.html for installation instructions -- that's the much simplified install instructions for the latest release.
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.
One stripped down screenshot is not enough. I need to see at least one image of your application in all of it's glory from the moment I hit the page. More is better. You can describe it all you want but if I can't actually see an image of it in action, I'm not going to be interested enough to go through the (poorly documented) install process.
That screenshot shows nothing about the threading model! If you're going to toot your horn about the fantastic, revolutionary, "world's most productive" threading model all day long, for goodness' sake show us what the threading model is, front and center.
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.
So I had something similar happen to me. I started out at the _ sign in _ page, I attempted to sign in with google, it remarked that I don't have an account and sent me to the _ sign up _ page that looked very similar to the sign in page, and from there, I was able to create an account via my google account.
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."
Can you open an issue on http://github.com/zulip/zulip/issues/new? We haven't heard similar reports in the year since the GitHub auth backend was added, so I'm guessing there's something special about your account (or maybe a problematic browser extension); I'd love to debug this with you.
I don't understand why so many applications do this. "Try our service! But we won't show you what it looks like or give you any details at all!" No, I'm not even going to consider your software if there aren't at least a few screenshots on the frontpage. It gets especially annoying when they use stylized wireframes in place of screenshots.
Why is it so difficult to take some screenshots and put on them on the homepage and/or features page?
Do companies actually pay for software they can't justify ahead of time? It took me months to justify the costs of a damn password manager and explaining why sending passwords over email and our XMPP was a bad idea
That is actually what I had to justify the first time (about 4 years ago), which was the more difficult one. We had a giant spreadsheet in Google Sheets with all of our logins and everyone seemed okay with it. Convincing them it was insecure and needed to be moved to Keepass was a nightmare. This took a good half year to do.
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.
What is stopping you from running it in k8s? Don't you just need to create a docker file based on the Ubuntu docker image, plus whatever installation steps zulip requires?
EDIT: There seem to be some folks who have done that already:
Yeah, well, even if it is an open source project, what about git? You can't remove an arbitrary commit in the tree. I'd argue discussions about code follow under the same umbrella.
I really thing people are taking this GDPR thing WAY too seriously. They are really only going after the obvious abusers, IMO.
I doubt it. I've read the 66 page standard and I remember something about "records required for business", ie transactions, tax info, etc. I'd argue employee conversations would fall under the same umbrella.
Zulip is using Python and Postgresql. Is this a great choice of stack for a chat app? I'd love to know how Zulip performs with hundreds of concurrent users.
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?
We tried RocketChat for about a day before switching to Mattermost. It wasn't great, but worked okay for a team of 20-30.
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.
We've been extremely happy with the Python 3 (with mypy static types) and Postgres stack. Like with any app, you need to take some care to design the database model right and avoid database queries in loops. But with our design, all the expensive operations are done in the database and cache, so Python is just as fast as anything else. And because our data model design and indexes are correct and Postgres is awesome, the database queries are all fast. We use Postgres' built-in full-text search, and people frequently praise Zulip's search as being unusually good for finding past conversations.
PostgreSQL is really really good, for any normal amount of data, or any normal number of users. If you can make Postgre do most of the work, it doesn't hugely matter what you build on it.
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.
Yes I guess with the right hardware everything is possible. The question is if you can get away with smaller hardware when using non-relational databases. Well one would have to test this.
I said concurrent users as in users that are online at the same time, each of them probably connected via WebSocket streaming and sending messages.... Thanks for the downvote...
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?
Python fits very well this use-case. If you design a chat app properly you should be doing very little computation. With Python's async you can scale up to large number of sessions / users / channels without issues.
If someone tried to do it how easy is it to add to Zulip login with 3rd-party SSO server like Discourse?
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.
Zulip uses python-social-auth for some other backends, so for the more general version of your question about doing some other third-party auth, the answer is not super hard. That said, it looks like python-social-auth doesn't have a backend for Discourse: https://python-social-auth.readthedocs.io/en/latest/backends....
It's also probably not super hard to just add a direct authentication backend for Discourse.
Thanks for information. Seems like I should be able to do it.
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.
Once something is merged to master in zulip.git, it's usually on zulipchat.com production within a few days.
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.
I love Zulip. I really wish other IM clients implemented functionality similar to Zulip's threading. It allows for easily filtering converstations and makes reading history that much easier.
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.
Thanks for the feedback! I agree with some of these complaints (e.g. I very much wanted to fix the push notification registration process in this release), but I'd like to clarify a few things:
* 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.
* 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.
Oh my bad then. I don't know why I though it was a Cordova app. Might have been because our last chat provider had one and I was mixing them up.
My problem with search is that it doesn't find URLs. I think it was reported already, but I will check anyway.
152 comments
[ 3.2 ms ] story [ 210 ms ] threadZulip'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
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.
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.
https://news.ycombinator.com/item?id=16877395
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.
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
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.
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/
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)
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
[1] https://barnowl.mit.edu/
[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.
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.
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
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.
[0] - https://zulip.readthedocs.io/en/1.7.1/prod.html
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.
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.
https://twitter.com/b0rk/status/986447131421609985
Anyone got experience with both?
EDIT: There seem to be some folks who have done that already:
https://github.com/galexrt/docker-zulip/blob/master/README.m...
I really thing people are taking this GDPR thing WAY too seriously. They are really only going after the obvious abusers, IMO.
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?
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.
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.