5 ms·

As someone that's only used XMPP fairly briefly and has no knowledge of the underlying protocol, could you tell me why it's 'horrible'?

by s3krit 11y ago

golergka 11y ago
That's what I read in a couple of blog posts in articles by people who implemented it. I can't bring the up right now, but after one minute in google, I found this conversation to be quite interesting: https://news.ycombinator.com/item?id=2069810 https://news.ycombinator.com/item?id=2069810
- userbinator 11y ago
  A representative comparison of what the notification for a user going offline looks like in several IM protocols: MSNP (older versions): FLN user@example.com IRC: :nick!user@example.com PART #channel XMPP: <message from='juliet@capulet.com/balcony' to='romeo@shakespeare.lit/orchard' type='chat'> <thread>act2scene2chat1</thread> <gone xmlns='http://jabber.org/protocol/chatstates'/> </message> MSNP (newer versions, unfortunately also XML-ified): NFY PUT 268 Routing: 1.0 To: 1:mypassport@hotmail.com From: 1:en-cn@hotmail.com Reliability: 1.0 Notification: 1.0 NotifNum: 0 Uri: /user NotifType: Partial Content-Type: application/user+xml Content-Length: 50 <user><s n="IM"> <Status>FLN</Status> </s></user> I think older MSNP and IRC are the best of all the IM protocols I've seen, and I've written clients for both. OSCAR (ICQ/AIM) is a binary format that doesn't look too hard to parse; I'd say it's still better than working with XML.
  - MattJ100 11y ago
    Your XMPP example is incorrect, what you pasted is a notification that the user you were chatting with closed the conversation. A user going offline would be: <presence from="juliet@capulet.com/balcony" type="unavailable"/> And yes, XMPP is extensible, so you might see such notifications with more content (e.g. the user can set an offline message), but the beauty is that not every client need implement support for that, which is handy if you're writing a thin client like a bot, or doing machine-to-machine communication. But every XMPP client will interpret the core meaning exactly the same: the user has gone offline.
  - nly 11y ago
    Message size is important, but for low-bandwidth instant messaging is XML really bothersome? I mean it's not like you're writing your own XML parser or serialiser, is it?
    - drdaeman 11y ago
      The sad truth about XMPP is that a lot of developers actually did this (at least in early days). Maybe because a lot of readily available libraries weren't really compatible with XML streams and XMPP's idea of framing. And their XML parsing were quite limited.
the_mitsuhiko 11y ago
As someone who implemented stuff for XMPP many years ago: it's a super complex, XML infested protocol that if implemented correctly can only result in a bad user experience. It gets a little bit better if you support only a subset of it (eg: you take away the federation aspect of it) and target a single server and assume you control all clients. But it's really very tricky to get a good user experience with it and the protocol is just not at all fun to work with. If it would not be the darling of the open source community it would not have gone far.
- drdaeman 11y ago
  It's not really complex on its own, just that a lot of developers used ad-hoc regexp-based parsers and made some assumptions (like hardcoded namespace names, say, some software really expected "x:" prefix and didn't care for "xmlns"es) when processing it. I absolutely admit (and don't like) a bad framing scheme — it would've been much better not as XML stream, but as TLVs of structured data — but that's manageable with streaming parsers, and otherwise I don't see why XMPP's core is super complex. When I think of something super complex that's SOAP (where you can literally write the same call in multiple different and server-incompatible ways), and XMPP is nowhere close. As much as I don't like XML (and I do), it allowed XMPP a great amount of extensibility that's just not possible with simpler/non-extensible formats like JSON (although possible with YAML or ASN.1, and doable with implementing some format on top of JSON). Most chat protocols just don't allow to implement arbitrary extensions. E.g. you want your chat service to have a concepts of, say, hats¹ for participants — with IRC the best you can do is to run a HatsBot or make a custom DCC protocol. With XMPP you just decide on a schema and put your stuff with a custom namespace (then if it's something useful for everybody, file a XEP). So, while XML may be not best format, I think it absolutely it made sense. ___ ¹) I just wanted something silly. So, I thought of Team Fortress-style hats.
  - the_mitsuhiko 11y ago
    > I don't see why XMPP's core is super complex. So even ignoring XMPP's intrinsic complexity, it's based on XML. XML is impossible to use securely out of the box without severely tweaking the parser. XML entity bombs, gazillion of different charsets you might encounter, stack exhaustion due to nesting of namespaces or elements in places you don't expect etc. The main reason many of these issues are not better known is because it did not get popular enough that people bothered exploiting it. > As much as I don't like XML (and I do), it allowed XMPP a great amount of extensibility that's just not possible with simpler/non-extensible formats like JSON You do not need schemas and namespaces to be extensible.
rakoo 11y ago
There are multiple pain points with the way the XMPP protocol is "organized": * It's designed to accommodate as many use-cases as possible with a variety of actors chiming in with their own requirements * a tiny core that doesn't do a lot, and a gazillion extensions * when you want to implement a software in XMPP world, you don't have a clear view on what extensions you need to implement and what extensions are nice-to-have (other than word of mouth) * corollary: extensions can move fast, some are new, some die, but the perception doesn't change as fast, so old habits remain for a long time (cue "PSYC said XMPP sucks") and softwares don't evolve to accommodate later improvements * second corollary: since the bulk of what makes XMPP useful is defined in extensions, as a user you don't know which client or which server you should pick * by design there's no reference implementation, which means you don't really know where to start * it's XML, and XML doesn't exactly play well with recent languages (you won't write XML itself so you'll use what your language gives you, but it doesn't always map very well with XML) To summarize, XMPP can do everything, provided that you know your way. If you don't know anything you will most likely be disappointed by your first experience, as a user.
- greggman 11y ago
  Does xmpp handle the case where you've read a message on another client and you want all clients to see it as read? Seems like possibly an argument for centralized storage
  - finnn 11y ago
    XEP-0280: Message Carbons https://xmpp.org/extensions/xep-0280.html https://xmpp.org/extensions/xep-0280.html
- ape4 11y ago
  I hope we can craft a better protocol. One that people will love to implement.
  - rakoo 11y ago
    At this point I don't think there is a huge benefit in starting another protocol. There are problems with XMPP, but IMHO they're more in how it is organized than in the protocol itself. XMPP has surveyed a huge chunk of the space, it has seen where things are difficult and proposed a solution for that. It is in use by many entities already, with many different use cases (one of the later extensions (https://xmpp.org/extensions/xep-0365.html https://xmpp.org/extensions/xep-0365.html) is to use XMPP over radios with atrocious conditions: latency in minutes, throughput as low as 75 bits/s. Also, for some reason XMPP has seen some success in military), it has all the benefits of being an approved IETF protocol (one of which being that it will still be here in 10 years, whatever happens). Sure, it's old stinky XML, but it's not like it's a brand new technology where little documentation exists. There are libraries in most languages already. What we really lack is a bit more guidance: the XSF (XMPP Standards Foundation) is only interested in making sure the standard is properly specified, that demands are met appropriately. It's a huge huge job, but for a community of developer it's not enough. There has already been talks to update the suite of extensions that are considered almost-mandatory in a modern IM software; it would also be really awesome to have a reference implementation for each usage (ie one server, one IM client, one VoIP client, one microblogging client, ...) because, like many others, I find tangible code we all agree on to be of very high value. I fear that other protocols will be created, they will all (or at least a good part) die, and in the end we'll have XMPP, standing there in the waves of protocols, chugging along quietly. People will be mocking it not because it doesn't work, but because they don't understand it (and that will be a fault with XMPP, not with people, because it will remain extremely complex)
tomelliott 11y ago
Here's a good list: http://matrix.org/docs/guides/faq.html#what-is-the-difference-between-matrix-and-xmpp http://matrix.org/docs/guides/faq.html#what-is-the-differenc...

As someone that's only used XMPP fairly briefly and has no knowledge of the underlying protocol, could you tell me why it's 'horrible'?

by s3krit 11y ago

As someone that's only used XMPP fairly briefly and has no knowledge of the underlying protocol, could you tell me why it's 'horrible'?

golergka 11y ago

That's what I read in a couple of blog posts in articles by people who implemented it. I can't bring the up right now, but after one minute in google, I found this conversation to be quite interesting: https://news.ycombinator.com/item?id=2069810 https://news.ycombinator.com/item?id=2069810

userbinator 11y ago
A representative comparison of what the notification for a user going offline looks like in several IM protocols: MSNP (older versions): FLN user@example.com IRC: :nick!user@example.com PART #channel XMPP: <message from='juliet@capulet.com/balcony' to='romeo@shakespeare.lit/orchard' type='chat'> <thread>act2scene2chat1</thread> <gone xmlns='http://jabber.org/protocol/chatstates'/> </message> MSNP (newer versions, unfortunately also XML-ified): NFY PUT 268 Routing: 1.0 To: 1:mypassport@hotmail.com From: 1:en-cn@hotmail.com Reliability: 1.0 Notification: 1.0 NotifNum: 0 Uri: /user NotifType: Partial Content-Type: application/user+xml Content-Length: 50 <user><s n="IM"> <Status>FLN</Status> </s></user> I think older MSNP and IRC are the best of all the IM protocols I've seen, and I've written clients for both. OSCAR (ICQ/AIM) is a binary format that doesn't look too hard to parse; I'd say it's still better than working with XML.
- MattJ100 11y ago
  Your XMPP example is incorrect, what you pasted is a notification that the user you were chatting with closed the conversation. A user going offline would be: <presence from="juliet@capulet.com/balcony" type="unavailable"/> And yes, XMPP is extensible, so you might see such notifications with more content (e.g. the user can set an offline message), but the beauty is that not every client need implement support for that, which is handy if you're writing a thin client like a bot, or doing machine-to-machine communication. But every XMPP client will interpret the core meaning exactly the same: the user has gone offline.
- nly 11y ago
  Message size is important, but for low-bandwidth instant messaging is XML really bothersome? I mean it's not like you're writing your own XML parser or serialiser, is it?
  - drdaeman 11y ago
    The sad truth about XMPP is that a lot of developers actually did this (at least in early days). Maybe because a lot of readily available libraries weren't really compatible with XML streams and XMPP's idea of framing. And their XML parsing were quite limited.

the_mitsuhiko 11y ago

As someone who implemented stuff for XMPP many years ago: it's a super complex, XML infested protocol that if implemented correctly can only result in a bad user experience. It gets a little bit better if you support only a subset of it (eg: you take away the federation aspect of it) and target a single server and assume you control all clients. But it's really very tricky to get a good user experience with it and the protocol is just not at all fun to work with. If it would not be the darling of the open source community it would not have gone far.

drdaeman 11y ago
It's not really complex on its own, just that a lot of developers used ad-hoc regexp-based parsers and made some assumptions (like hardcoded namespace names, say, some software really expected "x:" prefix and didn't care for "xmlns"es) when processing it. I absolutely admit (and don't like) a bad framing scheme — it would've been much better not as XML stream, but as TLVs of structured data — but that's manageable with streaming parsers, and otherwise I don't see why XMPP's core is super complex. When I think of something super complex that's SOAP (where you can literally write the same call in multiple different and server-incompatible ways), and XMPP is nowhere close. As much as I don't like XML (and I do), it allowed XMPP a great amount of extensibility that's just not possible with simpler/non-extensible formats like JSON (although possible with YAML or ASN.1, and doable with implementing some format on top of JSON). Most chat protocols just don't allow to implement arbitrary extensions. E.g. you want your chat service to have a concepts of, say, hats¹ for participants — with IRC the best you can do is to run a HatsBot or make a custom DCC protocol. With XMPP you just decide on a schema and put your stuff with a custom namespace (then if it's something useful for everybody, file a XEP). So, while XML may be not best format, I think it absolutely it made sense. ___ ¹) I just wanted something silly. So, I thought of Team Fortress-style hats.
- the_mitsuhiko 11y ago
  > I don't see why XMPP's core is super complex. So even ignoring XMPP's intrinsic complexity, it's based on XML. XML is impossible to use securely out of the box without severely tweaking the parser. XML entity bombs, gazillion of different charsets you might encounter, stack exhaustion due to nesting of namespaces or elements in places you don't expect etc. The main reason many of these issues are not better known is because it did not get popular enough that people bothered exploiting it. > As much as I don't like XML (and I do), it allowed XMPP a great amount of extensibility that's just not possible with simpler/non-extensible formats like JSON You do not need schemas and namespaces to be extensible.

rakoo 11y ago

There are multiple pain points with the way the XMPP protocol is "organized": * It's designed to accommodate as many use-cases as possible with a variety of actors chiming in with their own requirements * a tiny core that doesn't do a lot, and a gazillion extensions * when you want to implement a software in XMPP world, you don't have a clear view on what extensions you need to implement and what extensions are nice-to-have (other than word of mouth) * corollary: extensions can move fast, some are new, some die, but the perception doesn't change as fast, so old habits remain for a long time (cue "PSYC said XMPP sucks") and softwares don't evolve to accommodate later improvements * second corollary: since the bulk of what makes XMPP useful is defined in extensions, as a user you don't know which client or which server you should pick * by design there's no reference implementation, which means you don't really know where to start * it's XML, and XML doesn't exactly play well with recent languages (you won't write XML itself so you'll use what your language gives you, but it doesn't always map very well with XML) To summarize, XMPP can do everything, provided that you know your way. If you don't know anything you will most likely be disappointed by your first experience, as a user.

greggman 11y ago
Does xmpp handle the case where you've read a message on another client and you want all clients to see it as read? Seems like possibly an argument for centralized storage
- finnn 11y ago
  XEP-0280: Message Carbons https://xmpp.org/extensions/xep-0280.html https://xmpp.org/extensions/xep-0280.html
ape4 11y ago
I hope we can craft a better protocol. One that people will love to implement.
- rakoo 11y ago
  At this point I don't think there is a huge benefit in starting another protocol. There are problems with XMPP, but IMHO they're more in how it is organized than in the protocol itself. XMPP has surveyed a huge chunk of the space, it has seen where things are difficult and proposed a solution for that. It is in use by many entities already, with many different use cases (one of the later extensions (https://xmpp.org/extensions/xep-0365.html https://xmpp.org/extensions/xep-0365.html) is to use XMPP over radios with atrocious conditions: latency in minutes, throughput as low as 75 bits/s. Also, for some reason XMPP has seen some success in military), it has all the benefits of being an approved IETF protocol (one of which being that it will still be here in 10 years, whatever happens). Sure, it's old stinky XML, but it's not like it's a brand new technology where little documentation exists. There are libraries in most languages already. What we really lack is a bit more guidance: the XSF (XMPP Standards Foundation) is only interested in making sure the standard is properly specified, that demands are met appropriately. It's a huge huge job, but for a community of developer it's not enough. There has already been talks to update the suite of extensions that are considered almost-mandatory in a modern IM software; it would also be really awesome to have a reference implementation for each usage (ie one server, one IM client, one VoIP client, one microblogging client, ...) because, like many others, I find tangible code we all agree on to be of very high value. I fear that other protocols will be created, they will all (or at least a good part) die, and in the end we'll have XMPP, standing there in the waves of protocols, chugging along quietly. People will be mocking it not because it doesn't work, but because they don't understand it (and that will be a fault with XMPP, not with people, because it will remain extremely complex)

tomelliott 11y ago

Here's a good list: http://matrix.org/docs/guides/faq.html#what-is-the-difference-between-matrix-and-xmpp http://matrix.org/docs/guides/faq.html#what-is-the-differenc...