4 ms·

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 ht

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 https://news.ycombinator.com/item?id=2069810

pmlnr 5y ago
Seriously? Go check out Matrix or ActivityStreams, XMPP is actually much simpler.
- icedchai 5y ago
  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/ https://xmpp.org/extensions/
  - mst 5y ago
    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/ https://docs.modernxmpp.org/client/protocol/
  - MattJ100 5y ago
    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 https://xmpp.org/about/compliance-suites.html
  - southerntofu 5y ago
    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".
southerntofu 5y ago
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.
- icedchai 5y ago
  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.

pmlnr 5y ago

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

icedchai 5y ago
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/ https://xmpp.org/extensions/
- mst 5y ago
  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/ https://docs.modernxmpp.org/client/protocol/
- MattJ100 5y ago
  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 https://xmpp.org/about/compliance-suites.html
- southerntofu 5y ago
  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".

southerntofu 5y ago

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.

icedchai 5y ago
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.