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).
Thanks! If I read https://www.recurse.com/blog/90-zulip-supporting-oss-at-the-... correctly Dropbox has helped to open source it but will not dedicate engineers to it. In that case it is interesting that you'll have to sign a Dropbox CLA to contribute https://github.com/zulip/zulip#contributing-to-zulip. But even with that, the code is under Apache 2, it is great that Dropbox took the time to properly document everything and open source it. At GitLab we now bundle Mattermost and we're working with Rocket.chat to bundle that. I wonder what the demand for Zulip is, it looks really full featured.
Sytse, we use gitlab enterprise edition at packetzoom (Our VP eng is a major gitlab contributor). We'd love nothing more than have a proper chat system with good native clients. Slack has excellent UX and mostly decent native clients but the pricing and/or holding our chat logs hostage has always bugged me.
Please consider integrating zulip. Though even without gitlab integration, we'll still try it out anyway.
Although Zulip is far ahead of other open source solutions we are leaning towards Rocket Chat. Javascript and Meteor are the most popular language and framework so it would be easier to contribute. It is not who is ahead now but about speed of development.
Zulip is very heavy, they recommend 4GB for a production installation. This is due to the 15 workers that are not multi-threaded (GitLab has multi-threaded background workers).
We're proud that people can run GitLab on a Raspberry Pi 2. Forcing people installing the whole GitLab suite (GitLab itself and chat) to have a 8GB server is not acceptable. We're still hoping for multi-threaded unicorn foreground processes in GitLab so we can run it on 512MB.
By the way, Rocket Chat has 'native' clients on Android and IOS, although I think they use webview inside them.
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. :)
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?
There's a big difference in scope and impact between merely teaching somewhere and being on the Board of Directors and running it. It's not equivalent.
She was Provost there from '93 to '99, which is a little more than teaching [1]. I think that while her willingness to go with the Bush administration's extremist positions (on torture and surveillance, especially) are a dark mark on her career, Dropbox is worth dropping for wholly different reasons (e.g. technical incompetence [2]) than who is on their board.
1. "As the chief academic and chief budgetary officer of the University, the Provost is responsible for administering the academic program, including both instruction and research, and for the coordination of the administrative and support functions of the University with its academic purposes." (https://provost.stanford.edu/)
To be fair, though, her provost tenure there was before her tenure in the Bush administration, where her most egregious acts took place. You can't blame them retroactively for not knowing what a monster she would reveal herself to be in the future.
I disagree. As a professor at Stanford, she's teaching the future rulers of the world how to rule. At Dropbox, she's showing up to board meetings and taking a salary.
Her teaching at Stanford is the same sort of trophy namedropping photo op that being on the board is. You can't actually get a PhD in Hegemony from school.
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.
Everyone at my work (a big company) has Linux desktops. Granted we wouldn't use Zulip, or anything else hosted externally for that matter, but this does create a large demand for other types of software running on a Linux desktop from us, e.g. IDEs.
I've been using linux on workstation for last 6 years. I have to run VM with Windows, only when i have to interact with some Microsoft product directly. It may not be ideal solution for every use case, but it works.
> Linux Desktop will never be more than a VM host or Web Browser host.
I did mention this on a developer-specific context. AFAIK, most developers tend to use Linux nowadays - at least in all the companies I've been in during the last 10 years, windows users have always been a minority.
(YES, I'm perfectly aware that this is not true for average users, or anything outside IT).
That's probably not true[0]. In my experience you would often endure belittling or sheep calls, even bullying, if you walk into the office with a MacBook or an Iphone. We've customers where it's not even allowed to store corporate secrets on non-linux os. But that are highly professional financial or insurance dev corporations.
I'm confused about what the linked dataset is supposed to show as it doesn't seem related. In any case, I've certainly noticed ancedotally that MacBook usage is quite high.
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.
Is it possible to get what Slack provides using IRC? I mean the whole package, not just the text chat. Consider enterprise-friendliness, excellent mobile clients, zero-setup required (no separate keep-you-online relays), really easy integrations, etc.? We are adopting Slack because it's great and I'd have loved to make a case for IRC but I wouldn't know what server to recommend (we don't really want to install it, but we don't want to use a public server), where I can get commercial support, if there's a nice client (like irccloud is) for mobiles - there's a long list, unfortunately.
Also in-client searchable archives, media handling, history editing. All require going outside the IRC protocols.
IRC was designed by hackers, for hackers and it shows. Twenty years ago, IRC was my talk destination of choice and I operated a server within a major IRC network; these days my startup uses Slack which I determined to be the "least irritating" of the 21st century options.
I had high hopes for Google Wave but it was sadly stillborn.
Much of that can be had with a IRC bot. That doesn't include media handling, but you could do search via 1-on-1 /msg (query) with a bot. Then it'd truly be "in client" search.
Most would probably prefer a web ui, with search -- but recording chat could still be done via a bot.
I wouldn't say you could get most of the whole slack experience with just IRC, and you'd probably have to do some work (if only configuring channels/bots/find a web ui etc).
This doesn't resolve the multifarious issues with identity, reliability, scalability, federation, standardisation &c &c that further rule IRC out from being the universal panacea.
I stopped reading when the charter said "we are not working on the server protocol". The server protocol is the limiting factor in IRC's architecture.
My interest is in federated, reliable, ad-hoc messaging and IRC's acyclic forwarding graph and lack of any inherent identity model make that impossible.
It depends on the context. You can't federate with Google, Microsoft, Facebook anyway -- and you won't convert the world to use your favourite new protocol (most likely).
So that just leaves you with an easier problem: how can I host conversations etc for my team/org/my friends? And I think a single, isolated irc server should work fine for that use case, and work fine with many different irc clients?
So no, it's not a universial solution -- I just think it's strange when people bring up slack as somehow "better". Sure it's "better" in that it's a product with backing from some fine people -- but if you wanted a solution based on open standard, Free code that you could self-host without worrying about license costs etc ... then a battle-tested IRC server still seems like a half-decent option?
Or put it a different way: if you have 100s of users, could you get many of the features with IRC, and some bots? (Or maybe a slightly tweaked IRC server etc etc)?
[ed: Not that I claim there aren't problems with IRC -- and I've yet to run a personal ircd, so I don't know a) how much work it is to force TLS+SASL[1] and disable plain IRC, or b) if there are other solutions that might be better, that are available right now.
That is not an "easier problem" - that is repeating the problem: yet another venue/client/service we all have to be logged into to find one another.
Moreover, I'm really not interested in spending any time whatsoever on configuring and maintaining an IRC server and a fleet of bots, nor on teaching non-technical users in how to use the resulting heath-robinson system. Really, no. A world of no. I have run both a private IRC service and a public node of a very large network. It's a huge time sink. I've moved on.
As I see it, the only problem in this domain worth burning hours on is developing a protocol (and interoperable implementations thereof) that achieves everything the likes of Slack and Hipchat can do, only in a decentralized and federated manner.
> that is repeating the problem: yet another venue/client/service we all have to be logged into to find one another.
I'm not sure how you can create a new venue without creating a new venue? Perhaps have Google/Facebook/Microsoft/BigCorp create one for you, and the use that? But none of the big players appear to care a whit about facilitating a distributed, self-hosted, open Internet, so that is not going to happen?
> As I see it, the only problem in this domain worth burning hours on is developing a protocol (and interoperable implementations thereof) that achieves everything the likes of Slack and Hipchat can do, only in a decentralized and federated manner.
Any particular reason why you think IRC is inherently not a good building block for such a set of protocols/implementations? I'm not talking about IRC with legacy client support, I'm talking about a system that explicitly breaks comparability with legacy IRC, but still try to build on the years of experience and battle-testing IRC has.
You might be right that it's better to burn IRC to the ground, of course. My takeaway (as an observer, not a server operator in the trenches) is that one takeaway from XMPP/IRC is that:
1) We need authentication of users
2) We need authentication of servers
3) Today, we have no need of plain-text; encrypt and authenticate, or go home.
It appears that 1+3 leaves us with TLS-only, SASL auth if we go the IRC route. For 2) I suppose manual mediation of some kind (eg: server certs with Trust-on-first-Use, possibly a community blacklist?). I'm not sure if this would work, but on the surface it would appear to enable less spam and better security than email currently does.
And it should be much easier to strip down/adapt existing clients and servers than to build an entire new stack?
All that said, it might very well be that IRC server-server federation is hopelessly broken, and there's no hope.
Perhaps some kind of server-auth/community-web-of-trust framework on top of XMPP federation would make more sense?
But it's not possible to get what you're asking without breaking the IRC protocol - it's not easily extended and the formatting rules are icky mIRC crap.
The trick with capabilities is you need them to be reasonably standard. Which means the go to IRCv3 server should ship with them turned on, and the reference client should be capable of using them.
I didn't make the decision. Slack started to appear and I didn't know that IRCCloud had apps (which seem to have great reviews). If I had known, I would have suggested it as an alternative. As it was, I just kept quiet as Slack seemed great - even better than HipChat, which I used to use for the same purpose.
Perhaps IRCCloud could be sold as a rebranded Enterprise app as an alternative to Slack? I'd love to see some competition as it looks like only HipChat and Slack are getting talked about.
That sounds like a problem with the company. I can understand Slack and Hangouts (at least until Slack adds voice chat), but all that other stuff sounds like poor organization on the company's part.
What I posted in another thread still stands - https://news.ycombinator.com/item?id=10256943. Things were better when everything was brought under one client. I know iMessage is almost impossible to reverse-engineer (due to Apple kicking non-iClients off) but I wish there was more effort going into reversing Hangouts. Someone's emulated the JS client from GMail but that's about as far as it's got
IRC's lack of scrollback alone kills it for these considerations, unfortunately. If there's an incident or discussion in progress and you only join the room partway through you have no way of catching up to speed.
Sad as it may be, it's pretty clear at this point that XMPP won't be the communication protocol of the future. Everyone who ever seriously worked on it seem to have come out of the experience a broken man. Setting it up requires pretty deep knowledge and the promises of compatibility with most XMPP servers break down pretty fast unless you know which extensions to support.
All these problems are fixable but I don't see the tide ever actually changing direction and "hey suddenly XMPP is cool again, we should all use it".
One thing is for certain... humanity needs standard, open and widely-used protocols for communication. And there's a lot of ground to cover: Text, audio, video; single and multiuser; topical (IRC-like); social (invite-based/people I know); Synchronous (IM) and asynchronous (email/offline messaging)...
XMPP tried to do a lot of that. Maybe it tried to do too much. Maybe you just can't do all that in one protocol. I don't know, I just hope we'll get there soon - if nothing else, I'm tired of maintaining those "best way to reach me" charts JoshM33k is talking about.
I didn't just make this up on the spot, I've been dealing with these issues for years. So yes, I've thought about them a lot.
I used to run a prosody server on my home box. It is great software and a fantastic daemon compared to ejabberd (edit: Configuration-wise that is) but fat lot of good that does if you don't know what XEPs to set up when dealing with other servers. I shut it down because it was pretty much useless and I wasn't able to talk to my gtalk buddies from it anymore.
> fat lot of good that does if you don't know what XEPs to set up when dealing with other servers.
I have no idea what XEPs to set up when dealing with other servers. I did not have to set up any such thing. Like I said, federation (server to server communication) works out of the box, at least on Debian.
Yap. Agreed. XMPP looked good on paper, if you read just the mission statement. Thinking back, I tried to dive into it once and nope-d out of it quickly. I guess I just blocked that experience out of my mind for some reason.
One of the best things that could happen today I think is Google open sourcing the Hangouts protocol. It's a reasonable alternative to XMPP and has a massive userbase. The clients are pretty horrible but that might be completely unrelated to how good the protocol is (Note: I have no idea how good it is. Because it's closed source.).
I was hopeful for a while but I don't really see it happening anymore :( Oh well...
Edit: Oh and the worst part: Communication is just one side of that coin. The other side is identity and it's one hell of a side. OpenID was a disaster. Mozilla got it mostly right with Persona but completely botched the marketing and has all but given up on it now. There is no decent foss protocol for identity/authentication today other than Persona, and nobody is working on one. There was a time indeed where I could've pictured Google working on solving this just for the hell of it. Just because it would improve the world. That Google is gone, and there's nobody with the appropriate reach that seems willing to do it now.
What notatoad said, plus I don't think they're maintaining things very well any more. Last time I tried to use the ecosystem, various non-core things were breaking. Huge pity, it's a very well-designed protocol.
Persona was great and it's a bit sad to see it dead after investing a lot of time in it but - one big architectural problem was there was no way to support delegation (the problem OAuth was originally designed to solve).
Has anyone got experience with both XMPP and SIP/H.323? From what I've been able to figure out, H.323 looks like it's one of the better candidates of protocols that exist today and is "reasonably" simple... while SIP... well, SIP smells a lot like it came from big TelCos. And not in a good way.
> Has anyone got experience with both XMPP and SIP/H.323?
I've worked with all three. The H.323 vs SIP battle was fought a long time ago... for better or worse, SIP won. Any H.323 systems still in the wild can probably be considered "legacy."
That being said, while H.323 has more "batteries included," its call flow is accordingly more complex. SIP is not too bad, there is some subtlety to it, but the main issue is that you have to piece together dozens of RFCs for an interoperable system, not to speak of implementation-specific quirks.
XMPP is the more appropriate protocol in this context -- IM and group chat -- because it has had presence and ad-hoc messaging baked in from the start, including reasonably supported MUC. Ultimately, XMPP's issues are similar to SIP's -- the patchwork of XEPs is too unwieldy to work with. For an example, compare the multimedia bits (eg, Jingle) and the corresponding SIP session setup flow. The stigma of being a XML-based protocol designed in the 90's doesn't help, either.
The biggest reason SIP is sticking around, however, is that it has major buy-in from the telcos with IMS/4G. However, SIP is also a more appropriate protocol for traditional telephony. In that respect, comparing SIP and XMPP is a bit like comparing apples to oranges. With the appropriate extensions, one could behave like the other, but it wouldn't be their strength.
If you know your requirements up front, then it's not hard. In fact, it's a good exercise to do so -- probably one reason why messaging systems are a dime a dozen nowadays. What's hard is making a messaging system that is everything for everybody. If SIP or XMPP has taught us anything, it's that "extensibility" is a killer. Requirements evolve, and often it is perceived as easier or "cleaner" to start from scratch, rather than work around the idiosyncrasies of existing systems.
On the other hand, if you are trying to design a protocol to solve a domain specific problem (eg, in cryptography, multimedia, distributed systems, etc) then it becomes more of a research endeavor with all the associated pitfalls. In that case, there will always be the "shoulders of giants" to build off of. Unfortunately though, for every pioneering TextSecure, there are a dozen CryptoCats repeating the same mistakes of years past...
Sigh, sorry to hear that. I was hoping h.323 might work well for a personal call system with the option of ditching regular cell service. And just try and brute force most communication through h.323 :-/
It seems obvious multimedia calls is part of our future, and I refuse to let that be dictated by corporate lock-in -- be that Skype/Lync, Hangouts or whatever Facebook will launch when they enable videochat. And any videochat/conference needs text messaging/conversations too, so it seems like it would be nice to run everything through one server/service.
Which I had hoped made sense would be a h.323 server (along with open source clients+maybe a websocket/web-client bridge).
Guess it'll have to be SIP for phone (so I can ditch my regular cell service), maybe SIP for videochat (but I'm sceptical about the videoconferencing bit)... and XMPP for messaging.
As neither Facebook, Google nor Microsoft support either XMPP in general (making it feasible to set up a bridge server) anymore, nor federation (which would actually be useful), I suppose I'll just have to give up on the idea that there'll appear a chat network where I'll be able to reach most of my contacts with a Free/Open client that isn't forced to play catchup to corporate whims.
For a while, Facebook via XMPP worked (but not group chat), now it's back to sms. Which is annoying because sms is gated by the telcos, although it should be easy enough to make a xmpp<>sms gateway (eg: [s]) with a spare android phone. For personal use that wouldn't have to incur any sms fees (but would mean keeping a non-free cellular plan).
[ed: Forgot to commend duckduckgo and fastmail on hosting proper XMPP with federation and registration (at least ddg[d]) enabled. That's one reason why XMPP is nice -- you can actually point non-technical users at a suitable client, and add a couple of screenshots how how to set it up with ddg -- and they can then federate/talk away (that is assuming you don't/can't/won't support registration on your own server -- in my case the main reason not to recommend people wanting to talk to me to register on my server, is that I wouldn't know what kind of "SLA" my own server would have -- so if they used XMPP for other things than talking to me, having an account with someone a little more dedicated to keeping a server open to the general public might be better. But the main point is that that just works with XMPP today. And it should've just worked with both Facebook chat and Google talk/hangouts/newnamehere. And it probably also should've worked with Microsoft accounts/skype/hotmail.
> I was hoping h.323 might work well for a personal call system with the option of ditching regular cell service. And just try and brute force most communication through h.323
I guess you could try to run H.323 through a $protocol bridge, but I don't know why you would want to. Retrofitting modern features onto H.323 does not seem like fun. Because if SIP suffers from being too general, H.323 suffers from being way too specific in its architecture and technology requirements -- read through some of the associated specs, eg H.245, and it's not hard to see why SIP won. For the longest time, there was not even the notion of URI addressing...
> SIP for phone ... maybe SIP for videochat (but I'm sceptical
In SIP (and most well-designed protocols), there is no fundamental difference between an audio and a video call. It's just capability negotiation and RTP. Actual interoperability is the problem... and that is one of the reasons vendors like to create closed networks, so they can guarantee the experience end-to-end.
Regarding gating and lock-in: Part of it may be a desire for a proprietary walled garden [1], but a big reason is logistical as well -- one of the reasons Google disabled XMPP federation was because of abuse. This is the same reason you can't dial directly into the PSTN without going through a trusted trunk, and why unlicensed use of cellular frequencies (or any RF, really) is illegal.
[1] Actually, the reason the PSTN is federated is probably more an accident of history than anything else. If not for the AT&T monopoly (and subsequent breakup), people would have been complaining about siloed telephone services 50 years ago! See Tim Wu's The Master Switch for a nice treatment of this.
Right. Interesting that XMPP in many ways reimplemented some of the problems of both IRC and USENET wrt. federation.
> Retrofitting modern features onto H.323 does not seem like fun. Because if SIP suffers from being too general, H.323 suffers from being way too specific in its architecture and technology requirements -- read through some of the associated specs, eg H.245, and it's not hard to see why SIP won. For the longest time, there was not even the notion of URI addressing...
Sorry to hear that. My general thought was that for a personal system, it would be way lower barrier to use existing h.323 server/clients, than to make a whole new protocol -- and that's probably true.
But if it has been effectively abandoned for a while, SIP might be better -- even if what one might effectively end up with is "proprietary" SIP, as one picks a subset that works for a particular use-case.
Personally I have to complementary goals: The first, and most important, is to build something that allows group chat with archiving, hopefully integrated with optional audio/video and some kind of media sharing (be that wiki, or something more traditional like straight up sharing of files/documents) [But it it should be obvious that by uploading to a wiki with shared authentication/authorization, one would only need to share an url over chat].
The second goal would be to enable federation, at least among those with the know-how/interest in running their own nodes.
Oh, and goal zero would be to retain control, so self-host (although option to get it "on tap" as a service would be nice), and Free/Open software/protocols.
In the end, perhaps XMPP along with just video/audio via WebRTC turns out to be the least worst option. I'm a little worried that the "web-centric" solutions like Mozilla Hello/together.js etc is difficult to pair up with command line clients, bots and/or make accessible for those that need it (eg: braille terminals). I guess audio might be preferred to braille in the general case, even for asynchronous messages, but text is very flexible (eg: text-to-speech system exists).
I was the editor of the H.323 spec years ago. Funny you would say that SIP looks like it comes from the telcos, when the whole aim with SIP was to create just the opposite. H.323 has often been accused of being created by telcos, too. Truth is, folks from the traditional enterprise voice equipment makers shaped both.
SIP was adopted by 3GPP in 1999 to be used in the mobile networks. Of course, that trickled throughout the telcos, so it now is widely used in the telco space. H.323 was widely used for PSTN backhauling to reduce tolls. However, SIP is more prevalent there, I'd guess.
Enterprise networks still use both H.323 and SIP, with more desk phones using SIP and videoconferencing equipment split, but moving to SIP.
That said, any move to SIP these days is only because there is nothing better. WebRTC is the next big thing. It borrows SDP from SIP, but no signaling protocol is defined.
Personally, I'd like to realize the vision behind what was intended to be H.325, which was to be a JSON-based signalling protocol that is fully distributed. Each application could implement whatever protocol it wanted, and they would all be associated through H.325, giving the user the feeling that these different applications work closely together. That would be possible, even when applications run on different devices.
Alas, there seems to be no financial motivator for those that control the market to explore that concept, so we're stuck with H.323, SIP, and WebRTC (and various proprietary glue pieces). The trend these days seems to be toward proprietary solutions, providing limited interop with others through SIP. Limited, as in nothing but basic voice and video.
I recently discovered DTLS and QUIC, of which DTLS appear to be most interesting as a "general use" thing. We do of course not actually have a shortage of protocols, but it'd be nice to have something that was a little more suited for the "new" Internet. Full authentication/encryption, something lighter than TCP for multimedia -- and something that actually has a hope of crossing cheap DSL routers.
QUIC looks interesting, but a) is very concentrated on being a transport for http/2, b) is in flux, and c) Google apparently haven't donated any code that makes sense for production (excepting client-side in Chromium).
DTLS is closely connected with WebRTC, has several implementations (though, apparently no support in Erlang/Elixir yet?) and given the current push behind WebRTC appears to be here to stay.
Honestly, I don't know how interesting "hardware phones" are anymore. As long as one can get something to work over wlan with android, things "should" be real-world deployable. And I don't have 100s of SIP devices, so I don't need to care ;-).
It may turn out that wlan+android+WebRTC+DTLS never achieves the kind of latency needed for good live video/audio... I haven't experimented that much, but hopefully it's "good enough".
At any rate, appears that SIP really is the only interop that currently works. At first glance it does seem a little complex for the use-case of text messages, inconvenient in terms of addressing -- but maybe a core focused on WebRTC/IPv6 with gateways for SIP the way to go.
Either way, I guess as long as no big players want interop, it doesn't really matter. One'll just have to make a solution that works for inter-org/inter-friends communication, with the option to federate with those interesting in joining/building a new network. Doesn't look like it'll be easy to take a bite out of FB Messenger/Google Hangouts/WhatsApp etc.
Identity is a separate problem. So far, https://www.accountchooser.com and OpenID is winning -- if by winning you mean maintaining a list of very popular email providers and using their APIs. ;-)
Yeah, I can't see Google ever either open sourcing Hangouts, or making it possible to federate it. Google's opinion seems to be that everything that is a service or protocol should be a Google API.
I remember reading about matrix when they first announced. Was pretty excited about it, haven't heard anything since. I
It's just tech though; even if it's mind-blowingly great, won't do much good if no large-scale userbase picks it up somehow.
We're still alive and going strong - currently supporting glossy client development like Vector.im and building out bridges to as many other networks as possible (IRC, Slack, HipChat etc) using http://github.com/matrix-org/matrix-appservice-bridge and similar. In terms of being picked up by a large user base... yes, we need it if we are to be really relevant. And that means relying on folks like those commenting on this thread to try using it, contributing to it, and help us make it better.
Whilst we're not trying to replace XMPP, Matrix.org does provide an entirely different architecture (decentralised and evetually-consistent history, high baseline feature set, HTTP-based, etc) that can be used for group chat/VoIP/etc.
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.
I don't even know my girlfriend's email address. I'm 30, and she's only a few years younger. The world is strange now.
I miss Google Wave. Not the messy implementation, but the promise of a big influential company throwing its weight behind a modern, open communication protocol.
This. This was how I learned that the whole "don't be evil" thing was a load of bovine manure.
Google Wave, as an XMPP-based protocol, held enormous promise as a federated rich discussion standard. Sadly their first implementation was clunky and had a confused approach to standards and integration; it was effectively stillborn.
Then Google killed Google Talk by strongly favouring their closed "Hangouts" product which is practically inaccessible from chat clients. They went further, making it impossible to federate Google Talk to other XMPP services. Facebook and Microsoft followed suit, either ending XMPP support or closing their federation capability.
All three are therefore complicit in the worst abrogation of Internet interoperability since the early days of MSIE. And Google, in a land grab for consumer eyeballs, was the cheerleader.
Weird. I'm 30 too and I know all of my acquaintances' email addresses. How do you not know your girlfriend's email address? You can't even do something as simple as forwarding her your travel tickets so she knows your itinerary, or a receipt for concert tickets so she knows when it is, or send out a group email with details of the time and location of your party, etc.
Email was drifting off for me a handful of years back, but ever since smartphones ascended email has experienced a huge resurgence. I'm likely to use it in preference to SMS for (a) longer messages and (b) messages with multiple recipients (e.g. your standard activity planning emails).
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.
That they don't on Android is due to the app, not the platform - if the client adds contact integration, it gets listed in the contact's card. Lync, of all things, is a good example of this. I'm pretty sure Skype does too.
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.
>This is a very short sighted view. There is a real need for an alternative to IRC
There might be one -- but this is absolutely not what this and Slack are aiming to do.
>and closed source products do not cut it when we are talking about communication.
Not sure about that. As it seems, for 99% of the world who only uses "closed source products" for chat, they do cut it.
(Interoperability is orthogonal of course).
Slack and IRC are room-based, semi-synchronous, topic-centered communication protocols with support for direct messaging.
Slack literally took the concept of IRC and put a bunch of cool bells and whistles on it. They updated it, centralized it and sold the idea as an enterprise solution. It works great, and the tech could be a kickass replacement to IRC, done correctly.
I don't really disagree with you... but I often wonder how much Slack actually adds to IRC. We use it at work (and as a 100% remote person in a mostly co-located team, it is a godsend). I can't really think of anything in Slack that wouldn't be easy to implement with IRC bots.
Persistent history is easy. Email notification is easy. Storage of various assets like text snippets and pictures is easy. I've never used any, but I'm assuming that at least one of the web interfaces for IRC works well...
I think the main thing that Slack has done is package it up so that you don't need to cobble together 100 different things -- which is, of course, very valuable. Or at least more valuable than the monthly cost that they charge ;-)
To be honest, I would really rather be using free software. I would be quite happy to pay for a service that made it easy for me (as Slack does), but software freedom is valuable to me.
I've wondered the same. Like you said, though, there is value in packaging useful features together.
IRC is "You could do that ...", while Slack is "You can do that". So like you're saying, you could set up a bunch of channel bots (And for what it's worth, I think channel bots are fairly ugly. If I say "Let's work on #133", I want #133 to be linked, I don't want a different user spewing 3 lines of noise and a long link). But most people won't do that because it's too much of a hassle. So most of IRC does not showcase what's really possible.
Like I mentioned in the g+ rant I linked above, it'd be possible to improve this by adding scripting features and such to IRC servers. But nobody's doing that. The harsh reality is that "could" is a long, long way from "can".
> To be honest, I would really rather be using free software.
Me too, man. Me too. I don't use Slack out of principle, and I'm a heavy IRC user. Sadly it doesn't often compare :/
> There might be one -- but this is absolutely not what this and Slack are aiming to do.
That's kind of a weird statement to me, because every time I've sold a techie-type person on Slack it's been by describing it as "private IRC with persistent history and a bunch of other neat things".
You're missing the point. Just because it's not what they're aiming to do doesn't mean the tech isn't appropriate for it.
You're commenting on their business model rather than the tech. For all you know, Slack could be planning to expand their business to hosting public chat rooms, then your comment wouldn't make any sense anymore.
You can already get a hacked up public chat via Slack. There's a package (which is all set to run on Heroku) that automates the process of sending an invite to the Slack organization so that anyone on the public web can do it.
I noticed this when the Bootstrap 4.0a announcement had a link inviting you to join their Slack:
> For those jamming on v4 with us, we also have a dedicated v4 Slack channel. Jump in to talk shop and work with your fellow Bootstrappers. If you haven’t yet, join our official Slack room![0].
The problem is not just the open vs closed source. Even if Google, Yahoo, Slack all open source their products. You'd still not be able to send messages from one to another unless they also federate at the protocol level.
So you can be connected with a universal "messaging" client to any of the available servers then send messages to someone on Google, or Slack etc.
As noted in the OP, Zulip is not a closed-source product anymore. But I'm not sure that really helps so much with the immediate problem, since it's more the proliferation of protocols rather than the scarcity of source that causes issues.
Yes, that's the title of the thread, you can assume I read that far at least ;) I'll give you I wasn't very clear.
I'm super excited Zulip is going open source. And it's both the proliferation of protocols and the closed-sourceness(?) of the products that is problematic.
Open source has two coupled benefits:
1. If the product becomes popular, it's easy to integrate with it, extend it, modify it, etc rather than just write an alternative from the ground up. This prevents the proliferation of new protocols just for the sake of an alternative. Right now, it makes no sense for me to go and build a FOSS alternative to Zulip. It would've made sense a few weeks ago. FOSS web services encourage/promote self-hosting. This also counts for something.
2. When extending a foss product, writing a gateway is a lot easier. Gateways don't slow down proliferation as much, but they do keep protocols somewhat close to one another and make it easier for users to migrate from one another. For example: It's been several years now and there is still no reliable open source XMPP-to-Hangouts gateway. But a Zulip/IRC gateway? If one doesn't exist already, I bet you there'll be one within weeks.
To dive a bit deeper, while XMPP/IRC exists, and it wouldn't be hard to make the Zulip server natively speak XMPP to clients, that in-and-of-itself wouldn't be quite useful. A message sent to stream "ops" with topic "prod deploy" might look like this†:
But one more protocol on the stack with mac/windows/iphone/android clients is, IMHO, an entirely different ball of wax than a libre project with only a single platform under its belt. In my situation, the existence of mobile clients is clinch for actually pitching it to any org I participate in.
Yep, we have a channel for developers that integrate with our product instead of having them email us. It's pretty efficient, but the fragmentation risk is there.
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.
That was the biggest annoyance I experienced at companies that based their communications around IM clients like AIM or Gtalk. My previous company switched to HipChat at some point and everyone showing up as their real name instead of some stupid username was a surprisingly huge improvement.
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)
We had e2e encryption in the past, but we decided to make one click install of your own server or may be just key infrastructure to make everything cool.
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.
You forgot h.323. On the surface, it looks to me like a "saner SIP", or XMPP with working, standard audio/video support -- but I might be wrong.
I'm not sure why people claim IRC lacks archiving support. Isn't a bit like saying SMTP lacks archiving support? And doesn't basic IRC always go through a server? So there shouldn't be any technical barrier against a server archiving all chats (private and in channels)?
As for NNTP, I'm not sure if NNTP over TLS, peering with only trusted sites (aka for internal use) would make sense or not. I never did use Usenet much. At least the D language forums have made an effort to bring NNTP into the www era[d].
It's interesting that no one seems to do a decent job of (server side) archiving for XMPP -- partly I think it's because as you state, the XEPs have gotten out of hand -- and partly XMPP appears to be especially popular for users that want privacy -- and treat ephemeral chat as a feature.
(format note, you probably should've just listed the protocols in separate paragraphs, as indented blocks with lines longer than ~50 characters doesn't format very well on hn).
Good thought re.H.323, it is often forgotten in these discussions, in part because many implementers resent binary protocols and the ITU has few friends outside the telephony world. https://www.packetizer.com/ipmc/h323_vs_sip/
The IRC protocol is neither sophisticated nor scalable enough that we can all federate our private trusted IRC servers. IRC services are severely limited by being a brittle undirected acyclic graph of servers with little but text forwarding in the protocol. Trying to do anything sophisticated like e.g. identity management, is an ugly business.
NNTP has no identity scheme and no private channel. Running it over TLS doesn't change that. You can forge an ersatz private channel with encryption (I once did so, using Usenet as a message queue to backhaul out-of-band service alerts) - but it's neither pretty nor grandma friendly.
I suppose the difference between our points of view is that I would much rather have a better tool than a publicly accessible archive of message history.
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:
It would require changes to the core of the protocol itself, and that all deployments update to a version of the app that implements those changes. Pretty hard, yet possible.
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.
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.
"Sufficiently Smart Compiler" refers to something which has been hand waved away as a "Simple Matter of Engineering" or an "Exercise for the Reader" as to be impossibly difficult. Compilers are already very smart, usually the sufficient part of the SSC is a tongue in cheek Spock like sufficient. See the failure of Itanium betting that it could produce the SSC to create fast code. It was never built, the performance never matched expectations and it failed.
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.
[Matrix lead here] The open source clients for both Matrix and XMPP are improving a lot currently. On the Matrix side there's vector.im; on XMPP there's Kaiwa and Conversations.im. If you want to help break the fragmentation and have an open standards based approach please run the clients and help us make them better - it is open source, after all!
Something really missing about matrix (at least last time I looked) is a hosted option with my own domain.
I don't want to use the domain you provide, because I'm tied to a provider forever. I don't want to set up my server right now, because it's just too much work to try something that I may end up dumping (because nobody else I know uses it yet).
The overhead to get it is too high, when you're just betting it'll prosper.
Yup, agreed. We're planning to provide domain vhosting (ie point the SRV for your domain to matrix.org and you'll get your own server instance) which should help a bit, although doing that for free could start to get uneconomic. We also need to work out a nice way to let users migrate between providers.
Free for "2 users per domain" might catch on for those of us who use our own domain for email/im. Not the most common thing in the world, but probably quite common amongst your potential early adopters. All while keeping away domains with hundreds of users that would cripple your servers.
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.
Well, it's up to you if you want horribly mangled text rendering ;-) I won't make a judgement call one way or another on the font weight on the site. I'm just telling you that your font rendering is misconfigured. This is why you can't read that text.
Even for higher font weights, the rendering in your example is atrocious. Compare the sibling post's thicker fonts to yours. Notice how yours are fuzzy on the outside? His are crisp. Now, pick a website with a font you like. Shrink the page down so the characters are really small. Look at the characters closely. Do you see how it looks smeared and how there are pixels of different colours (not just black and gray)? This is the result of the misconfiguration. Good hinting will allow you to shrink the font to a very small size and still have good anti-aliasing. Without playing with it, I don't know if it's just that you have the DPI set wrong, or if you have auto-hinting turned on (which you should never do now that the hinting algorithms are no longer patented), or possibly something else.
If you ever decide to look into it, probably the best keywords to search for is "anti-alias" and "hinting". It seems silly to me to put up with such awful rendering just because you are too stubborn to consider the possibility that you are wrong.
Well you're responding to a different person, and my font rendering is fine (and I would fix it if it weren't). I'm just pointing out that if a lot of people are having problems reading a site for whatever reason, the site should probably be doing more testing on different configurations, and not be doing such fancy things with font weights. Another common complaint I have is sites using gray text on darker gray backgrounds, which can turn into an unreadable mess on lower contrast or lower brightness displays (like a mobile phone with the screen brightness set lower to save battery).
And FWIW, I'm on a stock MBP, and I just revisited this site and disabled the font-weight: 300 rule on the body text, and everything became a lot more readable for me (if less "stylish"). I think the site might simply need a slight design tweak for readability.
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.
No, Slack is an IRC alternative (you can connect to it with an IRC client, but you lose many of the features) with assorted bells and whistles (emoji, adding reactions to posts, easy management of private rooms, etc), a bunch of integrations with other services, and persistent and fully searchable history.
Sorry, I don't mean IRC client as in uses the same protocol, but rather that it primarily does what an IRC client would. I think it's great they've found success though.
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.
In fairness, your parent introduced the word "persistence" to this discussion, but I think you're misunderstanding queues if you think the two are interchangeable.
Two things you often want are at-least-once delivery and the ability to queue messages without requiring the consumer to be connected. It requires a fair amount of work to get this to work in Redis. It's not simple configuration.
I believe that you can already do this with python-rq, I understand what persistence means in terms of message queue patterns. There are several persistent queue systems that build on top of redis as a backing store... I was mainly questioning the use of 3 different servers, where 1 would be able to handle the workload.
OK, well, I'd certainly be happy to review a plan to consolidate things (probably the development mailing list is a better place for a detailed discussion) that doesn't hurt performance.
"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.
>There's no benefit to it only being able to reach some small group of people.
If something can just be locked to only talk inside the intranet/VPN it's better from something that can talk to arbitrary people the world over and is only configured not to via its own groups and permissions inside.
I thought we were talking about Slack, and several other hosted services, which don't fit the description you've just given, at all. But, for a self-hosted chat service, then yes...that's a benefit.
> 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).
Just don't make the mistake I did of running with less than 4 GB and then having a flash crowd show up. You really want the RAM for acceptable performance with a reasonable number of concurrent users.
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.
Yeah we run Debian Wheezy in production, so it's definitely possible, just I don't have a nice automated install process handy -- there's a thread about it here:
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)
Zulip doesn't have a strong dependency on Ubuntu 14.04.
It would be less than a day's work to have it support any additional version of Debian or Ubuntu (precise/wheezy would be quite easy since we've run both in production). It's probably also not hard to support something RHEL-based too but that'd be a bit more work.
RAM usage could also be brought down a lot for smaller environments with a bit of work; most of it is the fact that we run a set of like 15 queue processing workers that each import the entire application.
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.
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. :-)