6 ms·

I use XMPP every day. All my friends are on XMPP. What makes you think XMPP is dead? What are "various reasons"?

by Zash 11y ago

msbarnett 11y ago
Google's abandonment of it was a big, big blow. 90% of my contacts are no longer available via XMPP.
creshal 11y ago
All the servers available for it suck. All the clients available for it suck. I know, I'm using it daily too, but I don't see it gaining more traction that it already has ever again.
- pyre 11y ago
  What sucks about (e.g.) Adium? I haven't had any major issues with it other than the fact that it doesn't seem to be too actively updated. My biggest complaint is lack of protocol support for other things (e.g. GTalk vs. Hangouts), but that's on libpurple, and the lack of open protocols by the providers.
  - leonroy 11y ago
    Developer interest is on the wane in pretty much every XMPP project out there. That's the main issue. XMPP is very much alive in large businesses, especially for system to system interop, but as far as client to server goes I don't see a compelling XMPP client - where's voice, video, chat archiving for example? Compare any XMPP client to Skype for instance and they're not even remotely close.
    - pyre 11y ago
      > chat archiving for example This requires a central server though. This is more a function of the service providing XMPP to you than the client. If you want the functionality on the client, it presumably requires some sort of interop between client and server that I'm not sure it part of the XMPP spec.
      - Qwertious 11y ago
        Sounds like XMPP isn't the solution then, only {???,XMPP} is.
        pyre 11y ago
        Well, extending the spec could be the solution too. What I was trying to convey was more that there will be a lack of such clients until there is either an agreed-upon extension to the standard, or a popular enough fork of the standard. (at least as far as XMPP is concerned)
        creshal 11y ago
        There is an XMPP extension for it: http://xmpp.org/extensions/xep-0136.html http://xmpp.org/extensions/xep-0136.html The problem is, there are far too damn many XMPP extensions and too few of them see any kind of real adoption.
        leonroy 11y ago
        Pretty much this. Openfire for instance only recently had XEP-0136 implemented across the board on the server side. In the meanwhile I couldn't find a single client with decent support for chat archiving (XEP-0136) on the client side. Not one (and I really looked).
        davecridland 11y ago
        What? Openfire has had XEP-0136 for literally years. I think a little over a decade, actually. It's only recently implemented XEP-0313.
        leonroy 11y ago
        Hi Dave, firstly thanks for all the hard work on Openfire over the years, very much appreciated. Secondly regarding XEP-0136 support in OF. I did state that Openfire has only recently had 'XEP-0136 implemented across the board'. Whilst the Open Archive plugin which provided support is a fine piece of work it was an incomplete implementation with only 1-to-1 chats (no group chat support). I worked on merging the monitoring and open archive plugins to provide support for both MUC and 1-to-1 using XEP-0136. That work was only fully finished a couple years ago in 2013 so think my comment's still accurate.
  - taurath 11y ago
    Adium has a UX and UI from the 90s, for one.
- leonroy 11y ago
  btw. very much agree most of the clients are inadequate but if I could humbly pimp Openfire (I'm a dev there): https://github.com/igniterealtime/Openfire https://github.com/igniterealtime/Openfire And ejabberd of course (powering WhatsApp): https://github.com/processone/ejabberd https://github.com/processone/ejabberd You'll see that on the server side at least XMPP is very well catered for.
  - scrollaway 11y ago
    What are the advantages of OpenFire over ejabberd/prosody?
    - leonroy 11y ago
      Super easy to use, nice admin pages, great plugin architecture for 3rd party developers to extend its functionality. Means there's a LOT of cool plugins which add video, screen sharing, chat archiving, etc. Deal breaker against it (depending on your use case) is lack of support for multiple domains. It can only handle one per deployment. It also does need at least 512MB RAM which rules it out on embedded devices.
  - creshal 11y ago
    I've used both and moved on to prosody. Ejabberd is just too arcane to configure and debug; and openfire is a damn resource hog for no apparent reasons.
leonroy 11y ago
Having used and developed with XMPP day in and out for the past 9 years I'd have to agree with the sentiments towards XMPP being on life support. It's a real damn shame because XMPP is pretty awesome. It's open for one, can be made super secure with OTR (client-2-client encrypted chats), has numerous protocols and implementations for stuff as diverse as message archiving, Audio/Video signalling, file transfer, chat (of course), presence and an absolute boat load of other stuff: http://xmpp.org/extensions/index.html http://xmpp.org/extensions/index.html. There are two big issues as far as I can see with XMPP which really hurt it: 1. XMPP was incredibly poor at handling high latency, intermittent network connections (like cellular). Connections would time out, reconnections would take ages and all in all it really hammered battery life. As a consequence mobile app developers moved very quickly onto REST/JSON (yes there was XEP-0198 - Stream Management - but implementations of it were thin on the ground and even then it wasn't perfect). 2. There just isn't any interest amongst new developers or newer projects at least in an XML based chat protocol when REST/JSON is so attractive. Anyone who has had to write a god damned XML parser knows what I'm talking about. Things are a whole lot better now. XMPP has fixed a lot of session and battery life issues since then but to be honest I'm just not feeling it when I go to XMPP meetups. Feel like I'm attending a wake for an old friend and it really is sad because if there was ever gonna be one protocol to rule them all XMPP was far and away the best candidate. Who knows, a couple years from now large companies and governments might finally wake up to the fact that they have 100 different sucky (probably) REST based APIs amongst all their apps which are not remotely compatible and offer poor archiving and retrieval (like they did in the 90s when they forced Microsoft to open up their Office document format). XMPP might come to the fore again then (wouldn't put money on it though). More likely something similar (and not XML based) will take its place. It's anyone's guess really, suffice to say the present situation does feel like a complete and utter mess and will really start biting us in the ass when compliance asks 'how do I archive/retrieve this pot pourri of data'.
- scrollaway 11y ago
  Thanks for the insight. It reflects what I often hear from other people close to XMPP. What are your thoughts on Matrix?
coldtea 11y ago
>I use XMPP every day. All my friends are on XMPP. What makes you think XMPP is dead? What are "various reasons"? Well, it failed to be the preferred solution for its problem domain, and is universally ignored by big players. Google also killed Talk in favor of Hangouts (and the later doesn't talk to XMPP).
- mikekchar 11y ago
  The thing is that Google moved from XMPP to something proprietary specifically to avoid federation. The big players don't want federation and any protocol will suffer the same fate unless it becomes popular without reliance on the big players. I think it is fair to say that XMPP isn't any more dead than any other protocol in this respect.
  - tottenhm 11y ago
    An interesting point. There was a similar issue with SMS (federating with big telcos), and Whatsapp (among others) did a nice job of routing around that (by piggybacking on SMS). It's interesting to think about how a genuinely open player might route around that. For example, suppose you want to send an IM to your friend. You believe in XMPP or some other open/federated protocol, but you don't know which friends use the protocol. Piggyback off email. Note that identities are backed by email. Also, if any identity-providers refuse to join the federation, then route through a trusted fallback service (Trent.com). Pseudocode: function send_im(toEmailAddr, messageText) { // See if the user's domain already supports OpenChatProto. if (nslookup(toEmailAddr.hostname, 'SRV', 'OpenChatProto')) return OpenChatProto.deliver(toEmailAdrr, messageText); // If user's domain doesn't support it, see if the user has // registered+authenticated with a trusted third-party. var proxyAddr = http.get('https://trent.com/proxyAddr?email='+toEmailAddr + authCode); if (proxyAddr) { return OpenChatProto.deliver(proxyAddr, messageText); } // If the user doesn't exist in OpenChatProto, then // fallback to email. var emailText = messageText + "To continue this discussion in real-time chat, go to:" + "https://trent.com/setup?email=" + toEmailAddr + authCode + "To block messages from this person, go to:" + "https://trent.com/optout?email=" + toEmailAddr + senderEmail + authCode + "To opt-out of all messages, go to:" + "https://trent.com/optout?email=" + toEmailAddr + authCode Email.deliver(toEmailAddr, emailText); } Note: It's most efficient if members of the federation agree on the identity of trent.com, but it's not required. Any outbound MTA could use a different Trent, but that fragments the brand and identity databases. This feels pretty obvious, so maybe it's already being done or I'm missing something...

I use XMPP every day. All my friends are on XMPP. What makes you think XMPP is dead? What are "various reasons"?

by Zash 11y ago

I use XMPP every day. All my friends are on XMPP. What makes you think XMPP is dead? What are "various reasons"?

msbarnett 11y ago

Google's abandonment of it was a big, big blow. 90% of my contacts are no longer available via XMPP.

creshal 11y ago

All the servers available for it suck. All the clients available for it suck. I know, I'm using it daily too, but I don't see it gaining more traction that it already has ever again.

pyre 11y ago
What sucks about (e.g.) Adium? I haven't had any major issues with it other than the fact that it doesn't seem to be too actively updated. My biggest complaint is lack of protocol support for other things (e.g. GTalk vs. Hangouts), but that's on libpurple, and the lack of open protocols by the providers.
- leonroy 11y ago
  Developer interest is on the wane in pretty much every XMPP project out there. That's the main issue. XMPP is very much alive in large businesses, especially for system to system interop, but as far as client to server goes I don't see a compelling XMPP client - where's voice, video, chat archiving for example? Compare any XMPP client to Skype for instance and they're not even remotely close.
  - pyre 11y ago
    > chat archiving for example This requires a central server though. This is more a function of the service providing XMPP to you than the client. If you want the functionality on the client, it presumably requires some sort of interop between client and server that I'm not sure it part of the XMPP spec.
    - Qwertious 11y ago
      Sounds like XMPP isn't the solution then, only {???,XMPP} is.
      - pyre 11y ago
        Well, extending the spec could be the solution too. What I was trying to convey was more that there will be a lack of such clients until there is either an agreed-upon extension to the standard, or a popular enough fork of the standard. (at least as far as XMPP is concerned)
        creshal 11y ago
        There is an XMPP extension for it: http://xmpp.org/extensions/xep-0136.html http://xmpp.org/extensions/xep-0136.html The problem is, there are far too damn many XMPP extensions and too few of them see any kind of real adoption.
        leonroy 11y ago
        Pretty much this. Openfire for instance only recently had XEP-0136 implemented across the board on the server side. In the meanwhile I couldn't find a single client with decent support for chat archiving (XEP-0136) on the client side. Not one (and I really looked).
        davecridland 11y ago
        What? Openfire has had XEP-0136 for literally years. I think a little over a decade, actually. It's only recently implemented XEP-0313.
        leonroy 11y ago
        Hi Dave, firstly thanks for all the hard work on Openfire over the years, very much appreciated. Secondly regarding XEP-0136 support in OF. I did state that Openfire has only recently had 'XEP-0136 implemented across the board'. Whilst the Open Archive plugin which provided support is a fine piece of work it was an incomplete implementation with only 1-to-1 chats (no group chat support). I worked on merging the monitoring and open archive plugins to provide support for both MUC and 1-to-1 using XEP-0136. That work was only fully finished a couple years ago in 2013 so think my comment's still accurate.
- taurath 11y ago
  Adium has a UX and UI from the 90s, for one.
leonroy 11y ago
btw. very much agree most of the clients are inadequate but if I could humbly pimp Openfire (I'm a dev there): https://github.com/igniterealtime/Openfire https://github.com/igniterealtime/Openfire And ejabberd of course (powering WhatsApp): https://github.com/processone/ejabberd https://github.com/processone/ejabberd You'll see that on the server side at least XMPP is very well catered for.
- scrollaway 11y ago
  What are the advantages of OpenFire over ejabberd/prosody?
  - leonroy 11y ago
    Super easy to use, nice admin pages, great plugin architecture for 3rd party developers to extend its functionality. Means there's a LOT of cool plugins which add video, screen sharing, chat archiving, etc. Deal breaker against it (depending on your use case) is lack of support for multiple domains. It can only handle one per deployment. It also does need at least 512MB RAM which rules it out on embedded devices.
- creshal 11y ago
  I've used both and moved on to prosody. Ejabberd is just too arcane to configure and debug; and openfire is a damn resource hog for no apparent reasons.

leonroy 11y ago

Having used and developed with XMPP day in and out for the past 9 years I'd have to agree with the sentiments towards XMPP being on life support. It's a real damn shame because XMPP is pretty awesome. It's open for one, can be made super secure with OTR (client-2-client encrypted chats), has numerous protocols and implementations for stuff as diverse as message archiving, Audio/Video signalling, file transfer, chat (of course), presence and an absolute boat load of other stuff: http://xmpp.org/extensions/index.html http://xmpp.org/extensions/index.html. There are two big issues as far as I can see with XMPP which really hurt it: 1. XMPP was incredibly poor at handling high latency, intermittent network connections (like cellular). Connections would time out, reconnections would take ages and all in all it really hammered battery life. As a consequence mobile app developers moved very quickly onto REST/JSON (yes there was XEP-0198 - Stream Management - but implementations of it were thin on the ground and even then it wasn't perfect). 2. There just isn't any interest amongst new developers or newer projects at least in an XML based chat protocol when REST/JSON is so attractive. Anyone who has had to write a god damned XML parser knows what I'm talking about. Things are a whole lot better now. XMPP has fixed a lot of session and battery life issues since then but to be honest I'm just not feeling it when I go to XMPP meetups. Feel like I'm attending a wake for an old friend and it really is sad because if there was ever gonna be one protocol to rule them all XMPP was far and away the best candidate. Who knows, a couple years from now large companies and governments might finally wake up to the fact that they have 100 different sucky (probably) REST based APIs amongst all their apps which are not remotely compatible and offer poor archiving and retrieval (like they did in the 90s when they forced Microsoft to open up their Office document format). XMPP might come to the fore again then (wouldn't put money on it though). More likely something similar (and not XML based) will take its place. It's anyone's guess really, suffice to say the present situation does feel like a complete and utter mess and will really start biting us in the ass when compliance asks 'how do I archive/retrieve this pot pourri of data'.

scrollaway 11y ago
Thanks for the insight. It reflects what I often hear from other people close to XMPP. What are your thoughts on Matrix?

coldtea 11y ago

>I use XMPP every day. All my friends are on XMPP. What makes you think XMPP is dead? What are "various reasons"? Well, it failed to be the preferred solution for its problem domain, and is universally ignored by big players. Google also killed Talk in favor of Hangouts (and the later doesn't talk to XMPP).

mikekchar 11y ago
The thing is that Google moved from XMPP to something proprietary specifically to avoid federation. The big players don't want federation and any protocol will suffer the same fate unless it becomes popular without reliance on the big players. I think it is fair to say that XMPP isn't any more dead than any other protocol in this respect.
- tottenhm 11y ago
  An interesting point. There was a similar issue with SMS (federating with big telcos), and Whatsapp (among others) did a nice job of routing around that (by piggybacking on SMS). It's interesting to think about how a genuinely open player might route around that. For example, suppose you want to send an IM to your friend. You believe in XMPP or some other open/federated protocol, but you don't know which friends use the protocol. Piggyback off email. Note that identities are backed by email. Also, if any identity-providers refuse to join the federation, then route through a trusted fallback service (Trent.com). Pseudocode: function send_im(toEmailAddr, messageText) { // See if the user's domain already supports OpenChatProto. if (nslookup(toEmailAddr.hostname, 'SRV', 'OpenChatProto')) return OpenChatProto.deliver(toEmailAdrr, messageText); // If user's domain doesn't support it, see if the user has // registered+authenticated with a trusted third-party. var proxyAddr = http.get('https://trent.com/proxyAddr?email='+toEmailAddr + authCode); if (proxyAddr) { return OpenChatProto.deliver(proxyAddr, messageText); } // If the user doesn't exist in OpenChatProto, then // fallback to email. var emailText = messageText + "To continue this discussion in real-time chat, go to:" + "https://trent.com/setup?email=" + toEmailAddr + authCode + "To block messages from this person, go to:" + "https://trent.com/optout?email=" + toEmailAddr + senderEmail + authCode + "To opt-out of all messages, go to:" + "https://trent.com/optout?email=" + toEmailAddr + authCode Email.deliver(toEmailAddr, emailText); } Note: It's most efficient if members of the federation agree on the identity of trent.com, but it's not required. Any outbound MTA could use a different Trent, but that fragments the brand and identity databases. This feels pretty obvious, so maybe it's already being done or I'm missing something...