We've been using Zulip internally for a couple of years now. We've used IRC and Jabber, looked at Slack and Hipchat and Skype and Lync, and somehow keep coming back to Zulip. It lets us have real, ongoing, and substantive conversations, with a large number of participants, without being overwhelmed.
I sometimes feel like Twitter is actually a better comparison for Zulip than Slack---in Zulip like on Twitter, it's easy to watch and participate in multiple conversations at the same time. Zulip's threading model exists somewhere between Slack's rigid "rooms" model and Twitter's everything-is-public model, so it's much lighter-weight to participate in multiple places at once than on Slack but it's also easier than on Twitter to have the right conversation with the right people without bothering others with something irrelevant to them. And Zulip's threading model makes it much easier to have multiple conversations within the same space without stepping on each others' toes or getting distracted.
Our remote folks rely on it particularly heavily. When Zulip got acquired it was our remote employees and their managers who were showing up outside my cube with pitchforks when I breathed a word of turning it off. It gives folks in other offices or working from home a watercooler and a way to virtually tap a group of coworkers lightly on the shoulder when they need help.
Basically we can't live without it, so I'm super-excited to see it finally open sourced. Thanks for making it happen. :-)
You mention considering to turn it off. Is open sourcing it a way to keep the project going? Any idea how many people at Dropbox will be tasked with maintaining it?
I'm sure it's a great communications tool, however since Rice joined Dropbox's board (http://www.drop-dropbox.com/) I'd have severe concerns using anything released by Dropbox. Even if it's open source. And while I apologize for a tangential comment, people should be aware of the politics promoted by their software vendors.
Hopefully if it's a truly valuable tool it will be forked and audited.
There's something that quite surprised me: being a software company: how is it that you've never gotten around to a Linux client? Do most of you use the web-version, or is dropbox mostly windows-centric (sorry, I'm quite ignorant about dropbox team's culture. :D )
Slack, Zulip, this feels like we are back in 1999, when the internet was divided by ICQ, AOL Instant Messanger, Windows Live Messanger, and Yahoo Messanger. (Instant/Live was a plus back then). And the only innovation over IRC was a backlog and buddy list.
I wonder when the Trillian of Slack+Zulip will come out. I hope Trillian (which still exists) is already working on it.
Those types of fragmentation issues never went away, they just changed focus. Whether it is Slack vs. Hipchat vs. Zulip, or WhatsApp vs. iMessage vs. text vs. Hangouts... more options means more (and easier!) ways to contact friends, family, and coworkers, but also means that you have to memorize a "best way to reach me" chart for each individual person.
Only Slack and Zulip are for specific teams/companies, not for the public at large. So there's no "fragmentation" issue, any more that there's one when a company uses Bugzilla and the other uses JIRA.
What annoys me about stuff like Slack is that it's misused. It's made for small teams but I've been 10k people open source projects use it instead of IRC. Of course, it was laggy and they eventually couldn't afford it.
And backlog/offline message functionality is available by turning on logging and using a ZNC proxy. My "buddy list" is just a bunch of direct message channels that I keep open.
But this is about social norms, not technology. Hear the phrase "remote workers...tap lightly on the shoulder".
We have had thousands of years to work out our nuances over interruptions and social signals when around the same campfire.
But suddenly (and from the past 20-30 years suddenly) we have phone conferences where half the conversation is "no, sorry, you go ahead" and email going from killer app to no longer being a way to get a reply in ten minutes but two days because the signal to noise ratio hit a tipping point somewhere around 2006. (No it's not spam, that's mostly a done problem. It's co-worker spam that's clogging our minds of not our inboxes)
So the differences between Zulip and Twitter and Slack and IRC and Microsoft bloody communicator why does it not know about tabs ffs! (Sorry). The difference with all of these is not their technology - it's pretty much the same all the time - but their social utility.
One day some comms package will get it all together (I think there is too little context to get it right yet) and we will all go"of course".
Until then we will try each different social choices baked into the code - rooms or tags or whatever. Maybe the next step is to have rooms for something, open cry for others.
Who knows - maybe we should look at pubs bars, libraries and streets for inspiration.
Whatever it is - Zulip is not the right solution nor is it the best - it is one more random mutation in the evolution of remote communication.
We (https://actor.im) are actually working on this, but not trying to connect slack, but building telegram, skype, whatsapp, social networks to one, slack like interface that will help you easily manage communications from many networks.
This is not our main feature, just something like side project.
This is precisely the problem we're working on with Matrix.org - providing a standard API that can be used to bridge together all of these different protocols in one decentralised model. It's better than Trillian in that the defragmentation happens serverside and you can use any compatible client with it (or one of the existing services if you prefer). For instance, we turned on our first Matrix<->Slack bridge this week - see https://github.com/matrix-org/matrix-appservice-bridge/blob/... for how easy it was.
"You can install a Zulip server on a system with 2G of RAM, but for production use we recommend a system with 4GB of RAM or more."
Something has gone horribly wrong when a chat server can barely run on 2G.
edit: As a frame of reference, here's what Inspire IRCd needs:
> A network with 3000-4000 locally connected clients and 10000 open channels experiences a constant 1-4% CPU use with 70MB of RAM use. This won't go up drastically, but it will go up. Around 40000 local clients means you'll be expecting some 500MB of RAM. [1]
Smart play. If they can lock people in to their free chat client they can get a stronger foothold into enterprise and servicing smaller start-up/SMB companies. This is what Paul Graham talks about building an e-mail client, just call it a todo list.
This is a storage application front-end. Slack and hipchat charge the money for secure storage, file transfer and data. That is Dropbox's competitive advantage and a great way to break into the market discreetly.
I was just about to try out Mattermost for our company communications. It integrates with a few things including gitlab, but Zulip seems to have a larger number of integration options, which is awesome. Anybody tried both and have thoughts on them?
I still prefer to host my own infrastructure, and I want to be able to archive and categorize a discussion (after it's happened) for searchability, but a couple of our people want an alternative to email and Google Hangouts for communications, and are pushing for Slack or XMPP. I've never been a big chat user and another of our people doesn't do chat at all (so we'd likely need some kind of email gateway for him). I'm not convinced anything exists that answers all these needs, but maybe I'm just way out of the loop.
Also, do any of these integrate with XMPP? Googling is inconclusive, but it seems neither connects to XMPP directly, which is unfortunate. I'd like to see an open standard backing whatever chat we choose.
Zulip has beta-quality integrations for mirroring content with a Jabber or IRC server (also we have one for Zephyr but that's a lot less popular). Check out bots/irc-mirror.py and bots/jabber_mirror.py. It's a bit complicated to setup right now though -- feel free to ping the Zulip development mailing list for help if you're interested.
Kaiwa[1] seems like it's supposed to provide this slack-style group chat web interface thingy, but uses XMPP as the backend. I've played with it a little, not the worst.
So, if you're going to tool around, and think, "Hey, I've got an Ubuntu/Debian box laying around" -- you best just follow the repo README advice and do this on a virtual box. The server install scripts have some heavy dependencies (puppet, django), if the "sudo -i" wasn't a clue enough. Also, if you are doing this, /root/zulip/scripts/lib/install's wgets need some "--no-check-certificate" flags. When I get zulip server stood up I'll post my IP.
Yeah I'm hoping that the community will do some work on simplifying this -- our focus on the installation process side was to make there be at least one installation process for the two use cases that works completely automatically.
FWIW at Zulip we usually did our development environment on our laptop not inside a VM; it's not that hard to do, but the nice thing about the Vagrant setup (written as part of the Hack Week project) is that it's for people with no familiarity with the software to get to a running environment.
It should be feasible to make a Debian package for it that plays nicely; as you can see most of the dependencies are already packaged.
Everything scripts/lib/install downloads via https has a valid cert; I suspect the issue may be that we should bundle the verification chain.
I'd love to see notes on whatever issues you encounter in a github issue or sent to the mailing list so we can make things smoother.
I haven't yet tried Zulip's threading model, but I can certainly say I'm not pleased with Slack's.
It can be very frustrating to try and trace a conversation backwards in a crowded Slack channel. I haven't used IRC in a while, but at least my client had a feature to toggle highlighting on a back-and-forth conversation, but that wasn't perfect.
My one big question is: does Zulip support push notifications to the next version of the mobile app if you self-host the server?
I'm not exactly sure how that'd be possible, but I wonder if they've managed to figure it out somehow. It's the one big problem with self-hosted chat apps like Rocket.chat and others - APNS and GCM are both centralized, and it's hard to federate them to provide push services for self-hosted instances of open source projects.
I think there are two approaches one could take for doing this:
* It seems like one way you could make that possible would be to make it really easy to do white-label builds of the Zulip mobile apps. E.g. the "Zulip for example.com" app. Would be more overhead than is ideal for smaller deployments.
* It should be possible to have APNS/GCM traffic go through a central community-hosted service that dispatches the messages on to a set of configured Zulip servers.
We actually had functionality based on a similar concept for the Zulip desktop app login process, where it would query a service on zulip.com with e.g. "example.com" and that would return the URL of what zulip server hosts example.com, so that users don't need to fill that out in the login process.
For the open source release, we replaced this with in an explicit "what server are you doing prompt" but it would certainly be technically possible to go this route.
That one is my fault. The main reason is a performance patch that we made to django, which I wasn't as diligent as I should have been in getting merged. The relevant pull request is https://github.com/django/django/pull/5166, so it will continue to be forked until I get that merged and we update our django version.
I'm curious on the separate uses of Redis, RabbitMQ and Memcached... it seems these uses could all just use Redis. And have a lower overall memory/cpu footprint to boot.
"The Zulip desktop app is a C++ application written with the Qt toolkit. It is a lightweight wrapper around a Webkit web view: it loads the zulip webapp as a single page full-screen webpage. The desktop app provides some native integrations: tray icon and Dock support, notifications, and more."
Wouldn't it be better if the multi-platform wrapper for Webkit web view was a separate project? Should be useful, if it doesn't exist already.
I believe that Atom Shell/Electron fills that use case today. I think when the Zulip Desktop app was started that Atom shell wasn't available or maybe not quite good enough.
Would be really interesting if one could program a secure way for the individually hosted servers to hook up with each other and verify the correctness of one another while at the same time keeping the messages secure (I guess bitcoins come to mind here..). Up until something like this happens I guess centralized social networks are going to rule the roost since the value of networks is almost always in their reach/size.
>Up until something like this happens I guess centralized social networks are going to rule the roost since the value of networks is almost always in their reach/size.
This is a group chat. It's value is in being restricted in reach and/or size to the group (team, startup, enterprise) deploying a version of it.
> Would be really interesting if one could program a secure way for the individually hosted servers to hook up with each other and verify the correctness of one another while at the same time keeping the messages secure (I guess bitcoins come to mind here..).
You don't need a blockchain for that! Looking at the docs, it looks like Zulip messages are visible to servers anyway; that means that there's no need to encrypt the messages to hide them from the servers.
Now, supporting end-to-end encryption for chat would be pretty cool, but it's not going to happen in a browser client (since browser clients are currently completely at the mercy of servers, and will be so for the foreseeable future).
[+] [-] kevinr|10 years ago|reply
I sometimes feel like Twitter is actually a better comparison for Zulip than Slack---in Zulip like on Twitter, it's easy to watch and participate in multiple conversations at the same time. Zulip's threading model exists somewhere between Slack's rigid "rooms" model and Twitter's everything-is-public model, so it's much lighter-weight to participate in multiple places at once than on Slack but it's also easier than on Twitter to have the right conversation with the right people without bothering others with something irrelevant to them. And Zulip's threading model makes it much easier to have multiple conversations within the same space without stepping on each others' toes or getting distracted.
Our remote folks rely on it particularly heavily. When Zulip got acquired it was our remote employees and their managers who were showing up outside my cube with pitchforks when I breathed a word of turning it off. It gives folks in other offices or working from home a watercooler and a way to virtually tap a group of coworkers lightly on the shoulder when they need help.
Basically we can't live without it, so I'm super-excited to see it finally open sourced. Thanks for making it happen. :-)
[+] [-] sytse|10 years ago|reply
You mention considering to turn it off. Is open sourcing it a way to keep the project going? Any idea how many people at Dropbox will be tasked with maintaining it?
[+] [-] new299|10 years ago|reply
Hopefully if it's a truly valuable tool it will be forked and audited.
[+] [-] hobarrera|10 years ago|reply
[+] [-] tbingmann|10 years ago|reply
[+] [-] JoshM33k|10 years ago|reply
[+] [-] coldtea|10 years ago|reply
[+] [-] peruvian|10 years ago|reply
[+] [-] Mithaldu|10 years ago|reply
[+] [-] hughes|10 years ago|reply
[+] [-] lifeisstillgood|10 years ago|reply
We have had thousands of years to work out our nuances over interruptions and social signals when around the same campfire.
But suddenly (and from the past 20-30 years suddenly) we have phone conferences where half the conversation is "no, sorry, you go ahead" and email going from killer app to no longer being a way to get a reply in ten minutes but two days because the signal to noise ratio hit a tipping point somewhere around 2006. (No it's not spam, that's mostly a done problem. It's co-worker spam that's clogging our minds of not our inboxes)
So the differences between Zulip and Twitter and Slack and IRC and Microsoft bloody communicator why does it not know about tabs ffs! (Sorry). The difference with all of these is not their technology - it's pretty much the same all the time - but their social utility.
One day some comms package will get it all together (I think there is too little context to get it right yet) and we will all go"of course".
Until then we will try each different social choices baked into the code - rooms or tags or whatever. Maybe the next step is to have rooms for something, open cry for others.
Who knows - maybe we should look at pubs bars, libraries and streets for inspiration.
Whatever it is - Zulip is not the right solution nor is it the best - it is one more random mutation in the evolution of remote communication.
[+] [-] ex3ndr|10 years ago|reply
This is not our main feature, just something like side project.
[+] [-] ara4n|10 years ago|reply
[+] [-] krig|10 years ago|reply
Something has gone horribly wrong when a chat server can barely run on 2G.
edit: As a frame of reference, here's what Inspire IRCd needs:
> A network with 3000-4000 locally connected clients and 10000 open channels experiences a constant 1-4% CPU use with 70MB of RAM use. This won't go up drastically, but it will go up. Around 40000 local clients means you'll be expecting some 500MB of RAM. [1]
[1]: http://www.inspircd.org/wiki/FAQ.html
[+] [-] on_|10 years ago|reply
This is a storage application front-end. Slack and hipchat charge the money for secure storage, file transfer and data. That is Dropbox's competitive advantage and a great way to break into the market discreetly.
Client looks cool, I will be downloading it.
[+] [-] eric-hu|10 years ago|reply
http://paulgraham.com/ambitious.html
[+] [-] SwellJoe|10 years ago|reply
I still prefer to host my own infrastructure, and I want to be able to archive and categorize a discussion (after it's happened) for searchability, but a couple of our people want an alternative to email and Google Hangouts for communications, and are pushing for Slack or XMPP. I've never been a big chat user and another of our people doesn't do chat at all (so we'd likely need some kind of email gateway for him). I'm not convinced anything exists that answers all these needs, but maybe I'm just way out of the loop.
Also, do any of these integrate with XMPP? Googling is inconclusive, but it seems neither connects to XMPP directly, which is unfortunate. I'd like to see an open standard backing whatever chat we choose.
[+] [-] proksoup|10 years ago|reply
A timeline [1].
[1] https://cdn.sameroom.io/chat-timeline.pdf
[+] [-] tabbott|10 years ago|reply
(Patches welcome!)
[+] [-] it33|10 years ago|reply
Mattermost team here. We've had requests for XMPP, and potentially it can be added in future. Feature idea can be tracked here (and more ideas welcome!): http://mattermost.uservoice.com/forums/306457-general/sugges...
That said, communication has changed significantly since the XMPP standard. For example, after we implemented markdown in Mattermost it's really hard to go back (http://www.mattermost.org/open-source-slack-alternative-adop...).
If you decide to try Mattermost, please let us know if we can help! Twitter at @mattermosthq or via community options at http://www.mattermost.org/
[+] [-] finnn|10 years ago|reply
[1]http://getkaiwa.com/
[+] [-] hanley|10 years ago|reply
Not sure about the guy that "doesn't do chat", he might be out of luck. Time to adapt.
[0] https://confluence.atlassian.com/pages/viewpage.action?pageI...
[+] [-] raesene9|10 years ago|reply
[+] [-] jonathanwallace|10 years ago|reply
https://www.zulip.org/clients.html
[+] [-] benbristow|10 years ago|reply
[+] [-] tabbott|10 years ago|reply
[+] [-] vezzy-fnord|10 years ago|reply
[+] [-] manigandham|10 years ago|reply
There's no reason to use a font-weight of 200 (or anything less than 500) on body text, save that for the headlines.
http://i.imgur.com/r7a794n.png
[+] [-] mansilladev|10 years ago|reply
[+] [-] tabbott|10 years ago|reply
FWIW at Zulip we usually did our development environment on our laptop not inside a VM; it's not that hard to do, but the nice thing about the Vagrant setup (written as part of the Hack Week project) is that it's for people with no familiarity with the software to get to a running environment.
It should be feasible to make a Debian package for it that plays nicely; as you can see most of the dependencies are already packaged.
Everything scripts/lib/install downloads via https has a valid cert; I suspect the issue may be that we should bundle the verification chain.
I'd love to see notes on whatever issues you encounter in a github issue or sent to the mailing list so we can make things smoother.
[+] [-] jnpatel|10 years ago|reply
It can be very frustrating to try and trace a conversation backwards in a crowded Slack channel. I haven't used IRC in a while, but at least my client had a feature to toggle highlighting on a back-and-forth conversation, but that wasn't perfect.
[+] [-] dang|10 years ago|reply
[+] [-] sinak|10 years ago|reply
I'm not exactly sure how that'd be possible, but I wonder if they've managed to figure it out somehow. It's the one big problem with self-hosted chat apps like Rocket.chat and others - APNS and GCM are both centralized, and it's hard to federate them to provide push services for self-hosted instances of open source projects.
[+] [-] tabbott|10 years ago|reply
* It seems like one way you could make that possible would be to make it really easy to do white-label builds of the Zulip mobile apps. E.g. the "Zulip for example.com" app. Would be more overhead than is ideal for smaller deployments.
* It should be possible to have APNS/GCM traffic go through a central community-hosted service that dispatches the messages on to a set of configured Zulip servers.
We actually had functionality based on a similar concept for the Zulip desktop app login process, where it would query a service on zulip.com with e.g. "example.com" and that would return the URL of what zulip server hosts example.com, so that users don't need to fill that out in the login process.
For the open source release, we replaced this with in an explicit "what server are you doing prompt" but it would certainly be technically possible to go this route.
[+] [-] paste0x78|10 years ago|reply
[+] [-] stepmr|10 years ago|reply
[+] [-] acrefoot|10 years ago|reply
[+] [-] gregwtmtno|10 years ago|reply
[+] [-] tracker1|10 years ago|reply
[+] [-] tabbott|10 years ago|reply
Zulip's use of redis right now is basically just for the API rate-limiting; it could be easily removed.
[+] [-] cdixon|10 years ago|reply
[+] [-] muyuu|10 years ago|reply
Wouldn't it be better if the multi-platform wrapper for Webkit web view was a separate project? Should be useful, if it doesn't exist already.
[+] [-] acrefoot|10 years ago|reply
[+] [-] dingdingdang|10 years ago|reply
[+] [-] coldtea|10 years ago|reply
This is a group chat. It's value is in being restricted in reach and/or size to the group (team, startup, enterprise) deploying a version of it.
[+] [-] zeveb|10 years ago|reply
You don't need a blockchain for that! Looking at the docs, it looks like Zulip messages are visible to servers anyway; that means that there's no need to encrypt the messages to hide them from the servers.
Now, supporting end-to-end encryption for chat would be pretty cool, but it's not going to happen in a browser client (since browser clients are currently completely at the mercy of servers, and will be so for the foreseeable future).
[+] [-] parfe|10 years ago|reply
[+] [-] bachmeier|10 years ago|reply
[+] [-] tommoor|10 years ago|reply