5 ms·

XMPP was actually fairly successful. It was just embraced, extended, and extinguished by the major companies that provided services using it. Google, Facebook,

XMPP was actually fairly successful. It was just embraced, extended, and extinguished by the major companies that provided services using it. Google, Facebook, and Atlassian all used XMPP for their chat clients. You could freely interact with all of their chat solutions using XMPP clients. XMPP support for each one of them went away one by one. The environment outside of major providers was (it definitely is) kind of janky. If you can set up a server application it's not hard but it's not exactly easy to get started, or get people on it without handholding (from my own experience).

e12e 4y ago
I suppose this includes irc in a way too - AFAIK slack used to be (mostly) just a propiatary IRC network and client?
- sc68cal 4y ago
  They had IRC gateways that you could use to connect your IRC client into slack, but I don't think their architecture started like the IRC protocol. It appears to have at one time just been a webapp, with databases for storage for messages. Not anything like IRC's protocol/architecture. https://www.slideshare.net/InfoQ/how-slack-works https://www.slideshare.net/InfoQ/how-slack-works It may have subsequently turned into something more like how IRC servers work, but early on it doesn't appear to have been.
- nitia 4y ago
  Twitch still is
dsr_ 4y ago
And, if I understand correctly, the text chat in Zoom is XMPP. All of these companies chose to kill federation for their own advantage, making the world poorer.
- mike_hearn 4y ago
  Not really. Google killed XMPP federation because virtually nothing used it except spammers, who were becoming a big problem. Controlling spam inside a closed network is drastically easier than controlling spam in an open network, because in a closed network you have lots of ways to make bans stick, whereas in an open network you really can't. Faced with the choice of building a massive Gmail style heuristic spam filter in which basically all the messages it was processing would be spam, or, just turning off federation, they went for the latter. It was probably the right call. Very few people even noticed, let alone cared. The idea of an SMTP-style global network of federated chat servers was dead by that point.
  - MattJ100 4y ago
    They killed it mainly because there was a dictate to unify around the emerging Google+ (I'm pretty sure there is a public source for this, but I fail to find it right now, otherwise I would link it here). I'm not saying they didn't have spam problems, but that's the kind of thing they certainly had resources to solve. They already had such systems due to Gmail, and even independent XMPP operators have a pretty good handle on XMPP spam these days without even a fraction of the resources available to Google. It was more a matter of priorities du jour for the company.
    - mike_hearn 4y ago
      Well, I was there at the time and this is what I remember. The Gmail spam filter is very email specific, it's not like you could just point it at a stream of chat messages and get good results. Independent XMPP operators don't have anywhere near the spam problems Google has/had. They're just far less appealing targets.
  - AshamedCaptain 4y ago
    That's manipulation of history. XMPP federation was actually still working on the Google Talk servers even as recently as a couple years ago. However, Google outright refused to update their XMPP server capabilities. I am not talking about refusing to implement the latest XEPs (which they don't), I am talking that they didn't even bother to implement SSL! https://xmpp.org/2015/03/no-its-not-the-end-of-xmpp-for-google-talk/ https://xmpp.org/2015/03/no-its-not-the-end-of-xmpp-for-goog... Google was kicked by the other servers out of federation due to their abandonment way before Google turned it off. And it was always flacky to begin with, specially since they also started dropping 3rd party clients (and for that you can't blame spam...). And even if one argues that Google ignored federation because of spam and/or low usage, OP's claim that they did that "for their own advantage, making the world poorer" would still be valid.
synicalx 4y ago
A company I used to work at had an in-app chat feature that ran entirely on XMPP, specifically using ejabberd which scaled really well. Can't say it was super intuitive to setup and run though, there was definitely a learning curve.
theamk 4y ago
We used XMPP as our work chat back in 2010's. We run our own server and everything. I am not sure why -- was it a bad setup or an bad protocol? -- but experience was horrible compared to other chats. The biggest problem I remember was that XMPP was (is?) about message delivery, while what we really wanted was "synchronized message log". So multi device did not work: One device was designated "active" and would receive the messages, others would not. There was no history sync of any sort: If you had checked messages from home, they would not appear in your work computer's history next morning. If you replied from home, you won't be able to see your own messages at work PC. Anything mobile (mobile phone, laptop in coffee shops) was also unusable -- you cannot start app and catch up on all missing messages. You had to be online to receive them. For mobile access, I ended up doing custom Pidgin plugin (in perl!) which would export messages to text documents served over webserver, and then I'd visit that page from my phone to read the messages. --- I still don't know what was wrong with that system, was this our admin not spending enough time on the server, bad documentation, or bad clients -- but this did not really matter, this experience really destroyed XMPP brand. We used Google Talk and Slack later, and they were "just working", no batteries required, no messages lost. The funny thing I believe that Google Talk might have used XMPP under a hood at some point -- but it worked really well. So it is definitely possible to build working, feature-full things on XMPP... you just had to extend it and use it as underlying layer. Kinda like TCP and IP in a way.
- MattJ100 4y ago
  Google Talk was XMPP from start to finish. At its peak, Google folk participated in the standards process. They also contributed various protocol extensions, including the one for audio/video calls. Their open-source implementation of this (libjingle) still lives on as a part of their WebRTC stack in Chrome. You're spot on with your memory of early XMPP's behaviour. While it was one of the first messaging protocols to support simultaneous login, the focus was originally about routing messages to the right device. In the context of that period in tech, that was excusable and even desirable. As people got more devices connected, more permanently yet intermittently (i.e. smartphones), it stopped making any sense. We switched to a broadcast-and-sync approach, but it took a long time (years) for all the long tail of smaller internal deployments to roll that out (if they ever did). Another big issue was that one of the most popular clients was Pidgin, which ran into developer resource issues around the same time and still hasn't caught up yet. To many people though, this was XMPP. I'm hoping a new generation of XMPP implementations can solve these kinds of issues, which was what inspired my "Products vs Protocols" [1] talk/article a couple of years ago, and is why I work on Snikket (and we have many happy users who are both new and not-so-new to XMPP). [1]: https://snikket.org/blog/products-vs-protocols/ https://snikket.org/blog/products-vs-protocols/

e12e 4y ago

I suppose this includes irc in a way too - AFAIK slack used to be (mostly) just a propiatary IRC network and client?

sc68cal 4y ago
They had IRC gateways that you could use to connect your IRC client into slack, but I don't think their architecture started like the IRC protocol. It appears to have at one time just been a webapp, with databases for storage for messages. Not anything like IRC's protocol/architecture. https://www.slideshare.net/InfoQ/how-slack-works https://www.slideshare.net/InfoQ/how-slack-works It may have subsequently turned into something more like how IRC servers work, but early on it doesn't appear to have been.
nitia 4y ago
Twitch still is

dsr_ 4y ago

And, if I understand correctly, the text chat in Zoom is XMPP. All of these companies chose to kill federation for their own advantage, making the world poorer.

mike_hearn 4y ago
Not really. Google killed XMPP federation because virtually nothing used it except spammers, who were becoming a big problem. Controlling spam inside a closed network is drastically easier than controlling spam in an open network, because in a closed network you have lots of ways to make bans stick, whereas in an open network you really can't. Faced with the choice of building a massive Gmail style heuristic spam filter in which basically all the messages it was processing would be spam, or, just turning off federation, they went for the latter. It was probably the right call. Very few people even noticed, let alone cared. The idea of an SMTP-style global network of federated chat servers was dead by that point.
- MattJ100 4y ago
  They killed it mainly because there was a dictate to unify around the emerging Google+ (I'm pretty sure there is a public source for this, but I fail to find it right now, otherwise I would link it here). I'm not saying they didn't have spam problems, but that's the kind of thing they certainly had resources to solve. They already had such systems due to Gmail, and even independent XMPP operators have a pretty good handle on XMPP spam these days without even a fraction of the resources available to Google. It was more a matter of priorities du jour for the company.
  - mike_hearn 4y ago
    Well, I was there at the time and this is what I remember. The Gmail spam filter is very email specific, it's not like you could just point it at a stream of chat messages and get good results. Independent XMPP operators don't have anywhere near the spam problems Google has/had. They're just far less appealing targets.
- AshamedCaptain 4y ago
  That's manipulation of history. XMPP federation was actually still working on the Google Talk servers even as recently as a couple years ago. However, Google outright refused to update their XMPP server capabilities. I am not talking about refusing to implement the latest XEPs (which they don't), I am talking that they didn't even bother to implement SSL! https://xmpp.org/2015/03/no-its-not-the-end-of-xmpp-for-google-talk/ https://xmpp.org/2015/03/no-its-not-the-end-of-xmpp-for-goog... Google was kicked by the other servers out of federation due to their abandonment way before Google turned it off. And it was always flacky to begin with, specially since they also started dropping 3rd party clients (and for that you can't blame spam...). And even if one argues that Google ignored federation because of spam and/or low usage, OP's claim that they did that "for their own advantage, making the world poorer" would still be valid.

synicalx 4y ago

A company I used to work at had an in-app chat feature that ran entirely on XMPP, specifically using ejabberd which scaled really well. Can't say it was super intuitive to setup and run though, there was definitely a learning curve.

theamk 4y ago

We used XMPP as our work chat back in 2010's. We run our own server and everything. I am not sure why -- was it a bad setup or an bad protocol? -- but experience was horrible compared to other chats. The biggest problem I remember was that XMPP was (is?) about message delivery, while what we really wanted was "synchronized message log". So multi device did not work: One device was designated "active" and would receive the messages, others would not. There was no history sync of any sort: If you had checked messages from home, they would not appear in your work computer's history next morning. If you replied from home, you won't be able to see your own messages at work PC. Anything mobile (mobile phone, laptop in coffee shops) was also unusable -- you cannot start app and catch up on all missing messages. You had to be online to receive them. For mobile access, I ended up doing custom Pidgin plugin (in perl!) which would export messages to text documents served over webserver, and then I'd visit that page from my phone to read the messages. --- I still don't know what was wrong with that system, was this our admin not spending enough time on the server, bad documentation, or bad clients -- but this did not really matter, this experience really destroyed XMPP brand. We used Google Talk and Slack later, and they were "just working", no batteries required, no messages lost. The funny thing I believe that Google Talk might have used XMPP under a hood at some point -- but it worked really well. So it is definitely possible to build working, feature-full things on XMPP... you just had to extend it and use it as underlying layer. Kinda like TCP and IP in a way.

MattJ100 4y ago
Google Talk was XMPP from start to finish. At its peak, Google folk participated in the standards process. They also contributed various protocol extensions, including the one for audio/video calls. Their open-source implementation of this (libjingle) still lives on as a part of their WebRTC stack in Chrome. You're spot on with your memory of early XMPP's behaviour. While it was one of the first messaging protocols to support simultaneous login, the focus was originally about routing messages to the right device. In the context of that period in tech, that was excusable and even desirable. As people got more devices connected, more permanently yet intermittently (i.e. smartphones), it stopped making any sense. We switched to a broadcast-and-sync approach, but it took a long time (years) for all the long tail of smaller internal deployments to roll that out (if they ever did). Another big issue was that one of the most popular clients was Pidgin, which ran into developer resource issues around the same time and still hasn't caught up yet. To many people though, this was XMPP. I'm hoping a new generation of XMPP implementations can solve these kinds of issues, which was what inspired my "Products vs Protocols" [1] talk/article a couple of years ago, and is why I work on Snikket (and we have many happy users who are both new and not-so-new to XMPP). [1]: https://snikket.org/blog/products-vs-protocols/ https://snikket.org/blog/products-vs-protocols/