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