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