Hacker News Reader

Comment by finnn | Hacker News Reader

http://getkaiwa.com/ is another Slack alternative that uses an XMPP backend, which IMO is much better than a custom backend. So far the only open source Slack clone I've seen that uses an existing standard for the backend

View on HN

There are a slew of developers who tangled with XMPP and came away with very negative, well-founded reasons to dislike the protocol. Do you want XMPP because it is a standard, or you also have a contrary experience to these developers?

[1] http://about.psyc.eu/Jabber#Technical_Issues_in_Jabber

[2] http://josephg.com/blog/xmpp-in-wave-in-a-box/

[3] https://news.ycombinator.com/item?id=2069810

[4] https://www.reddit.com/comments/rvzdp

[5] https://news.ycombinator.com/item?id=10040302

For some balance, there are contrary opinions. This one seems to revolve around project governance.

[6] http://about.psyc.eu/Jabber#Technical_Issues_in_Jabber

And links [4] and [5] have a lot of people piping up saying they like XMPP just fine.

To be fair to XMPP, I strongly suspect it is a protocol trying to solve a very large, very messy problem space, and too many developers are trying to wrestle with it "raw" in its totality, unaware that for their specific problem domain, they only need a subset, and a specialized protocol/library that exposes only that subset to them. It's almost as if too few understand that XMPP is kind of the assembly language (or microcode?) of its problem domain, and most people need a $High_Level_Language_of_Choice instead.

I just like jabber because it's a standard. I have an app on my phone that'll do Jabber already. There's a lot of server software already out there to host Jabber, it's pretty robust, all we need is a reasonable frontend for desktop

The counter to that—and no doubt a factor for many like Slack—is that when you use a custom protocol/API you get to control the whole experience. You don't have to deal with bugs in third-party clients, wait for clients to get emoji support, and can control the look-and-feel (many of the Jabber apps I've seen aren't great).

This is obviously not ideal for everyone, but I suspect that outside of tech that using a custom client is possibly even a plus.

I'd rather have it the other way around: start from a solution that works (like Mattermost) and progressively plug XMPP into it. Mattermost and its friends have the huge advantage of having everything built-in and well working together, and if you take a good look at it XMPP should be more like a "compatibility protocol" on top of a working solution.

Mattermost v1.1 (ships Oct 16) has incoming webhooks support with samples (www.mattermost.org/webhooks/), and we're planning outgoing webhooks v1.2 (Nov 16), which provides the ground work for XMPP

Community has asked this for a while, we want to build an effective, well documented API to let the community create what they want: http://mattermost.uservoice.com/forums/306457-general/sugges...

https://rocket.chat/ built with Meteor and with WebRTC videocalls, is another great open source alternative... The list of current and upcoming features is quite impressive:

https://github.com/RocketChat/Rocket.Chat#features

https://github.com/sdelements/lets-chat is open source and supports XMPP as well. Tried it, it's very slick.

There's a lot of standards out there. Open is better than closed, and standard is better than ad hoc, yes...but that doesn't mean XMPP is automatically the best solution.

I'd honestly be more interested in seeing Mattermost try and write a really solid solution, and then work to standardise their protocol.

Here's another one: http://about.jabbr.net/ but for the Windows / Azure / AppHarbor platforms.

Reply on news.ycombinator.com