Live data from Hacker News

Open Sourcers Race to Build Better Versions of Slack

wired.com

351–360 of 397 posts

Re: Open Sourcers Race to Build Better Versions of Slack

#351
post #305

Earlier quoted context omitted.

Sounds like XMPP isn't the solution then, only {???,XMPP} is.

Well, extending the spec could be the solution too. What I was trying to convey was more that there will be a lack of such clients until there is either an agreed-upon extension to the standard, or a popular enough fork of the standard. (at least as far as XMPP is concerned)

There is an XMPP extension for it: http://xmpp.org/extensions/xep-0136.html

The problem is, there are far too damn many XMPP extensions and too few of them see any kind of real adoption.

Re: Open Sourcers Race to Build Better Versions of Slack

#352

Earlier quoted context omitted.

btw. very much agree most of the clients are inadequate but if I could humbly pimp Openfire (I'm a dev there): https://github.com/igniterealtime/Openfire And ejabberd of course (powering WhatsApp): https://github.com/processone/ejabberd You'll see that on the server side at least XMPP is very well catered for.

What are the advantages of OpenFire over ejabberd/prosody?

Super easy to use, nice admin pages, great plugin architecture for 3rd party developers to extend its functionality. Means there's a LOT of cool plugins which add video, screen sharing, chat archiving, etc.

Deal breaker against it (depending on your use case) is lack of support for multiple domains. It can only handle one per deployment.

It also does need at least 512MB RAM which rules it out on embedded devices.

Re: Open Sourcers Race to Build Better Versions of Slack

#353
post #305

Earlier quoted context omitted.

Well, extending the spec could be the solution too. What I was trying to convey was more that there will be a lack of such clients until there is either an agreed-upon extension to the standard, or a popular enough fork of the standard. (at least as far as XMPP is concerned)

There is an XMPP extension for it: http://xmpp.org/extensions/xep-0136.html The problem is, there are far too damn many XMPP extensions and too few of them see any kind of real adoption.

Pretty much this. Openfire for instance only recently had XEP-0136 implemented across the board on the server side. In the meanwhile I couldn't find a single client with decent support for chat archiving (XEP-0136) on the client side. Not one (and I really looked).

Re: Open Sourcers Race to Build Better Versions of Slack

#354

Earlier quoted context omitted.

Seriously, what is going on here? It seems any and every comment about IRC or XMPP is being downvoted to oblivion. If someone is astroturfing, I suggest you stop immediately.

Because such comments are at this point inane and uninteresting. As has been mentioned ad nauseum, Slack and friends are winning because IRC is a pain and lacks really basic creature comforts like offline messages and anything but text. I'm downvoting them as I see them for this reason. Anyone saying "Why not IRC?" to the question of "Slack alternative?" is being willfully ignorant at this point. Same goes to those w…

Only as inane and uninteresting as the comment you just posted.

You can't impute motives why someone might ask that question. You may feel it has been repeated ad nauseum but it's quite possible those asking the question haven't read the previous HN comments.

At this point, you come over as an arrogant jerk.

Re: Open Sourcers Race to Build Better Versions of Slack

#355
post #346

Earlier quoted context omitted.

XMPP has changed yes. And we now have some nice clients that are compatible together and stable servers with a bunch of nice features (multi-devices sync, history management, ACK, rich messages, messages edition, encryption, battery management, push notifications…). I'm personally working on Movim, a nice-looking "Social-IM" client fully based on XMPP ( https://movim.eu/ ). The main goal of the project is to show tha…

> And we now have some nice clients that are compatible together and stable servers with a bunch of nice features (multi-devices sync, history management, ACK, rich messages, messages edition, encryption, battery management, push notifications…). Can you recommend a few? I haven't looked into XMPP in detail for a while, because the clients I've been using are "good enough and I didn't bother with mobile), but it seem…

Well I can recommend Conversations for Android https://play.google.com/store/apps/details?id=eu.siacs.conve... which have some really nice features and is fitting well with Movim.

For the desktop there is no real "modern" client yet, unfortunately. But I've ported Movim using Electron :) There is already a Ubuntu/Debian version and the package is here https://github.com/edhelas/movim_electron.

Re: Open Sourcers Race to Build Better Versions of Slack

#356

Earlier quoted context omitted.

Having used and developed with XMPP day in and out for the past 9 years I'd have to agree with the sentiments towards XMPP being on life support. It's a real damn shame because XMPP is pretty awesome. It's open for one, can be made super secure with OTR (client-2-client encrypted chats), has numerous protocols and implementations for stuff as diverse as message archiving, Audio/Video signalling, file transfer, chat (…

Thanks for the insight. It reflects what I often hear from other people close to XMPP. What are your thoughts on Matrix?

Looks like they're making all the right noises in order to be a viable successor to XMPP. Really does look good, but seems to be in its very early stages.

Reminds me of what the Layer guys were trying to do (at least in their initial mission statement). https://layer.com

Pros of Matrix are that it looks like they have full chat support, are working on adding end to end encryption, and of course have federation which is super important for interoperability.

Only concerns with Matrix are that I don't see any large projects or companies spearheading it. Also seem resource constrained. For example it looks like they planned on rewriting their existing basic server side app in C and then ended up just writing a proxy. So clearly it's still a small project. Also see verbs in their URIs...I'm not super up to date on REST best practices but isn't that a no-no?

Anyways early days - and it's easy to nit pick. Matrix certainly looks compelling enough that I'd be interested in trying it and seeing them succeed. God knows we need something like it and soon.

Re: Open Sourcers Race to Build Better Versions of Slack

#357

Earlier quoted context omitted.

The ircv3.net organization and the movement behind it started in 2012 and gained traction in 2014-2015. You're thinking of something else.

The specs listed under 3.1 have copyright dates including 2004, 2009, 2010. There's also this, which may be what I'm thinking of, and perhaps not official, but one of the first things I recall: http://achurch.org/irc3/ Dating to 1999.

Some of the few features that are rolled into IRCv3 like SASL or CAP negotiation were widespread and specified on their own for long before IRCv3 was a thing.

Re: Open Sourcers Race to Build Better Versions of Slack

#358
I know what we need: an open protocol so that people can chat easily, whichever company you work for, wherever you are... We should call it IRC or XMPP

:)

Seriously I know XMPP is pretty un-popular, but deep inside I kind of wish it was the default protocol everybody used to communicate...

Re: Open Sourcers Race to Build Better Versions of Slack

#359
post #254

Earlier quoted context omitted.

There is, actually. IRC has no concept of timestamps. IRC has no concept of foreign metadata, even, so shoehorning isn't even possible without looking horrible. IRCv3 fixes all that.

Prefixing a date/timestamp unless the client has asked for IRCv3 timestamps is reasonable.

And now, you just broke essentially all clients that already support channel logs by duplicating anything they already had.

This is a problem bouncers are already solving best they can, and it still sucks. It's not good enough to compete with slack.

Re: Open Sourcers Race to Build Better Versions of Slack

#360
post #268

Earlier quoted context omitted.

This is so disappointing. Especially Jabber/XMPP was created to fix that issue by standardizing the protocol. The idea is that IM would be like email - no central server. Others (GTalk, Facebook, WhatsApp, HipChat to name few) started implementing it but did not enable server to server communication (ok GTalk did, but as soon as they became popular they intentionally broke it with Hangouts). So now we have bunch of s…

The problem is that the IM protocol space seems very opinionated. "XMPP? XML sucks!" "Web sockets? Web sockets suck!" "JSON? JSON sucks!" "Binary? That prevents telnet, binary sucks!" People do care, it just seems as though they care about their pet peeves more.

That "XML" sucks thing is why we don't have single-sign on (YuBiKey is doing a great job getting half way there though). We keep on reinventing the wheel re: authorization & authentication despite the fact that there are well-defined, cryptographicly secure[0]. SAML2[1] has been standardized, implemented, operates in a similar fashion to SMTP/Kerberos (i.e., your identity is established (i.e. authentication) purely through a trusted-source), after which you can proceed.

  * This eliminates the whole issue for users (I don't want to have to remember 40 million passwords, and I don't want to rely on Google as my SSO). 
  * It helps the developer because all he has to do is implement one protocol (rather than make 8 different accounts to register passport.js with).
  * It helps the tin-foil hatters like me, because I can revoke access from any source at any time & if my account gets compromised I call my buddy Bill hosting the IDP and invalidate my credentials.
It's SMTP mail back in the late 90s when your buddy ran his own server as your primary MX, and his buddy as a secondary MX (i.e., you host an IdP similarly to hosting a mail server).

I've been working on this problem on and off for about 10 months, the last 4 of which have been fairly rigorous. I've got a solution for the "buddy" willing to host the IdP. https://github.com/bergie/passport-saml is a low friction add-on to your node app for the developers. The last piece of the puzzle is dev adoption (i.e., getting traction on par with LetsEncrypt) to actually spend 5 minutes for that passport-saml stuff.

The other issue is developing an easy solution (easier than SSO with Google) done by mobile App authentication. User-flow is basically: you click "Login with ", the IdP forwards the message to your mobile via APN, and you swipe left or right to auth. That's the last technical barrier (user adoption is 80% of the problem). I need to take ~3 mo off and pony up high-five, low-sixes in fees re: getting a great UX guy (I'm abysmal [[if you're great at UX, contact me]]), lawyers, liability insurance, a security firm to audit, etc (there's already a monetization model for this venture, though the whole thing will be GNU AGPL[3] / free for universities / research institutions, etc.)

[0] Like, in the formal mathematically proven sense, both in concept, and implementation (though which one slips my mind).

[1] http://wso2.com/library/articles/2010/07/saml2-web-browser-b...

[2] Encryption is basically a subset of privacy, which I think we have a constitutional right to, though other people object.

[3] The whole point is to do this first as a human good, but profiteer off expensive licenses a la Exchange modules, et al. I don't really want to shop around Sandy Hill but if any of you successful Angels (who are historically privacy advocates, I'd give Karsten Nohl or DJB (or hell, PG if you're reading this message haha, 30% and 2 seats in a second, but Larry Ellison could offer 3MM for .1% and that meeting would conclude rapidly) are interested, e-mail me me -- we'd be able to go to market a lot quicker with 2 or 3 FTE's. I'm going to complete this anyways, but we're fighting cryptowars again so there might be a rush.

Post reply on HN