Hacker News Reader

Comment by AceJohnny2 | Hacker News Reader

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 >:(

View on HN

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.

[0] https://duck.co/blog/post/2/using-pidgin-with-xmpp-jabber

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.

https://account.conversations.im/

Thanks. I can't really justify using a paid XMPP service, though. I was hoping for something indefinitely free.

(Maybe I should look into running my own server...)

If you only need voice + video, Ostel has been running for a few years.

https://ostel.co/

You do not need an account at conversations.im – the app works without it.

Ah, okay. I misunderstood. Cool!

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.

――――――

¹ — https://github.com/siacs/Conversations

² — https://f-droid.org/repository/browse/?fdid=eu.siacs.convers...

³ — https://en.wikipedia.org/wiki/F-Droid

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.

See also zom.im - wraps up otr and xmpp in a package along with boatload of cuteness - and is FOSS:

https://github.com/zom/Zom-Android

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.

I use prosody and it's really slick.

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.

[0]: https://prosody.im/

Openfire is actively developed. https://www.igniterealtime.org/projects/openfire/

I used tigase server and tried building an open source messaging client that you can use to chat as well as share your realtime location with your friends and groups : https://play.google.com/store/apps/details?id=co.getintouch....

Never took off in developed world but I strangely got plenty of users in Iran & middle east

Consider looking at matrix.org and vector.im as an alternative that won't make your eyes bleed from the Xcessive nature of XMPP.

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.

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.

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.

This is untrue; WhatsApp still uses a profile of XMPP with a custom compression layer.

Please elaborate on what exactly you dislike about XMPP.

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.

Very tangential: which server do you personally use Conversations with, and does it have gateways to other networks?

> 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?

IRC is still alive, at least.

> The worst part is that WhatsApp is actually based on Jabber

I'm missing something here; why is this a bad thing?

It's ironic; that albeit they started with an open federation protocol they don't federate and are essentially a proprietary service.

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.

So what's good about it?

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.

> E.g. it benefits you that Google uses TCP internally

But they didn't modify TCP to prevent interoperability did they?

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.

as is (original) hangout, facebook chat and probably much more.

in the early days both worked with external clients/servers too.

Reply on news.ycombinator.com