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?
Just to clarify, most users of Zulip were using the central cloud service (zulip.com). Kevin's experience is from one of the Zulip customers who had "Zulip Enterprise" (aka a Zulip server in their own data center -- which is also the basis of the "self-hosted production server" installation process you see now is based on). So "turning it off" in this case refers to their discussions about their internal deployment, not the Zulip cloud service (which is still running for existing Zulip users today).
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.
Do you boycott every company that has any questionable people on their board? This feels like cherry picking because of how high profile Rice is. Her only crimes are being in the Bush administration and doing her job, and being on the board of an oil company. That's pretty weak.
I agree in principal that the politics behind a business matter. But why focus on Dropbox? Rice teaches at Stanford too, why not boycott Stanford and anything coming out of it?
But your complaints have nothing to do with the codebase. How would a fork help? If I fork it and change nothing but the name does it become palatable to you?
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 )
> There's a Linux client, but we don't have binaries posted yet. We hope to have a PPA setup soon.[0] In the meantime, you can clone the git repo[1] and build from source.
It's mostly a WebKit wrapper, just like the Mac and Windows clients, but it does provide an icon and a dedicated window and potentially better integration with system notifications etc.
Most tech companies (doubly so in the Bay Area) develop on Macs and deploy (servers) on Linux. There'd be little pressure to develop a Linux client since most devs are spending their day on a Mac.
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.
Every week I have to use a Cisco jabber client, Hipchat, Slack, and Hangouts within the same company.
I know it's got less of a "cool" factor because it wasn't invented last week, but I soooo wish everyone would just use IRC. Use irccloud if you want some nice apps and picture embedding.
At some point it did fade a bit. About 2-3 years ago enough people were using XMPP/Gtalk so that I could reach about 80% of my acquaintances thought it.
Now, there's no single network that holds over 25% of them. Except facebook, but most of them don't actively use facebook every day, nor pay attention to it's IM.
It would be nice if the iOS and Android built-in Contacts apps had better support/integration for all the various messaging apps that work on their respective platforms. Rather than trying to remember who uses which services, their contact card could simply contain the entire roster of their services and usernames, and you could initiate a conversation in that service from within the contact card. I know you can do this with the baked in messaging services for each platform (SMS/MMS and iMessage for iOS, SMS/MMS and Hangouts for Android), but I'm talking about a one-stop-contacts-shop for every major messaging platform. Maybe that would require too much cooperation between messaging app authors and the big OS vendors, but I think it would be possible.
An alternative solution would be a cross platform third party Contacts app that offers that kind of integration. I've seen multi-messenger apps (Trillian, IM+) for both platforms, but that's not quite the same thing and it inevitably leaves out important functionality from the official apps.
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.
This is a very short sighted view. There is a real need for an alternative to IRC - and closed source products do not cut it when we are talking about communication.
What parent is talking about is a real problem. There's micro-ecosystems out there around specific closed source products, all of them centralized, none of them compatible... and in the mean time, the only real decentralized, open source group chat solution (IRC) has a lot of issues [1] which shouldn't exist in 2015.
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.
I also really dislike the idea of having to register with a phone number. I reminds me of ICQ, where I had to dig up some obscure number to log in. Except, I also lose my account permanently the moment I lose my phone.
This is the regrettable de-facto standard. I'd like to see the opposite: a network that provides native desktop clients. Telegram seems to be the only one taking this seriously up to now.
that would be great. what would be greater though is ensuring that actor.im cannot read the data as it transits (or easy to setup on our own local machines)
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.
There have been and always will be competing products and communities that serve similar purposes. We use what we think is the best one. Is this a bad thing?
(Not to mention the fact that Slack is for internal teams, not for IRC-like discussions, though our open newsroom (http://newsroom.grasswire.com) and some other communities (http://fpchat.com) have repurposed it for that.
I think that "best tool for the job" attitude is a straw man. It seems to presuppose that "the job" is per-organisation, or even that there is one job.
In truth many of us believe that the goal is enabling everyone - universally - to communicate without a single body holding centralised control of message history, reachability and access.
Quick review of the globally federated protocols:
Email is too slow and bulky and lacks "group" capability
IRC is deeply unreliable and lacks identity, archiving, and media management
NNTP is too amorphous, slow, and lacks any privacy or security controls
Everyone thinks SIP is just for telephony (it isn't)
XMPP is phenomenally complicated yet held great promise
- if only everyone could agree on the extensions and semantics.
- but was murdered by Google.
Yup, it's a big shame. XMPP promised for quite a while, but then stagnated and failed to deliver what most users were expecting (mostly due to implementations, not lack of protocol features).
I've recently given up on IM, and written about it recently:
Wow, out of all the things that may have occurred to me over the last couple years of using Slack, "this feels like 1999" is definitely not one of them.
One could say that OS-level notifications could be considered a crude replacement of an aggregation tool like Trillian. We didn't have these back in the ICQ days and today it's easier (read: less painful) to listen on multiple messaging apps. Especially on mobile devices.
Amazon for a long time (maybe even today) used IRC for 1:N communication. I personally like IRC over anything else, but I am probably just too old... :)
"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]
Who cares though? A 4 GiB stick of ECC server RAM is $35-50, which is only about $10 more expensive than a 2 GiB stick.
If you spent even twenty minutes of developer time trying to reduce memory usage, you've already lost money.
It may still be worth the total savings if someone solves it globally, but from the perspective of an individual company who wants to run this, it doesn't matter at all.
Posting this in a few places since it came up N times on this thread: I opened https://github.com/zulip/zulip/issues/34 to track optimizing the server-side memory consumption. :)
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.
Yep. I like his talk at Pycon in 08, where he talks about building a better email client[0] but it is also noted in your link. Thanks, I switched back from mobile and meant to post it.
Incidentally, if anyone has seen his Pycon talk, one of his ideas is "Bring Back the Old More's Law", and if you are curious it is ~2-3 minutes here[1]. I have always been wondering what he means when he says a "sufficiently smart compiler is a byword for impossible" is this an AI reference or a deeper computer science theory that I am missing. Always been really curious.
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.
HipChat, while providing the XMPP backend, and a self-hosted option, isn't cheap, and doesn't seem to provide the extensibility that an open source option would. But, it's certainly closer to the right thing than Slack (at least, from a surface level examination).
I guess it doesn't even need to be XMPP, specifically. But, some open standard and some level of interoperability would be nice. In googling I came upon matrix.org, which also seems promising, but has the same problem XMPP has of not having great clients (though I also found Kaiwa, which looks like a pretty good XMPP client with Slack-like features). Maybe one of these open source projects will formalize their protocol, and we can all move forward on interop with that.
That chart is amazing (and depressing, as another commenter said). I counted and I've used 18 different ones. I've also used a few others for video and audio conferencing, like WebEx (unless that falls under a particular Cisco one in the chart, I don't know).
Currently I'm "only" using Slack, Skype, iMessage, and Google+ Hangouts (very occasionally, with considerable loathing).
It strikes me the situation is inherently ridiculous, but after not far off 20 years of dealing with it, I can't say it bothers me that much anymore.
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.
In doing research today I see some valid reasons for not going XMPP. The question that raises for me is merely: How do these things interoperate going forward? I'm through with walled gardens, particularly with something as important as team communications. If not XMPP, then what needs to happen to allow any chat to federate with any other chat? And, perhaps equally important, how does one move data from one to another. Data lock-in should be on everyone's mind, but it always seems to be an afterthought (so far after that it doesn't come up until the disastrous occurs and your vendor sells out and closes up shop, or becomes like SourceForge and destroys user trust).
I don't mean to rant at you, of course. Mattermost looks great and it is open source, which means any complaints I have, I am free to put my money/time where my mouth is and fix it.
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.
There is something wrong with your rendering. What system are you using? It looks to me like the hinting and/or sub-pixel rendering is wrong. I had a lot of problems with this when I moved to Arch Linux because Debian had done some default setup that I needed to figure out in Arch. Here are my xresources for xft if you are using Linux (probably formatted badly, but you can get an idea):
It will give you a place to start, anyway. Main things you will want to change are the rgba and dpi depending on your monitor. The filter and hintstyle depends on your preference. Just make sure to turn autohinting off.
If you are using something else, then I'm not sure how to fix it, but I can tell you for certain that it is broken ;-)
Enough other people (who can read other websites perfectly fine) are complaining about breakage that it's pretty clear this site is doing something wrong. "You had one job ..." applies here. Body text on a webpage should be readable on all platforms.
Nothing is broken with my rendering or system. This is a fresh Windows 10 on a normal 1900x1200 24" monitor.
The font used is a fancy font with thinner strokes and then using a font-weight of 200 makes it that much smaller, making it illegible. There's no reason to make body text so skinny and it's often better to stick with normal system fonts.
Headlines and occasional larger text can have more styling. This is just a failure of design/UX on this site.
The problem is not so much the font weight as the font itself. Time to abandon 'Humbug' on that site which is translating to SourceSansPro-Light-webfont at font-weight: 300.
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.
Hey tabbott, I'd love to chat about this more if you're interested, it's something we've been particularly looking for. My email is sina@eff.org.
White-label builds of Zulip apps would work, but at least in our case wouldn't be ideal. Having a central community-hosted service would be much better.
This does look like a good product though. Personally I like the style of this more than slack at first glance. Running your own server and being open source are awesome. I can't wait to see what people build on it.
The worst part is, all those systems (we can't say clients anymore) don't even try to standardize anything. Which is understandable, because they feel like they're improving the usability situation. All they do is provide bridges to other solutions, but that's not helping on the protocol side.
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.
Redis does have persistence options... I was just thinking Redis is often used as a more advanced memcached, while also supporting pub/sub channels and acting as a mq broker with a frontend... was just thinking in terms of reducing the requisite services, since rabbitmq requires erlang and it's own services as well as memcached.
"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.
There's no benefit to it only being able to reach some small group of people. There is benefit in being able to include only a small group of people in a particular conversation, but that does not require no interoperability, only a concept of groups and permissions and access controls. In fact, it is completely orthogonal to the lack of interop.
> 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).
Posting this in a few places since it came up N times on this thread: I opened https://github.com/zulip/zulip/issues/34 to track optimizing the server-side memory consumption. :)
1) Is there any support for federation? At first glance it looks like every installation might have multiple servers, but more for balancing load, than federation?
2) How well is the protocol specified? How hard would it be to par down the requirements to eg: just python and sqlite/lmdb or redis (or zodb...)? Say if one wants to support just ~100 users or so?
(1) Not currently, though you can certainly imagine doing it and having it work well; the core data model doesn't change very much over time.
(2) There's a reasonably well-specific API, and you could imagine building an independent implementation that fit that API and feeling good about doing so. But I feel like that would probably be a lot of work and you could probably much more easier achieve whatever your actual goal without paring down the dependencies very much.
E.g. the relatively high minimum recommended RAM for a Zulip server is mostly due to running 20 Python processes for all the queue workers, most of which are idle all the time. If we wanted to decrease the memory requirements, there's a variety of ways to solve that problem directly that are a lot easier than doing a rewrite :).
It looks cool that said as usual its "hey I dont like <insert some chat program> so im just going to code my own incompatible one".
In the end im happy with IRC. Its not the greatest but its the one that just works:
Its the one everyone who's an engineer in the business knows how to use, bots work, automation work, and irccloud works if you like webuis.
Wow. Good luck installing this. I'm not touching it. It needs to do all sorts of hokey things to work. It needs puppet and git to work? You can't just install python packages, it installs them from a ppa. Deployment is a huge mess. It doesn't have to be this hard.
Thanks for the feedback. We prioritised getting this into a state where it can run in dev and production based on the existing deployment processes we used in our own environment.
I'm working on a Debian package[1], and we expect to iterate on the deployment process in general.
Has anyone switched workplace chat from skype to something else? I don't much like the chat bits in Skype but on the other hand the voice bit is fantastic. I can't imagine having to manage two separate contact lists for chat and voice, so I'm reluctant to switch to something that doesn't have good voice or integrates with something that has (e.g. launch group call from a chat conversation).
If you're looking for interesting elements, the REQ framework for doing argument validation I'm pretty happy with and have been thinking would be good to try to extend to be part of Django upstream.
There's a Git integration that you can use with GitLab or anything else that supports post-receive hooks. But it would be cool if someone contributed a more slick GitLab integration :)
Also there is a beta XMPP gateway at bots/jabber_mirror.py that can mirror traffic with an XMPP setup. It's beta because it's kinda annoying to setup; feel free to reach out on the development list for help if you have issues setting it up.
One note is that the a key feature of Zulip is thread-level topics which aren't really supported by XMPP; see https://news.ycombinator.com/item?id=10280817 for more discussion of this.
Would nice if it were easier to self-host. Requiring Ubuntu 14.04 with 2GB RAM minimum...not terrible, but could point at a lot of work to be done to broaden the appeal. (Edit: And of course, a thank you to Dropbox for releasing it, this does look like a nice little setup)
Oh, I'm interested in the business decision behind that. For example why didn't they just buy (not acquire) the slack product. What were the reasons to host it in-house and manage it themselves.
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. :-)
So Zulip was acquired in March 2014 http://techcrunch.com/2014/03/17/dropbox-acquires-zulip-a-st...
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?
Just to clarify, most users of Zulip were using the central cloud service (zulip.com). Kevin's experience is from one of the Zulip customers who had "Zulip Enterprise" (aka a Zulip server in their own data center -- which is also the basis of the "self-hosted production server" installation process you see now is based on). So "turning it off" in this case refers to their discussions about their internal deployment, not the Zulip cloud service (which is still running for existing Zulip users today).
I think my blog post covers pretty well why we open sourced Zulip: https://blogs.dropbox.com/tech/2015/09/open-sourcing-zulip-a....
7 replies →
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.
Do you boycott every company that has any questionable people on their board? This feels like cherry picking because of how high profile Rice is. Her only crimes are being in the Bush administration and doing her job, and being on the board of an oil company. That's pretty weak.
I agree in principal that the politics behind a business matter. But why focus on Dropbox? Rice teaches at Stanford too, why not boycott Stanford and anything coming out of it?
7 replies →
But your complaints have nothing to do with the codebase. How would a fork help? If I fork it and change nothing but the name does it become palatable to you?
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 )
There is a Linux desktop client, although it isn't mentioned on the front page with the other clients.
From https://zulip.org/clients.html:
> There's a Linux client, but we don't have binaries posted yet. We hope to have a PPA setup soon.[0] In the meantime, you can clone the git repo[1] and build from source.
[0]: https://github.com/zulip/zulip-desktop/issues/1
[1]: https://github.com/zulip/zulip-desktop
It's mostly a WebKit wrapper, just like the Mac and Windows clients, but it does provide an icon and a dedicated window and potentially better integration with system notifications etc.
Most tech companies (doubly so in the Bay Area) develop on Macs and deploy (servers) on Linux. There'd be little pressure to develop a Linux client since most devs are spending their day on a Mac.
7 replies →
From what I see, zulip-desktop appears to have Linux support...
https://github.com/zulip/zulip-desktop
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.
Every week I have to use a Cisco jabber client, Hipchat, Slack, and Hangouts within the same company.
I know it's got less of a "cool" factor because it wasn't invented last week, but I soooo wish everyone would just use IRC. Use irccloud if you want some nice apps and picture embedding.
23 replies →
They were on their way out as some services were federating via XMPP. Then some stopped supporting it.
34 replies →
At some point it did fade a bit. About 2-3 years ago enough people were using XMPP/Gtalk so that I could reach about 80% of my acquaintances thought it.
Now, there's no single network that holds over 25% of them. Except facebook, but most of them don't actively use facebook every day, nor pay attention to it's IM.
Best ask them first via email.
3 replies →
It would be nice if the iOS and Android built-in Contacts apps had better support/integration for all the various messaging apps that work on their respective platforms. Rather than trying to remember who uses which services, their contact card could simply contain the entire roster of their services and usernames, and you could initiate a conversation in that service from within the contact card. I know you can do this with the baked in messaging services for each platform (SMS/MMS and iMessage for iOS, SMS/MMS and Hangouts for Android), but I'm talking about a one-stop-contacts-shop for every major messaging platform. Maybe that would require too much cooperation between messaging app authors and the big OS vendors, but I think it would be possible.
An alternative solution would be a cross platform third party Contacts app that offers that kind of integration. I've seen multi-messenger apps (Trillian, IM+) for both platforms, but that's not quite the same thing and it inevitably leaves out important functionality from the official apps.
2 replies →
>more options means more (and easier!) ways to contact friends, family, and coworkers
utter nonsense.
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.
This is a very short sighted view. There is a real need for an alternative to IRC - and closed source products do not cut it when we are talking about communication.
What parent is talking about is a real problem. There's micro-ecosystems out there around specific closed source products, all of them centralized, none of them compatible... and in the mean time, the only real decentralized, open source group chat solution (IRC) has a lot of issues [1] which shouldn't exist in 2015.
[1] https://plus.google.com/u/0/+JeromeLeclanche/posts/icC6gDToB...
16 replies →
We have cross-organization Slack users in our company slack channels and I also have multiple 'organizations', so fragmentation is sometimes an issue.
1 reply →
Strangeloop (the programming conference) is using a slack, as we speak. it's more than teams :)
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.
Obfuscating usernames with real names and no ignore are also massive downsides.
2 replies →
And none of them manage to replicate even the most basic of IRC's network solutions in regards to user count scaling and server network combination.
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.
I also really dislike the idea of having to register with a phone number. I reminds me of ICQ, where I had to dig up some obscure number to log in. Except, I also lose my account permanently the moment I lose my phone.
"Mobile First"
This is the regrettable de-facto standard. I'd like to see the opposite: a network that provides native desktop clients. Telegram seems to be the only one taking this seriously up to now.
This looks cool.
FYI notifications is misspelled as "notificaitons" in the paragraph under "I don't believe in messaging. Email is better".
that would be great. what would be greater though is ensuring that actor.im cannot read the data as it transits (or easy to setup on our own local machines)
I'd pay a good bit for that!
1 reply →
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.
There have been and always will be competing products and communities that serve similar purposes. We use what we think is the best one. Is this a bad thing?
(Not to mention the fact that Slack is for internal teams, not for IRC-like discussions, though our open newsroom (http://newsroom.grasswire.com) and some other communities (http://fpchat.com) have repurposed it for that.
I think that "best tool for the job" attitude is a straw man. It seems to presuppose that "the job" is per-organisation, or even that there is one job.
In truth many of us believe that the goal is enabling everyone - universally - to communicate without a single body holding centralised control of message history, reachability and access.
Quick review of the globally federated protocols:
3 replies →
Yup, it's a big shame. XMPP promised for quite a while, but then stagnated and failed to deliver what most users were expecting (mostly due to implementations, not lack of protocol features).
I've recently given up on IM, and written about it recently:
https://hugo.barrera.io/journal/2015/09/21/giving-up-on-im/
If only zulip were federated. :(
> If only zulip were federated. :(
Now that it's open source, could it be made to be federated?
1 reply →
Wow, out of all the things that may have occurred to me over the last couple years of using Slack, "this feels like 1999" is definitely not one of them.
One could say that OS-level notifications could be considered a crude replacement of an aggregation tool like Trillian. We didn't have these back in the ICQ days and today it's easier (read: less painful) to listen on multiple messaging apps. Especially on mobile devices.
Amazon for a long time (maybe even today) used IRC for 1:N communication. I personally like IRC over anything else, but I am probably just too old... :)
<shameless plug>
We at sameroom.io do this in sort of backend-only way.
</shameless plug>
IRC+ZNC = backlog support, and WAY more. I don't know why you'd want anything else.
> I don't know why you'd want anything else.
Voice+video just to begin with. The ability to work on poor networks (mobile?), read notifications, delivery notifications.
+300.
You forgot Glip too.
"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]
[1]: http://www.inspircd.org/wiki/FAQ.html
See https://news.ycombinator.com/item?id=10280246.
Historically most users were using the single cloud installation at zulip.com, and so having this significant fixed memory overhead wasn't a problem.
I expect someone will do the work the fix this before long; it shouldn't be hard.
Thanks for the explanation! I take it that the open sourced zulip is very close to what zulip.com runs, then?
1 reply →
Who cares though? A 4 GiB stick of ECC server RAM is $35-50, which is only about $10 more expensive than a 2 GiB stick.
If you spent even twenty minutes of developer time trying to reduce memory usage, you've already lost money.
It may still be worth the total savings if someone solves it globally, but from the perspective of an individual company who wants to run this, it doesn't matter at all.
Posting this in a few places since it came up N times on this thread: I opened https://github.com/zulip/zulip/issues/34 to track optimizing the server-side memory consumption. :)
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.
Client looks cool, I will be downloading it.
For others who didn't get the PG reference:
http://paulgraham.com/ambitious.html
Yep. I like his talk at Pycon in 08, where he talks about building a better email client[0] but it is also noted in your link. Thanks, I switched back from mobile and meant to post it.
Incidentally, if anyone has seen his Pycon talk, one of his ideas is "Bring Back the Old More's Law", and if you are curious it is ~2-3 minutes here[1]. I have always been wondering what he means when he says a "sufficiently smart compiler is a byword for impossible" is this an AI reference or a deeper computer science theory that I am missing. Always been really curious.
[0]https://youtu.be/R9ITLdmfdLI?t=7m40s [1]https://youtu.be/R9ITLdmfdLI?t=21m38s
1 reply →
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.
I think HipChat might be the only one backing the XMPP horse still.
A timeline [1].
[1] https://cdn.sameroom.io/chat-timeline.pdf
HipChat, while providing the XMPP backend, and a self-hosted option, isn't cheap, and doesn't seem to provide the extensibility that an open source option would. But, it's certainly closer to the right thing than Slack (at least, from a surface level examination).
I guess it doesn't even need to be XMPP, specifically. But, some open standard and some level of interoperability would be nice. In googling I came upon matrix.org, which also seems promising, but has the same problem XMPP has of not having great clients (though I also found Kaiwa, which looks like a pretty good XMPP client with Slack-like features). Maybe one of these open source projects will formalize their protocol, and we can all move forward on interop with that.
4 replies →
Jebus. That chart is horribly depressing.
That chart is amazing (and depressing, as another commenter said). I counted and I've used 18 different ones. I've also used a few others for video and audio conferencing, like WebEx (unless that falls under a particular Cisco one in the chart, I don't know).
Currently I'm "only" using Slack, Skype, iMessage, and Google+ Hangouts (very occasionally, with considerable loathing).
It strikes me the situation is inherently ridiculous, but after not far off 20 years of dealing with it, I can't say it bothers me that much anymore.
Needs to be updated. It shows Zulip died in late 2014.
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.
(Patches welcome!)
Hi SwellJoe,
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/
In doing research today I see some valid reasons for not going XMPP. The question that raises for me is merely: How do these things interoperate going forward? I'm through with walled gardens, particularly with something as important as team communications. If not XMPP, then what needs to happen to allow any chat to federate with any other chat? And, perhaps equally important, how does one move data from one to another. Data lock-in should be on everyone's mind, but it always seems to be an afterthought (so far after that it doesn't come up until the disastrous occurs and your vendor sells out and closes up shop, or becomes like SourceForge and destroys user trust).
I don't mean to rant at you, of course. Mattermost looks great and it is open source, which means any complaints I have, I am free to put my money/time where my mouth is and fix it.
Have you had a look at IRCv3? Specifically capability negotiation - http://ircv3.net/specs/core/capability-negotiation-3.2.html
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.
[1]http://getkaiwa.com/
HipChat supports XMPP [0], and you can host it yourself.
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...
He writes more code than everyone else in the company combined. He does whatever he wants.
1 reply →
HipChat supports XMPP clients, but not federation, which is the interesting part of XMPP.
lets-chat (https://github.com/sdelements/lets-chat) works fine with XMPP and is relatively straigtforward to setup.
No plan9?!?!? I'm disappointed. :/
https://www.zulip.org/clients.html
Is it me or does the font on that page suck for readability?
Yup, it's terrible (Firefox 42 / Windows 8.1).
1 reply →
Can you provide a screenshot and what browser/OS you're running?
I'll look into it.
2 replies →
nope, it's pretty bad for me too. w10 with default display everything.
Contributions welcome :)
Maybe with linuxemu.
Side note: Please STOP using tiny font weights. Text becomes ridiculously hard/painful to read.
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
There is something wrong with your rendering. What system are you using? It looks to me like the hinting and/or sub-pixel rendering is wrong. I had a lot of problems with this when I moved to Arch Linux because Debian had done some default setup that I needed to figure out in Arch. Here are my xresources for xft if you are using Linux (probably formatted badly, but you can get an idea):
Xft.autohint: 0 Xft.lcdfilter: lcddefault Xft.hintstyle: hintslight Xft.hinting: 1 Xft.antialias: 1 Xft.rgba: rgb Xft.dpi: 96
It will give you a place to start, anyway. Main things you will want to change are the rgba and dpi depending on your monitor. The filter and hintstyle depends on your preference. Just make sure to turn autohinting off.
If you are using something else, then I'm not sure how to fix it, but I can tell you for certain that it is broken ;-)
Enough other people (who can read other websites perfectly fine) are complaining about breakage that it's pretty clear this site is doing something wrong. "You had one job ..." applies here. Body text on a webpage should be readable on all platforms.
2 replies →
Nothing is broken with my rendering or system. This is a fresh Windows 10 on a normal 1900x1200 24" monitor.
The font used is a fancy font with thinner strokes and then using a font-weight of 200 makes it that much smaller, making it illegible. There's no reason to make body text so skinny and it's often better to stick with normal system fonts.
Headlines and occasional larger text can have more styling. This is just a failure of design/UX on this site.
I'd be curious to see how the screenshot below looks on your system.
http://i.imgur.com/xCWBCcB.png
I'm not sure what you're asking here... that text looks fine but it's also much larger than mine. Are you on a 4k/retina/high DPI monitor?
I'm viewing on a 1900x1200 24"
The problem is not so much the font weight as the font itself. Time to abandon 'Humbug' on that site which is translating to SourceSansPro-Light-webfont at font-weight: 300.
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.
See also https://news.ycombinator.com/item?id=10280146.
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.
Hey tabbott, I'd love to chat about this more if you're interested, it's something we've been particularly looking for. My email is sina@eff.org.
White-label builds of Zulip apps would work, but at least in our case wouldn't be ideal. Having a central community-hosted service would be much better.
1 reply →
2015 The year of the chat clients
?->building facebook clones->building twitter clones->building slack clones->?
This does look like a good product though. Personally I like the style of this more than slack at first glance. Running your own server and being open source are awesome. I can't wait to see what people build on it.
Isn't Slack an IRC client with some project management features?
2 replies →
I thought that was 1999.
Everything is a cycle.
https://xkcd.com/927/
The worst part is, all those systems (we can't say clients anymore) don't even try to standardize anything. Which is understandable, because they feel like they're improving the usability situation. All they do is provide bridges to other solutions, but that's not helping on the protocol side.
Any idea why this uses a forked version of Django? I read through docs and skimmed the repo but couldn't find anything that speaks to this...
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.
For those wondering, it's Apache license.
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.
Zulip use RabbitMQ for passing messages where persistence is desired; last I checked Redis didn't support persistent on-disk queues.
Zulip's use of redis right now is basically just for the API rate-limiting; it could be easily removed.
Redis does have persistence options... I was just thinking Redis is often used as a more advanced memcached, while also supporting pub/sub channels and acting as a mq broker with a frontend... was just thinking in terms of reducing the requisite services, since rabbitmq requires erlang and it's own services as well as memcached.
http://redis.io/topics/persistence http://python-rq.org/
3 replies →
Commoditize the complement: http://www.joelonsoftware.com/articles/StrategyLetterV.html
"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.
There's no benefit to it only being able to reach some small group of people. There is benefit in being able to include only a small group of people in a particular conversation, but that does not require no interoperability, only a concept of groups and permissions and access controls. In fact, it is completely orthogonal to the lack of interop.
2 replies →
> 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).
Why would reinventing jabber federation require bitcoin?
To prevent the spam issues that made federation useless?
Looks wonderful, but am I the only one that thinks the recommended 4 GB server is a lot?
See https://news.ycombinator.com/item?id=10280246.
Okay, then given that it's open source, hopefully we'll see a smaller version soon.
1 reply →
Posting this in a few places since it came up N times on this thread: I opened https://github.com/zulip/zulip/issues/34 to track optimizing the server-side memory consumption. :)
Dropbox has great designers, surprised they couldn't have found a few hours to spruce this up in the year and a half since it was acquired :)
My thoughts exactly. It's not awful by any stretch of the imagination, but Dropbox has traditionally set itself apart on design.
A couple of Zulip questions:
1) Is there any support for federation? At first glance it looks like every installation might have multiple servers, but more for balancing load, than federation?
2) How well is the protocol specified? How hard would it be to par down the requirements to eg: just python and sqlite/lmdb or redis (or zodb...)? Say if one wants to support just ~100 users or so?
(1) Not currently, though you can certainly imagine doing it and having it work well; the core data model doesn't change very much over time.
(2) There's a reasonably well-specific API, and you could imagine building an independent implementation that fit that API and feeling good about doing so. But I feel like that would probably be a lot of work and you could probably much more easier achieve whatever your actual goal without paring down the dependencies very much.
E.g. the relatively high minimum recommended RAM for a Zulip server is mostly due to running 20 Python processes for all the queue workers, most of which are idle all the time. If we wanted to decrease the memory requirements, there's a variety of ways to solve that problem directly that are a lot easier than doing a rewrite :).
It looks cool that said as usual its "hey I dont like <insert some chat program> so im just going to code my own incompatible one".
In the end im happy with IRC. Its not the greatest but its the one that just works: Its the one everyone who's an engineer in the business knows how to use, bots work, automation work, and irccloud works if you like webuis.
Wow. Good luck installing this. I'm not touching it. It needs to do all sorts of hokey things to work. It needs puppet and git to work? You can't just install python packages, it installs them from a ppa. Deployment is a huge mess. It doesn't have to be this hard.
Thanks for the feedback. We prioritised getting this into a state where it can run in dev and production based on the existing deployment processes we used in our own environment.
I'm working on a Debian package[1], and we expect to iterate on the deployment process in general.
1: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800052
No mention of Skype? It seems like every one of my business contacts is using Skype to chat.
What do Zulip / Slack / Hipchat / IRC / ... people do for screensharing and (group) voice calls?
We'd love the chat improvements, but without screensharing and voice we're stuck on Skype. :(
There is also Chromebox for Meetings[1]: https://www.google.com/work/chrome/devices/for-meetings/
https://github.com/jitsi/jitsi-meet
Hipchat does screensharing and voice/video (although not yet group).
Has anyone switched workplace chat from skype to something else? I don't much like the chat bits in Skype but on the other hand the voice bit is fantastic. I can't imagine having to manage two separate contact lists for chat and voice, so I'm reluctant to switch to something that doesn't have good voice or integrates with something that has (e.g. launch group call from a chat conversation).
Nice, it looks like an excellent Django app to study.
If you're looking for interesting elements, the REQ framework for doing argument validation I'm pretty happy with and have been thinking would be good to try to extend to be part of Django upstream.
Good to see it be open sourced. I'm disappointed there's no XMPP gateway, OTR chat encryption or Gitlab integration however.
There's a Git integration that you can use with GitLab or anything else that supports post-receive hooks. But it would be cool if someone contributed a more slick GitLab integration :)
Also there is a beta XMPP gateway at bots/jabber_mirror.py that can mirror traffic with an XMPP setup. It's beta because it's kinda annoying to setup; feel free to reach out on the development list for help if you have issues setting it up.
One note is that the a key feature of Zulip is thread-level topics which aren't really supported by XMPP; see https://news.ycombinator.com/item?id=10280817 for more discussion of this.
Ah good to know - thanks for the info.
I just spotted this though: "Currently, the automated Zulip server installation process only supports Ubuntu 14.04 Trusty"
Not at all keen to run Ubuntu, if it was available on CentOS 7 or Debian I'd give it a go but I guess I'll hold off for now.
1 reply →
https://github.com/zulip/zulip/issues/33 is open for adding a slick GitLab integration
Wow. Great news. Very good alternative to slack.
The 'Or use the web app' link on the frontpage links to the list of desktop clients instead of the web app.
Thanks for pointing this out! Will fix.
No linux client? That's a deal breaker for us right there... Pity, looks interesting otherwise.
There is a Linux client! You can build it from source right now, and prebuilt binaries will be available in a PPA soon.
Prebuilt binaries aren't available quite yet because it's a lot easier to submit to a PPA once you're already open source :)
Thanks, will check it out!
Wait a week, someone will develop one.
There is a web client for it.
is this something like slack?
yep - very similar but with an emphasis on self hosting.
Check out: https://zulip.org/ and https://zulip.org/features.html. The biggest difference from something like Slack is the threading model, which is documented in some detail on those pages.
Would nice if it were easier to self-host. Requiring Ubuntu 14.04 with 2GB RAM minimum...not terrible, but could point at a lot of work to be done to broaden the appeal. (Edit: And of course, a thank you to Dropbox for releasing it, this does look like a nice little setup)
5 replies →
Also open source (which means it can be extended / modified / etc).
Does anyone know if Zulip has support for directory integration? whether it's OpenLDAP or MS AD. Hell, even RADIUS would be ok by me... @@
LDAP is supported:
https://github.com/zulip/zulip/blob/b69c6228af03634061cba29f...
Also, generic webserver-side REMOTE_USER authentication is supported.
thanks~! Going to try it out then =p
Why did Dropbox build this? Why didn't they just use Slack? What were the features slack was missing or were there other business reasons?
They didn't build it; they acquired the company that built it.
Oh, I'm interested in the business decision behind that. For example why didn't they just buy (not acquire) the slack product. What were the reasons to host it in-house and manage it themselves.
13 replies →
#googlewave
Anyone have recommendations for a free SSL cert provider so that I can test this out?
Those bastards!! Got me all excited with the Plan 9 tease. ;(
indeed a great move, the part I don't get is that why dropbox acquired it then opensource it? what's the logic behind this...
I have the same questions too. Acquihire?
Also, how is zulip compare to slack in term of features, stability, pro/con?
I tried search youtube for any zulip demo/screencast, can't find anything - very strange.
No one mentioned gitter.im, weird...
Reminds me of https://euphoria.io
who cares. seriously. group chat is a solved problem.
looks like a great codebase, both django and ios!
LDAP support?
We have an authentication backend for that:
https://github.com/zulip/zulip/blob/b69c6228af03634061cba29f...
Someone should tell those web developers choosing those fonts that not everybody has a damn Mac.
https://i.imgur.com/MciirNR.png
It looks a lot better on my Linux laptop! We're investigating.
I have found bugs on that installation guide. For example it tells you to install the certificate chain to
/etc/ssl/certs/zulip.combined-chain.crt
But nginx looks for it in
/etc/ssl/certs/zulip-combined-chain.crt
Also during your installation you download this deb file to
/root/zulip/python-django-guardian_1.3-1~zulip4_all.deb
But the script then tries to install it from
/root/python-django-guardian_1.3-1~zulip4_all.deb`
1 reply →
Is it possible to have secure chats that the server cannot read?
cool