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 think my blog post covers pretty well why we open sourced Zulip: https://blogs.dropbox.com/tech/2015/09/open-sourcing-zulip-a....
Hopefully if it's a truly valuable tool it will be forked and audited.
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.
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.
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.
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.
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...
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.
This is not our main feature, just something like side project.
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.
FYI notifications is misspelled as "notificaitons" in the paragraph under "I don't believe in messaging. Email is better".
I'd pay a good bit for that!
(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.
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.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. :(
Now that it's open source, could it be made to be federated?
We at sameroom.io do this in sort of backend-only way.
</shameless plug>
Voice+video just to begin with. The ability to work on poor networks (mobile?), read notifications, delivery notifications.
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]
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.
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.
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.
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
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.
A timeline [1].
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.
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.
(Patches welcome!)
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/
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.
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...
There's no reason to use a font-weight of 200 (or anything less than 500) on body text, save that for the headlines.
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 ;-)
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'm viewing on a 1900x1200 24"
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.
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.
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.
* 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.
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.
Zulip's use of redis right now is basically just for the API rate-limiting; it could be easily removed.
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.
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.
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).
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?
(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 :).
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.
I'm working on a Debian package[1], and we expect to iterate on the deployment process in general.
We'd love the chat improvements, but without screensharing and voice we're stuck on Skype. :(
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.
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.
Prebuilt binaries aren't available quite yet because it's a lot easier to submit to a PPA once you're already open source :)
https://github.com/zulip/zulip/blob/b69c6228af03634061cba29f...
Also, generic webserver-side REMOTE_USER authentication is supported.
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.
https://github.com/zulip/zulip/blob/b69c6228af03634061cba29f...
/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`
