Hacker News Reader

Comment by 0xdeadb00f | Hacker News Reader

Anyone else feel like the fact XMPP needs this kind of signals that it's pretty... shit? (Excuse my language).

Do you have constructive suggestions on introducing cohesive design into open ecosystems without a guiding documentation project? (disclaimer: I started this one)

Firstly, to answer your question: No.

There are other ecosystems that are going "fine" that have centralised, official documentation and don't require a third party to intervene and collate documentation and recommendations in an attempt to make it easier for developers. The fact this is necessary, or people feel is necessary, makes me want to avoid XMPP at all costs. That's just my very shallow surface level opinion.

With all that said, i have to say; what you're doing here is commendable. I don't mean to (pardon my language) shit on something you seem to have worked very hard on. Doing something like this isn't an easy task I'm sure.

This kind of thing is pretty common with complex systems that have a very long legacy. There's a huge amount of features, many of which are very niche and most people don't even need to know about them. Official docs tend to be unopinionated and cover everything, while third parties create "guides" and similar docs for the features that matter to them.

You see something similar with end-user software like Adobe's entire suite where the official docs are basically useless if you just want to learn the common operations quickly and so you have to rely on third-party books and tutorials (like the Dummies books).

XMPP has a long history... Two decades of accumulated specifications can make it a bit overwhelming to find what you're looking for. It's important to have external individuals/collectives gathering the pieces they find important and remarks to achieve what they consider a good implementation.

It's just like when you do web stuff you may read from MDN, csstricks or smashing magazine. It doesn't mean that the W3C/IETF specs are useless, far from it. But in my view it's useful to find guidance in a nebula of specifications and endless UX possibilities.

XMPP is basically an abomination of a protocol. It's too complicated. Other people can explain it better than I: https://news.ycombinator.com/item?id=2069810

Seriously? Go check out Matrix or ActivityStreams, XMPP is actually much simpler.

The core of XMPP may be simple, but when you add in various XEPs, the complexity builds really fast. Just look at all this stuff: https://xmpp.org/extensions/

One of the key points of the article we're discussing is to recommend a small curated set of XEPs.

Just look at this relative lack of stuff: https://docs.modernxmpp.org/client/protocol/

That's a growing list of documents over the course of XMPP. It doesn't really prove anything other than... XMPP has been around a long time, and people continue to develop it.

People saying "look at all this stuff" is one reason the Modern XMPP project was born. To draw attention to the actually important things that developers need to read.

The XSF receives a lot of submissions each year. Many of these proposals never make it past the "experimental" stage. Others are only applicable in certain domains (IoT, etc.). Over time some of these become widely adopted and progress through the standards process. Some do not.

The XSF publishes annually the "compliance suite" which describes what clients and servers should be supporting in different areas: https://xmpp.org/about/compliance-suites.html

That is true to some extent, however most of extensions listed there are not required or even recommended to implement useful clients/servers. It's just like if you took the list of RFCs using TCP/IP then said "ha! TCP/IP complexity builds really fast".

Overall, the impressions expressed in that comment from 2011 were relevant at the time, back when "Compliance Suites" specifications were not a thing and there was a lot more room for interpretation in many specifications. The situation has much improved since then. To reply to individual bits from that comment:

> It has never seen serious adoption because nobody wants to touch it - and for good reasons.

That's outright false. There's many successful commercial products using XMPP right now (eg. WhatsApp/Zoom or games and gaming systems like Fortnite, Origin, League of Legends) including for non-IM usecases (Google Cloud Print, Firebase Cloud Messaging, Nintendo Switch, Apple's push notifications).

In the free-software world, there's actively maintained featureful clients (gajim/dino on desktop and snikket family of clients on mobile) and servers (ejabberd/proosdy/tigase). I can't say there's no bugs but i can say with confidence they're actively being hunted down.

> It leads to ridiculous overengineering through layered complexity.

Layering complexity may sound like engineering, but that's where the "eXtensible" promise of XMPP comes from. The same goes with Matrix/ActivityPub protocol: there's a reason people are doing it this way, and that reason is not "overengineering".

> Take a lesson from IRC, a group-chat protocol that, despite its age, works and scales amazingly well.

The protocol works remarkably well because it's dead simple. However, implementing a decent client/server that plays well with others is not easy (see IRCv4 debates) and each server in practice operates differently, more so even than XMPP servers.

> It wouldn't take much fix the warts on IRC and extend it to cover everything that XMPP tries to do.

Please by all means try. It'll take you far more time to design, and you can be 100% sure you're going to break many existing clients and servers by extending the IRC protocol. XMPP/Matrix clients on the other hand can handle missing features gracefully because the protocol is namespace'd/schema'd properly.

I appreciate that concern for fighting NIH and that's a criticism i've addressed to the Matrix project myself, that it could have been implemented on top of existing XMPP clients and servers with two simple XEPs: one for decentralized chatrooms and state resolution, the other for client-to-server JSON API. But when comparing those newer federated protocols with IRC, i think the comparison has no grounds.

Let me know if you're not convinced by these answers or have more questions.

Maybe I should take another look! It sounds like a lot has changed. My experience, working on an XMPP client for an internal application, dates from 2011.

If you're still into that same domain, then sure you should have another look. There's plenty of chatrooms where you can ask questions, jdev@muc.xmpp.org is a popular one for implementers. The Jabber/XMPP community, despite a too-much-information syndrom, is full of very friendly folks who always take time to answer questions in public chats to guide you in the right direction. That's something i truly miss in most dev chatrooms where i often feel like i'm talking into the void (or to other people like me who have different problems and no clue).

From a client perspective, picking a good/modern XMPP library will save you a lot of headaches, because a good library is supposed to hide away the complexity. If you're not sure what to pick, just ask around in dev chatrooms.

Happy hacking

if so then same is true for say, TCP/IP, HTTP and HTML

Fair point. I think I've maybe changed my tune on this a little bit since writing that comment.

Reply on news.ycombinator.com