I think it started to die when Google decided the XMPP spec was not good enough for them and deviated from it, eventually abandoning it completely. Then, came Facebook and almost everybody people knew was there so it was convenient.
I wish it would come back though. OTR encryption was fairly easy to setup and under my control.
It was my impression that Google dropped XMPP support not because of the spec being "not good", but because they saw now advantage allowing the federation, since nearly nobody else federated with them, while it comes with a cost.
The XMPP specification is open and in large parts malleable, nothing would have stopped Google from participating in improving it.
XMPP is still used in many places, including in online gaming https://xmpp.org/uses/gaming.html. Unfortunately without the federation support (which can be explained in those specific cases).
federation with xmpp doesn't need to be configured. it is automatic. all you need to do is to send a message to someone on a different server. i am not on google, so i used this all the time to talk to people on google. until they stopped.
to get advanced features, google would have had to create a client that uses those features. much like they created the chrome browser.
i guess there just wasn't enough value in doing so. and there were to few people like me who communicated from the outside.
The only solution out there that supports cross platform JINGLE is AstraChat[^1], which is closed source and commercial, but they lack OMEMO and Carbons.
Conversations on Android has both OMEMO and Carbons, but no audio/video or p2p transfer files.
Pidgin, Empathy, Gajim, etc are lacking behind with features, though Pidgin can be made reasonable up to date, still without JINGLE[^2].
Dino[^3] is promising, but it linux only.
I don't know how Trillian is doing these days.
[^1]: https://astrachat.com/
[^2]: https://petermolnar.net/instant-messenger-hell/#adding-netwo...
[^3]: https://dino.im/
XMPP seems to be moving away from that as it is impossible to do reliably with the current brokenness of the internet. The current hotness involves uploading the file to the XMPP server and then just providing a https link to the other client(s). The contents can be encrypted but client support is spotty. So sometimes you have to trust the server. Still way better than the old thing.
I am personally not at all sad if my IM client can't do audio/video. Just let me send a damn text message and have it come out at the other end reliably.
Could be even more cool if you could just post a file to a group chat and it would be shared via BitTorrent behind the scenes.
> I am personally not at all sad if my IM client can't do audio/video. Just let me send a damn text message and have it come out at the other end reliably.
I agree. I can hardly see why texting and voice calling is always meant to be done with the same app.
So why won't somebody just make a great XMPP client with all the features, make it closed-source and commercial and earn money from it? They could make 3 versions: enterprise with some enterprise features (like CRM/LDAP integration etc), standard and adware - I would gladly buy the second or use the first if the ads were unintrusive and not personalized with my personal data like messages text or contacts.
People make instant messengers, why does everybody have to invent their own protocol? Is XMPP actually so hard to implement?
Pidgin is quite lacking as far as Carbons and OMEMO is concerned. Last time I checked you need to install custom plugins, issue text commands to configure the plugin, issue different commands to trust/distrust OMEMO keys etc. It's a lot of work which is probably partly due to the fact the libpurple tries to handle a lot of different protocols using a more-or-less transparent API. It does a fairly good job with most protocols (including proprietary ones through plugins; like hangouts [1]) but unfortunately its XMPP support is not really up to modern standards without effort (much more so than Gajim).
Dino is good and I think they solved some OMEMO compatibility issues they had. But it's Linux only. This is not necessarily bad since they can do much better work by focusing on a specific platform, both functionality- and aesthetics-wise. It's too bad there isn't anything comparable on Windows/Mac.
[0]: https://dev.gajim.org/gajim/gajim/wikis/help/GajimXEPSupport
[1]: https://bitbucket.org/EionRobb/purple-hangouts/wiki/Home
Services need to be able to iterate quickly to deliver features that other services have, introduce new ones that give them a competitive advantage, and improve UX, all at the same time. Federation and standardization do not help in achieving any of that.
There is nothing wrong with XMPP, it's not a technical issue.
There is a lot of interesting XMPP stuff happening right now with respect to the currently hot topic of privacy which could affect XMPP popularity.
There are over a hundred known public XMPP servers last I looked. Due to Let's Encrypt those servers are now encrypting the server to server and client to server links in a meaningful way.
The encryption from Signal has been integrated into XMPP with OMEMO. This suddenly makes XMPP a lot more interesting in terms of privacy. The clients are mostly moving to OMEMO end to end encryption which as a nice bonus eliminates the user awkwardness with the last thing (OTR):
End to end encryption is basically impossible to do properly with a web client. An interesting discussion for Movim can be found here:
I want to disagree with this specifically. There is lots of money in email. /me eyes Gmail, Yahoo, Microsoft.
Also, clients. https://conversations.im/ is good for Android . https://dino.im/ looks like a promising Desktop client but where are the iOS clients? Stuck in XMPP dark ages from what I've heard.
I guess most of the developers that worked with it had a bad time. That would be my bet why it hasn't taken of.
IMO we need something simpler, websocket and JSON based. Less standards, less use-cases - for example I don't think xmpp should take care of vcards, nickname and tons of other things I forgot about. Programmer should be able to grok it realtively quickly and then specifics of your application should take longer to understand instead of having to spend ages on XMPP first and then ages on your specific hacks around it.
Why JSON? JSON is the packaging format of this decade but remember when XMPP was conceived XML was the packaging format of that decade.
Maybe CBOR would be more appropriate. No need to encode binary data (signatures, encryption) in base64 wrappers and more efficient encoding of frequently used stuff (no need for Whatsapp-stype FunXMPP).
> annoying that you have to bring in XML parsing libraries
Uhhhhhh...
https://developer.mozilla.org/en-US/docs/Web/Guide/Parsing_a...
When I said web I should really say javascript. If you replace it my point still stands.
I thought we are in "mobile first" era already...
out of curiosity: what platform?
I think I've never seen a platform where XMPP is not supported, even AtheOS, BeOS, GNU/Hurd, PalmOS and QNX have libraries for it.
> IMO we need something simpler, websocket and JSON based
nothing is stopping you to build a layer of compatibility
React Native - iOS JavaScript runtime + Android JSC runtime.
> nothing is stopping you to build a layer of compatibility
I don't have 10 engineers. It's already super complex. Adding extra layer will just make things worse. I reckon custom solution would be simpler for majority of use cases.
there are Java, Javascript and Swift libraries for XMPP
> I don't have 10 engineers. It's already super complex
The point is XMPP is a solved problem, you can simply use what you need of it, making it json over websocket won't make it anyway easier, you would use a library anyway
Creating protocols just for the sake of it, it's the reason why this comic exists https://xkcd.com/927/
p.s.: Movim, afaik, solves that problem for you
When you use Movim, it acts as an intermediary between the user's browser and an XMPP server. All the data that is sent and received by these two parties are managed by the Movim core, some of them are also saved in a database (for cache purposes).
From the browser perspective, all communication with Movim is done using WebSockets (except for the "default" page loading). These sockets are proxied through your web-server to the Movim daemon. On the XMPP side Movim connects using pure TCP connections (like any XMPP client).Majority of JS XMPP libraries depend on the DOM for xml parsing - see strophe.js for example. This won't work in all JSC runtimes.
> The point is XMPP is a solved problem
Ye, which problem exactly? All of them are solved partially. Let me give you example, imagine you have a platform where users can chat in chatrooms (as simple as it gets really). On your platform you have a username and you are supposed to communicate with others with your username. You'd think xmpp is perfect! Nope, you'll have to fork the xmpp server for this use case. Why? Well, because XMPP standard supports nickname changing, which means in a context of a platform it would allow nickname spoofing. So you need to modify and add some security rules on top of it. "Solved problem" of course...
Nicknames can be registered against a MUC so that other users can't use them. See here: https://xmpp.org/extensions/xep-0045.html#register
This has been part of the MUC standard for years and there are XMPP servers which support this, so you don't need to fork.
If you want to support nickname changing and still know whether it's the same user, you can use the newer XEP-0421: https://xmpp.org/extensions/xep-0421.html
If it's Javascript it's already cross platform
> Ye, which problem exactly?
communicating via XMPP in a standardized way
> All of them are solved partially
And a new protocol based on half backed technologies would change that, how exactly?
> On your platform you have a username and you are supposed to communicate with others with your username.
On any forum or BBS I've been part of in my life, I've always used a nick, that changed over time.
> Well, because XMPP standard supports nickname changing, which means in a context of a platform it would allow nickname spoofing.
That's a feature, not a bug.
In 1995 I could change my nick on IRC, in 1997 I could change my nick on ICQ, I still can change nick on Skype today (my artists friends do it on facebook all the times)
Anyway, nick spoofing on XMPP is hardly a problem and it's not an XMPP fault.
Have you ever tried to search for "someone has been impersonating me with FB messenger" on a search engine?
> "Solved problem" of course.
XMPP it's a solved problem, your chat where nick cannot be changed is your problem.
Every implementation of standard protocols requires work, HTTP is a solved problem, but edge cases still exist.
Name one standard federated protocol that could help you with that and make it simpler, please.
Because I don't know any.
You mean you just want to use RFC 6120/6121? That's fine, just do it then.
When you can receive messages from anyone, you will receive huge amounts of spam.
So, as with many of the rest of the web’s problems, it’s spyvertising’s fault.
Most people attribute it to the lack of standardisation regarding server implementations, or "which XEPs can I support" but normally when those situations happen a single set of things takes off because it's highly polished or packaged as a bundle.
It feels like we were -nearly- there with regards to decentralised IM, but then suddenly we regressed to walled gardens and now I have 10 applications on my phone to communicate with people, each with their own account and very little cross over.