201–210 of 323 posts
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?
Earlier quoted context omitted.
¯\_(ツ)_/¯ 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…
I will forever mourn and be angered by Mozilla giving up on Persona so easily.
A couple of Zulip questions: 1) Is there any support for federation? At first glance it looks like every installation might have multiple servers, but more for balancing load, than federation? 2) How well is the protocol specified? How hard would it be to par down the requirements to eg: just python and sqlite/lmdb or redis (or zodb...)? Say if one wants to support just ~100 users or so?
(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 :).
Earlier quoted context omitted.
> 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.
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.
Earlier quoted context omitted.
¯\_(ツ)_/¯ 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…
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. See eg: https://www.packetizer.com/ipmc/h323_vs_sip/
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.
Nice, it looks like an excellent Django app to study.
Side note: Please STOP using tiny font weights. Text becomes ridiculously hard/painful to read. There's no reason to use a font-weight of 200 (or anything less than 500) on body text, save that for the headlines. http://i.imgur.com/r7a794n.png
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 ;-)
Earlier quoted context omitted.
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. See eg: https://www.packetizer.com/ipmc/h323_vs_sip/
> 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 th…
Earlier quoted context omitted.
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,…
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 every…
Please consider integrating zulip. Though even without gitlab integration, we'll still try it out anyway.
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.