Live data from Hacker News

Dropbox has open-sourced Zulip

zulip.org

211–220 of 323 posts

Re: Dropbox has open-sourced Zulip

#211

Earlier quoted context omitted.

> 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…

What are some of the reasons it's hard to design a good messaging protocol?

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...

Re: Dropbox has open-sourced Zulip

#212

Good to see it be open sourced. I'm disappointed there's no XMPP gateway, OTR chat encryption or Gitlab integration however.

There's a Git integration that you can use with GitLab or anything else that supports post-receive hooks. But it would be cool if someone contributed a more slick GitLab integration :) Also there is a beta XMPP gateway at bots/jabber_mirror.py that can mirror traffic with an XMPP setup. It's beta because it's kinda annoying to setup; feel free to reach out on the development list for help if you have issues setting i…

Ah good to know - thanks for the info.

I just spotted this though: "Currently, the automated Zulip server installation process only supports Ubuntu 14.04 Trusty"

Not at all keen to run Ubuntu, if it was available on CentOS 7 or Debian I'd give it a go but I guess I'll hold off for now.

Re: Dropbox has open-sourced Zulip

#213

Earlier quoted context omitted.

I will forever mourn and be angered by Mozilla giving up on Persona so easily.

Why is Persona dead? Visiting the site doesn't seem to give any indication it's dead...

It's been "given to the community" or something like that. They didn't kill it, but they aren't paying any staff to work on it anymore.

Re: Dropbox has open-sourced Zulip

#215
post #200

Earlier quoted context omitted.

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 a…

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 f…

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.

Re: Dropbox has open-sourced Zulip

#216
post #198

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…

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 xmppsms 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).

For others frustrated by the same, there's at least a "traditional" project to reverse-engineer working with FBs current chat: https://github.com/jgeboski/bitlbee-facebook

[s] http://projectmaxs.org/homepage/

[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.

[d] https://duck.co/blog/post/2/using-pidgin-with-xmpp-jabber

]

Re: Dropbox has open-sourced Zulip

#217
post #196

Earlier quoted context omitted.

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…

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 ch…

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.

Re: Dropbox has open-sourced Zulip

#218
What do Zulip / Slack / Hipchat / IRC / ... people do for screensharing and (group) voice calls?

We'd love the chat improvements, but without screensharing and voice we're stuck on Skype. :(

Re: Dropbox has open-sourced Zulip

#219
post #196

Earlier quoted context omitted.

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 ch…

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.

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.

[1] https://freenode.net/sasl/ ]

Re: Dropbox has open-sourced Zulip

#220
post #196

Earlier quoted context omitted.

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 ch…

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.

It doesn't have to be. Go help with IRCv3 - http://ircv3.net/. Almost everything that's in Slack and Zulip would just be a capability extension.
Post reply on HN