Hacker News new | ask | show | jobs
by handrous 1830 days ago
Your notable open alternatives are Matrix or Signal. Matrix is a PITA to set up and admin and has all the issues you'd expect from a newcomer. It's fine if you like living on the bleeding edge, and has some promise, but isn't exactly "tried and true" yet and its software ecosystem is small and immature. Signal, OTOH, is only kinda, halfway, sorta, open. In both cases, your options for server software, if you don't want to step directly into "here be dragons" territory, are limited to at most two options, and options for client software aren't a ton better.

With XMPP it's easy to get a server running on dirt-cheap hardware, maybe straight from your favorite distro's official repo (you have multiple choices of mature daemons for your server), and it has tons of clients and client libraries on every platform under the sun.

Basically if you want to serve an open protocol for chat, with all the ecosystem benefits one wants from a protocol (versus an ecosystem that's, at least so far, tightly coupled to an official implementation), XMPP's your front-runner.

(I'm omitting IRC because its ideal use-cases are different from XMPP's, so they're not exactly competitors)

2 comments

Matrix servers are now fairly simple to deploy. https://www.youtube.com/watch?v=dDddKmdLEdg I do wish the Element team moved a bit quicker at attacking Slack head-on. Element isn't super polished yet nor does it implement all the features built into the server/spec. So there is some catching up to do there. But the project is more than ready to use today at a large org and it includes a ton more features than what you get out of the box with an off the shelf XMPPd. https://joinup.ec.europa.eu/collection/open-source-observato...
I run a Matrix server with Dendrite, it was pretty easy to set up. My biggest complaint is the RAM usage, but if you don't join large rooms it's fine.
My big dig against Matrix is that it is monolithic. By compare, XMPP's virtue is in the very first word of it's name: Extensible (of Extensible Messaging and Presence Procotol; really: Protocols).

XMPP is designed to be grown, to have new capabilities added, to be experimented with. XMPP was used to build Google Chat's video conferencing a long long time ago (Jingle) because it was the only sensible straightforward chat system out there built for extensibility, built to be grown on. XMPP has all manners of neat uses, from IoT to VPNs (EdgeVPN) to nearly anything else you could imagine.

A lot of people seem to like the authority & control & centralization of systems like Matrix, but to me, this consigns away the future for an easy convenience. It restricts what a thing might become. I value loose coupling, I value extensibility highly, and XMPP continues to be an evolvable, changing, enhancing set of technologies that stays relevant because Extensible leads it's design. It's something Matrix will not nor ever could compete with, and to me, it nearly certainly dooms some latter version of Matrix to obsolescence: there will come a point when the bad choices have added up, and no progress can be made.

Let's take a little case study example. XMPP itself faces a moment of crisis now, imo, with Multi-User-Chat (MUC), which is a very not good experience & technically crufty; a very early specification that has really obstructed chat rooms from being good & let Slack et cetera take over & dominate. There are some attempts to fix MUC but the tech underpinnings are, imho, bad. The good news? There is a much wiser, much better engineered alternative, MIX, that builds upon many of the other XMPP standards that have emerged over the years & stood the test of time. MIX is a way simpler, way better, way smarter way to do chat in XMPP. The ugly? There are nearly no clients that have implemented MIX. Not a lot of xmpp servers have implemented MIX. Trying to drive adoption of this thing necessary for XMPP to survive has been hard going.

But still, to me, even with this struggle, even with these huge pains, & a non-adapting future, I still think this case study hugely shows the need for Extensible systems. This is just one realm, one battle being fought, amid a system that made up of a bunch of different components. Matrix might be able to muster up the need for serious breaking changes, but my feeling is that the concensus based, forward moving innovation of Matrix will keep adding decisions & technical nuance & capabilities forever, and will likely never have the chance for redress & re-appraisal that XMPP by it's nature, by it's namesake, promises. XMPP can re-orient, learn, adjust. Nothing prevents Matrix, with it's monolithic , core-contributor-driven specification system from making radical changes, but they will forever lack the outsider perspective & autonomy that folks can bring to XMPP specification development. Matrix can't be the platform for a next-Google to build their next-chat VR platform on, because Matrix is not extensible, it's not a system of protocols: it's monolithic, it's top down, it's structured for linear, forward progress, not the free innovation that extensible systems are designed for. Matrix has many decades of wonderful innovation & advancement to go, but to me, it's already a dead end, it's already made it's bed, where-as XMPP will always have a freer hand to keep becoming more, freer hand to becoming something different, is always available for radical innovation (such as EdgeVPN, or IoT).

> XMPP is designed to be grown, to have new capabilities added, to be experimented with.

so is Matrix.

your entire post is based on a wrong assumption...

I don't see any technical evidence of that. matrix is a single unified protocol, maintained by a small core contributor group. matrix has no extensibility mechanisms. not sure how you can make a claim like this.
There's a process, guided by core team members, to contributing to the one specification.

This does not sound like extensibility at all. It's monolithic development. Gated by a core team.