> Well, it failed to be the preferred solution for its problem domain,

Google Talk, Facebook Chat, Origin (EA), Playstation, Cisco WebEx, WhatsApp all use/used XMPP for instant messaging.

That sounds like it's the preferred solution for realtime messaging, with vendor lock-in and NIH syndrome decisions being the major reasons that it isn't used in even more situations.

> and is universally ignored by big players.

As evidenced by the above list of major deployments, it is absolutely not "universally ignored". The problem (as someone else pointed out) is that for many of the "big players" a federated protocol is not what they want, so they don't allow federation, and don't allow/publicise the use of standard XMPP clients.

> Google also killed Talk in favor of Hangouts (and the later doesn't talk to XMPP).

This is a reason to stop using Google services, not a reason to claim XMPP is ill-suited to the task at hand.

The thing is that Google moved from XMPP to something proprietary specifically to avoid federation. The big players don't want federation and any protocol will suffer the same fate unless it becomes popular without reliance on the big players. I think it is fair to say that XMPP isn't any more dead than any other protocol in this respect.

An interesting point. There was a similar issue with SMS (federating with big telcos), and Whatsapp (among others) did a nice job of routing around that (by piggybacking on SMS). It's interesting to think about how a genuinely open player might route around that.

For example, suppose you want to send an IM to your friend. You believe in XMPP or some other open/federated protocol, but you don't know which friends use the protocol. Piggyback off email. Note that identities are backed by email. Also, if any identity-providers refuse to join the federation, then route through a trusted fallback service (Trent.com). Pseudocode:

function send_im(toEmailAddr, messageText) { // See if the user's domain already supports OpenChatProto. if (nslookup(toEmailAddr.hostname, 'SRV', 'OpenChatProto')) return OpenChatProto.deliver(toEmailAdrr, messageText);

  // If user's domain doesn't support it, see if the user has
  // registered+authenticated with a trusted third-party.
  var proxyAddr = http.get('https://trent.com/proxyAddr?email='+toEmailAddr + authCode);
  if (proxyAddr) {
    return OpenChatProto.deliver(proxyAddr, messageText);
  }

  // If the user doesn't exist in OpenChatProto, then
  // fallback to email.
  var emailText 
    = messageText
    + "To continue this discussion in real-time chat, go to:"
    + "https://trent.com/setup?email=" + toEmailAddr + authCode
    + "To block messages from this person, go to:"
    + "https://trent.com/optout?email=" + toEmailAddr + senderEmail + authCode
    + "To opt-out of all messages, go to:"
    + "https://trent.com/optout?email=" + toEmailAddr + authCode

  Email.deliver(toEmailAddr, emailText);

}

Note: It's most efficient if members of the federation agree on the identity of trent.com, but it's not required. Any outbound MTA could use a different Trent, but that fragments the brand and identity databases.

This feels pretty obvious, so maybe it's already being done or I'm missing something...