There is no federated client-independent IM future with Hangouts because the Hangout model does not map to instant messaging. It's not about protocol support.
I have not used hangouts, but the name appears to suggest some sort of chatroom? Wouldn’t a XMPP MUC[0] do the trick at least for text-based chats? I can hardly imagine someone wanting to use audio/video all the time anyhow.
Not as simple as that. I actually took a look at the XMPP extensions list to see if I could replicate Hangouts on top of them. You'd need a new audio/video layer with support for centralised DSP, MUC and carbon copies at the very minimum. Not to mention typing notifications (do they work with MUC?), cross-client notification dismissal, automatic client priority assignment (if I'm using a client atm, don't ring all devices, just the one I'm using) and I'm sure a lot more.
Half of these things (e.g. carbon copies) are spec'd out but barely supported.
Hm, most of that is already supported (both in the spec, clients and servers) in user-to-user chats, I don’t know how difficult it will be for MUCs. Audio/Video is the problematic part here, I agree, but at least for me text is a big improvement over the times when I had to call people.
Would it not have been possible to offer a XMPP MUC as a text-based interface to hangouts, to allow ‘legacy’ users to still be connected?
As well as the OLPC extensions for transports to support application and screen sharing.
The X in XMPP is for extensible. I guess the point is Skype doesn't support XMPP or federation, and Microsoft is moving towards Skype and away from their SIP/SIMPLE chat services. Likewise, Apple's promise of an open standard for interoperating with Facetime turned out to be empty.
There was some discussion regarding the Facetime and open sourcing it on HN a while back, I can't find the source this quickly, but it was mentioned that Apple found itself on the barrel end of a lawsuit gun... and that because of that they have not improved Facetime much, nor innovated on it, or published any of the spec.
And as you say - there's a bunch of stuff to support if you go the traditional route and try to bolt on more crap to MUC or <message> stanzas. We're considering just building hangouts on top of "ephemeral" buddycloud channels that just disappear when the last recipient leaves them.
A very valid question. It was probably the outcome of a team meeting (don't we love them?), and one or more people were present with reasons not to take this route. What those reasons were, or whether they were well-founded, we'll never know.
They could publish these reasons to the angry users who are being cut off from their contacts by this. Not doing it shows the low culture of Google in regards to treating users. Evil or not evil, it's simply indecent.
Hangouts also provides information about whether your messages were viewed and syncs chat history across devices whether they were online at the time the message was sent or not.
Message Receipt Notification is XEP-0184 and supported in most clients, though I don’t know how it works in MUCs.
XMPP also has a spec for server-side history storage, that allows for syncing to clients. I don’t know how well it is supported in reality, but understand that there are at least ejabberd modules for the server-side part and a plugin for Pidgin to view this stored history. Not perfect, yet.
I don't care much about receipt notification but chat history sync was probably one of my biggest annoyances with GTalk. I'm glad to see it solved in some way although it is disappointing that Hangouts doesn't support XMPP anymore.
Well, it is being addressed. Ideally, I would like my phone to tell the server to save history of its chats, Pidgin on the desktop syncing these chats over from the server and then deleting them from the server and the server making sure that, if Pidgin is running, it gets messages instantly even if they are sent to/from the phone, either by pushing Pidgin to sync history or ignoring the full JID and always doing a CC to Pidgin.
I guess it is a long way till we get there, though :|
Could you set things up so that a handshake and connection details can be negotiated over XMPP and then have the hangouts-like connection established on a different port. i.e. do something similar to websockets, where connections are negotiated on port 80 and then promoted to a non-standard HTTP port to communicate via a different protocol.
