Man, remember the late 90s and early 2000s, when the IM scene was a mess of incompatible networks like ICQ and AIM and MSN Messenger, and people were like "fuck this" and came up with this protocol that was interoperable with all the others through gateways and also it was extendable, and we could all be happy together?...
/grump
The worst part is that WhatsApp is actually based on Jabber >:(
I recently started looking into XMPP again a few days ago. I have a few ideas for projects built on top thereof.
Can anybody recommend XMPP servers? I know duckduckgo has an XMPP service up and running, but I can't seem to find any relevant API documentation. All I found was this [0], which doesn't go into details about encryption settings and isn't very useful for programmatic interaction.
Extensions that implement server-side XEPs are really easy to add on as well. Just git pull the community XEP repo and then add a line to the ini and you can add more superpowers. I have it on a cheap VPS. I'm using conversations with it and it has been mostly flawless. Now I just need a good linux application that understands OMEMO. There's a Gajim hack, but it's kind of messy.
Conversations.im has made great progress in making XMPP usable on mobile devices, although its services don't seem ready for public adoption quite yet. There are very few XMPP servers which support the XEPs Conversations does so while federation is theoretically possible, it is not yet a reality.
The new extensions are all public and supported by the two main server implementations, prosody and ejabberd. You can nicely ask your server operator to enable them.
Yep. In addition to that, it’s also FOSS¹ and you aren’t limited to only getting it from the Google Play Store; it’s also distributed² on F-Droid³ too. One thing to note though is that the version of Conversations on F-Droid doesn’t support push notifications, since that functionality uses Google Cloud Notifications.
I used ejabberd (https://www.ejabberd.im/) and it was fairly easy to get up and running and make minor tweaks like logging conversations, but I can't say about encryption but it seems to have it from cursory web searching. It's Erlang so that was an interesting learning hurdle.
I'm a big fan of jabber.at; it should support most modern XMPP features. Dukgo is notorious for not supporting new features and having large ammounts of downtime, I would not recommend it.
And yes, I absolutely realize that the protocol had flaws, was overly verbose, the base spec required a continuous connection which is hard/impossible on mobile networks, its extensibility meant that clients could end up with little common compatibility, etc etc... But still.
A continuous connection is actually desirable on mobile networks to save battery; your phone can turn the radio on to a power saving mode if you use a single TCP connection and no traffic is being sent and only wake it up again when it gets a paging message alerting it that there is new data to be sent down over the TCP connection. However, if you use something that requires multiple connections (eg. to poll and see if new data is available), you will have to put the radio into full power mode every time you poll to check if there's new data.
The protocol is an absolute nightmare to work with, even when you're only using it for your own internal systems and so control everything that's involved. I heard that WhatsApp stopped using it long ago, and if so, that wouldn't surprise me.
Jabber is still around and works, there is nothing that stops you from using it.
However, clearly people prefer to use other systems, such as Whatsapp. They offered something different (and simple) enough that it enticed people to use it, and so they have the users. It would appear that people just don't care enough about interoperability to switch to something else.
> Man, remember the late 90s and early 2000s, when the IM scene was a mess of incompatible networks like ICQ and AIM and MSN Messenger, and people were like "fuck this" and came up with this protocol that was interoperable with all the others through gateways and also it was extendable, and we could all be happy together?
XMPP isn't an "open federation protocol" it's just a protocol that includes a means to federate; doing so is a matter of server preference. It would be great if more large services federated, but I'd rather have them use XMPP and not federate than build more custom protocols and not use XMPP at all so that I can't write a third party client for them.
My point is that being based on XMPP is still a good thing, regardless of whether they federate or not.
The whole point of XMPP is interoperability, so saying some proprietary service uses it internally is useless for the rest of the world without interoperability.
Can you connect with third party clients? Can they federate? Are they contributing to the protocol? No.
Big proprietary users of protocols tend to discover bugs in them, that they feed upstream, even if they run otherwise closed networks.
E.g. it benefits you that Google uses TCP internally, even if you can't get on their network? Why? Because they've submitted patches to Linux to make it work better.
So what if they did? How are we any worse off than if they'd written their own TCP replacement from scratch to begin with?
Maybe someone outside Google gains nothing, but presumably their engineers will spend less time reinvesting the wheel, which is a net gain for humanity in less time wasted.
> but I'd rather have them use XMPP and not federate than build more custom protocols
Well, bad news then: They never federated and they modified their implementation of XMPP to the point of third party clients not being able to connect.
/grump
The worst part is that WhatsApp is actually based on Jabber >:(