I suspect the thing that held back its adoption for end-users (or is still holding it back) is the fragmented ecosystem and so-so open source clients with questionable inter-compatibility, i.e. you can get calls from Windows to Android to work as an end-user, but it's a rocky path.
Hopefully we can one day see the great XMPP renaissance.
And yet, in 2016, 9 years after the first iPhone, XMPP still struggled to provide any of the modern conveniences on the protocol level: https://gultsch.de/xmpp_2016.html (at the time most of the links marked as "solution available" were going to experimental and beta proposals)
The protocol/backend can be, and often is, as much hindrance as the clients.
I feel like compatibility between clients is good, people just aren't used to having independent implementations anymore. It's easy to cook up your own protocol and have compatibility by being the only game in town but if you look at the bigger picture you have just created more fragmentation. We need more instant messaging standardization and XMPP serves an important role as the IETF internet standard for IM.
Maybe the modern web-based clients like Movim are better, never got around to testing them. I'll admit that Android always was the golden platform for XMPP thanks to Conversations - as long as you stick to that on both ends it's the perfect experience.
FWIW it's been smooth-sailing for me and my non-tech family and friends for many years now. BTW, OTR is deprecated, and OMEMO just works.
This project looks promising too: https://prose.org/
> Windows, where most people live
Most people live on their smartphone for IM these days, at least in my circles. I have been surprised by how few people are actually interested in getting a chat app on their "real computer".
In all honesty, it's not that awesome. It took XMPP over a decade to get features expected from modern protocols such as not requiring persistent connections, client notifications, conversation syncing between clients, file uploads, E2EE...
IRC probably has a similar level of requirements, but I haven't heard of its mobile capabilities. Most others seem to be completely new developments and in the case of Matrix e.g. they seem to have solved some issues by reducing the scalability (higher server load).
So yes, it took a while for XMPP to solve those issues, and you can say it took too long. But at the same time having done that at all, is an achievement in itself.
10 years is not agile.
> Imagine what could be if people focused on XMPP instead of constantly re-inventing the wheel.
We could try and imagine. As it stands, it's XMPP which is reinventing the wheel, continuously. The primary reason being: it was developed at a time when non-persistent internet connection, multi-device synchronisation, video calls, ubiquitous file sharing and other wonders of the modern world didn't exist, and retrofitting it was a multi-year struggle. Undoubtedly prolonged by the very same people who decried the modern world and claimed that XMPP was enough: https://news.ycombinator.com/item?id=38497839
I've been using XMPP since I had a smartphone (I was late to the party, around 2015) and never needed a persistent connection or had issues with multi-device use. https://xmpp.org/extensions/xep-0313.html solves both and the first version is from 2012.
E2EE via opengpg has been there since the beginning of XMPP, and via OMEMO (signal-like) for 7 years now, just like HTTP file upload.
I don't. I know what I'm talking about: https://news.ycombinator.com/item?id=38497839
> solves both and the first version is from 2012.
The question is: when it stopped being experimental and supported by most servers and clients.
- The firewall module to blacklist spammers; that can be done with a system-wide firewall as well, but it is nicer for diagnostics to serve proper errors, not just to drop packets or refuse connections.
- The bosh and websocket modules, to use with converse.js. A web UI is convenient to have for logging in from systems without XMPP clients.
Conversations.im and its developer produce great things for the community:
* Conversations.im itself
* https://snikket.org/open-source/ and https://quicksy.im/ are built on the conversations app
* Hosted XMPP: https://account.conversations.im/
* Compliance testing: https://compliance.conversations.im/
The things that make XMPP unique are very superficial. For a long time, it was the dominant IETF Standard for instant messaging and it has proven that it can adapt to new circumstances (mobile clients), but who cares about such stuff nowadays ;-)
Compared to running your own email server, you just have to solve different problems:
- XMPP has higher uptime requirements (from a user perspective)
- spam is not such a big problem for small installations
- Much lighter in processing and storage requirements (at the cost of group conversation history being a crapshoot)
- Not de facto controlled by New Vector, which I’m gradually losing faith in[1][2]
Snikket (a project I started) is probably the easiest way to get a modern XMPP setup these days, or (if you're more into system packages than docker) it's pretty straightforward to get up and running with Prosody, this guide being a good indication of the few things to think about beyond "apt install prosody".
Not only text chat, but also audio/video calls, file transfer. And not sure if it is exactly a "niche", but it is a standard for a federated IM, quite widely supported. Probably the only comparable alternative now is Matrix, but that comes with a bunch of downsides.
> This feels like a step beyond running your own email server.
Running both XMPP and mail servers, I find that an XMPP server setup is easier: there are fewer components, less spam, fewer restrictions on federation; I think you can run it fine even with a residential ISP unless there is a NAT. Not that email setup is particularly hard though.
20 years ago many websites looked exactly like that. Hand-written (<!-- vim: set filetype=rst: -->) and just with basic CSS formatting.