It's XMPP at core, but - AFAIK - they also do not support server-to-server federation. So you can connect to Facebook chat with any XMPP compatible client, but if you run your own ejabberd server, you can't connect to your server, and then message your Facebook friends.
I'm not sure I fully understand this comment. What does it mean to have an "XMPP backend" but not as the interface? And yes, they did use a full, open source XMPP solution for Facebook chat when it started out called "ejabberd". Ejabberd is a terrific solution if you quickly want to have a scalable, real-time messaging and event solution with low maintenance.
This only describes the feature of connecting an XMPP client to facebook chat.
S2S federation means server-to-server. That is, use your XMPP account on your own server (such as prosody, as proposed above) to communicate with facebook users (on facebook's servers).
But that would go against fb's walled garden approach, so it's unlikely to come.
I run my own ejabberd instance for a group of friends and it obviously works.
I do manual account creation and know people there (or they are vetted by my friends). The server federates with any other server that supports s2s encryption so they can talk to whoever they want.
On windows probably the most mature client is Gajim. You can use it on Linux too, but there are more alternatives (such as the more modern Dino.im) On Android there is the excellent Conversations, with a few more to choose from. Or you can go with a platform-independent web-based client and use Movim. All support OMEMO. I am not invested in the Apple ecosystem so I don't know about that (Beagle IM? Monal?).
Typically the XMPP naysaying is a mix of bad experiences in the past and NIH syndrome. Things like server-side message archiving, message carbons, message delivery receipts or MUCs are long solved. You want to make a stand for open, federated internet you need to put your money where your mouth is.
About the only sore points are cross-platform VoIP (Windows lacking here) and direct file transfers (SOCKS5 bytestreams are wonky which leaves http uploads) although arguably neither have to be a part of a chat application.
> Being able to point your Facebook Messenger client at a different server would be a big step.
Interestingly, you used to be able to do the inverse: point your XMPP client at Facebook Messenger. I'm pretty sure they never supported federation, but you could connect clients to multiple servers and have a relatively seamless experience from a single client.
I used FB Messenger over XMPP for the last handful of years before it was shut down using Pidgin and I'm pretty sure that's how it worked. You could talk to people on different networks but you needed your own FB account to talk on Messenger and you couldn't do group chats cross-network.
GTalk and self-hosted XMPP could federate and you only needed one account and conversations could span servers.
If only there was a way for these different providers to interoperate. XMPP gets us most of the way there, but is a bit short on features - inline images still seem to be in development, for example. Worse, those providers that do support it don't consistently support federation, so I still can't talk to a Facebook user from Google Chat.
No one is taking xmpp away from your server or the applications that are using it; but take Facebook: did they do any effort of integrating their chat with the Gmail one?
Like Facebook, they're only using XMPP for client-to-server. That is, you can use any run of the mill Jabber client to talk to your friends on MSN. I'll be impressed if they choose to do federation (server-to-server) like Google does so that you can use your Gmail account to chat with your Hotmail friends. That would be handy.
reply