12 ms·

As a Googler (who does not work on Hangsout) my own personal opinion is that I fully agree with the EFF here: "In public explanations of its dropping XMPP supp

As a Googler (who does not work on Hangsout) my own personal opinion is that I fully agree with the EFF here: "In public explanations of its dropping XMPP support, Google has said that it was a difficult decision necessitated by new technical demands. But even if this new protocol responds to different technical requirements, that shouldn't prevent the company from making it public and interoperable. Releasing the specifications for Google Hangouts would be a good first step. Releasing free/open source clients and servers should follow. It's clear that some of Hangouts' video features have been implemented in some very Google-specific ways. But that's no excuse for leading us toward a world where the only practical choices are proprietary chat clients and protocols." I hope the specs at some point are opened. The Hangouts team probably has good reason at the moment to strictly focus on a core set of functionality and get it working with good UX on all the platforms. People are complaining that stuff like voice calling, and some Talk features are missing, but it's probably due to focus on shipping something that works good first. It's inevitable people will reverse engineer the client, as was done with MSN, Y! Messenger, and AOL. In the late 90s, early 2000s, I remember using reverse engineered Java libraries that could talk to these services. Google Wave was done in the opposite way, as was Open Social. They came with specs, but they did not focus on core user experience in the beginning. It's hard to win with open specs without getting consumer traction.

deepblueocean 13y ago
I was always under the impression that the core Hangouts protocol _was_ the Wave protocol, in which case it's _already_ an open standard. What would be awfully nice is if Google (which is a category mistake - what I really mean is "the Hangouts team") would clarify this, release any updates to the protocol that they've made, and perhaps define something more than the weak API provided for the current Hangouts platform. In particular, the right test of openness is this: can I build an interoperable client that could participate in a Hangout as a first-class entity?
- saraid216 13y ago
  > I was always under the impression that the core Hangouts protocol _was_ the Wave protocol I've never heard this. Do you have anything that backs you up? I found a Quora answer that says that the Hangouts API is based on the the Wave API, but that's it.
- josephg 13y ago
  As a former google wave developer, I can only say that I hope this isn't the case. Wave's federation protocol embedded an XML-like data structure (wavelets) in protobufs (binary) which were then encoded using base64 and embedded in XMPP extensions (ie, more XML). That way lies madness.
  - mh- 13y ago
    thank you for giving me a new 'something' to contrast some of our internal transport cruft. i can now, at least, think positively: 'well, at least it's not XML encapsulated in base64-encoded protobufs shipped over XML.'
  - Camillo 13y ago
    How did Wave end up with that sort of mess? Isn't Google full of Very Smart People?
    - zanny 13y ago
      They do love their XML in Android layouts, though @.@
    - DannyBee 13y ago
      The internal architecture of wave was very abstract. a lot of this abstraction was exposed in the first federation spec, somewhat due to necessity, somewhat due to lack of time.
    - rachelbythebay 13y ago
      Here's a thought: what constitutes a very smart person? How often do those occur in the global population? Now, how many people are there on the planet and how big is the company? The Earth may not be big enough for that to work out. This is before you remove people who aren't in this industry, people who are too young or too old to work there, people who don't want to work there, people who DID work there and left, and so on. It might explain a lot, particularly when they go on a hiring bender. Where are all of these new people coming from?
- drivebyacct2 13y ago
  Where oh where oh where did you get that idea?
spankalee 13y ago
As another Googler, I mostly agree with you, but I also sympathize with the product and engineering teams. They keep seeing very popular apps and messaging products that are completely proprietary and locked in, and that are able to move and innovate fast because they either don't have to conform to an existing standard, or worry about publishing and support whatever internal protocol they do use. Sure Hangouts could publish their protocol like Wave did, but Wave was a complex mess of different protocol formats and transports and publishing that as a "standard" was way premature. Who knows how good the current Hangout protocols are, or how well they might play with real standards like WebRTC. It's probably too early for them I remain optimistic that these things can be standardized in the future.
- cromwellian 13y ago
  I agree with you, history is pretty much full of committee designed specs that failed, but full of defacto standards from commercially successful products that are later standardized. A lot of the features, like group video calling, first need their use cases polished by user trial, then hopefully, they can be implemented on top of either existing standards, provide inputs to change those standards to satisfy the requirements. OpenID/OAuth is an instructive example. The specs were built very much driven by committee oriented thinking, and the resulting UX implementations out of the gate were much more complicated than the Facebook Connect experience. I think actually focusing on the "design" aspect of how users use it, and then extracting the relevant technical requirements into a spec works better.
- rjzzleep 13y ago
  i'm sorry i fail to see the argument. it's perfectly fine to have your own proprietary format, but publish the specs so others can interact with it. who said anything about ietf having to sign it off.
  - ChuckMcM 13y ago
    This is exactly right. It is a false choice to suggest that "open" means "slow". But that is fostered in part by folks who think "open" means "community driven." It is perfectly reasonable to publish the specs of what your doing with no commitment of support, simply for folks to see and possibly use at their own risk. That said, the reason companies don't do this is often one or two reasons. Reason one is that it results in a 'noisy' side channel as people who read the specs share their opinions, but they also get bent out of shape if something they said, or think they said, appears in the spec later. The other issue is that there is always a sanitization/prep process to take essentially internal information about a service and create an external representation for consumption (even if that consumption is unsupported). So the 'easy' choice is to not publish.
deleted 13y ago
[deleted]
saraid216 13y ago
I have to say I really do admire the way the EFF has taken to presuming that Google is a governmental body.
- godgod 13y ago
  The EFF is correct. Google is in lock step with the US governments plans of the complete erosion of our privacy rights. Google knows a lot about us all and the feds want that info.
  - pekk 13y ago
    It isn't accurate to state that the US government "plans the complete erosion of our privacy rights".
    - cmiles74 13y ago
      It certainly seems as if it does. They repeatedly pursue strategies to gain access to private data and actively work against compromise or safeguards. If that is too strong, I think everyone has to agree that shoring up privacy rights is something they are clearly hindering.
  - moultano 13y ago
    Poe's law.
- kps 13y ago
  Where does the article conflate Google with a governmental body?
  - mwfunk 13y ago
    With the implicit assumption that there is any expectation or obligation for Google to conform to some level of openness, especially in (relatively) new products, as if it were paid for with taxpayer money and they owe us something in return. We can say that we wish it were more open, or that we won't use it because it isn't open, but I don't understand the attitude that they are committing some colossal ethical lapse or failing some social contract by not having it be more open at this stage.
zmanian 13y ago
It always seems to be my look Google is heading in the direction of a WebRTC based messaging service/client and then suddenly the product group veers off into another direction. WebRTC has been nearly here for several years now but it does seem to arrive...
graue 13y ago
> It's inevitable people will reverse engineer the client, as was done with MSN, Y! Messenger, and AOL. I hope you're right, but to my knowledge, this has never been done with Skype, and to this day you can only call a Skype-using friend/colleague if you use the official, closed-source Skype client. So let's not be sanguine.
- fryguy 13y ago
  or the closed-source plugin with an API (skypekit.exe)
  - lsaferite 13y ago
    I was so hopeful they would release that at a library so all the open-source IM clients could link to it and get Skype integration. They indicated, years ago, that it was going to be released, but as far as I know, you can still only get it via a developer account.
- josteink 13y ago
  I hope you're right, but to my knowledge, this has never been done with Skype It was done, but Skype has a rule about this which they apply quickly: Press the cease and desist button. I've been using IM clients with support for skype, only to see it get dropped. Which makes it doubleplus sad that MSN (which was fairly interoptable) got ditched for Skype and not the other way around. The only "supported" way for third party IM clients to access Skype's network without risk of lawsuits is piggybacking on its COM API and have the user download and log into the official client, and have that handle all the actual communication. You probably think "He's gotta be kidding", but sadly I'm not. TLDR: Skype does not only not care for or provide an open-source implementation, but they are actively fighting it.
rogerbinns 13y ago
> ... necessitated by new technical demands As a bystander, this comes across as "we aren't smart enough to figure it out", or "we are smart enough, but this is a business decision with ulterior ("evil") motives". Neither of those look positive for Google. I don't expect multi-person video conferences to work, but plain old textual messages, as already work today, shouldn't be a problem.
- aneth4 13y ago
  Wanting to maintain a competitive advantage is not evil in and of itself. Google Hangouts is far from a monopoly and they are under no obligation to make every product completely open. Not only would it be competitively stupid, but it would also hinder product development to be so heavily tied to standards publication.
  - rogerbinns 13y ago
    Google has a marketing approach of being different by not being "evil", being open & accessible, and having smart people work there. The steady drumbeat now is one of being no different than the other guys. Google held themselves up as taking the high road, which is why so many are calling them out on this (and why people don't call out other companies for the same antics). The issue isn't even about making hangouts open, but rather about chat messages in hangouts also being able to relay with federated XMPP servers - something GTalk does today just fine and has done so for many years.
pyre 13y ago
| It's inevitable people will reverse | engineer the client, as was done with MSN, | Y! Messenger, and AOL That's not the end-all be-all though. I remember that AOL was pretty aggressive about keeping unauthorized clients off of their Oscar protocol (the original protocol was 'toc,' IIRC and didn't support all of the 'advanced' features like Buddy Icons, idle times, etc). At one point, AOL's servers would require random chunks of the official AOL IM client's binary as a protection measure. Obviously you can get around this, but it's not something you can do out in the open (distributing AOL IM with, say, Pidgin/libpurple would be copyright infringement).
DannyBee 13y ago
Google Wave was not really done in the opposite way when it came to specs. The spec were largely written by an an intern and a person not part of the wave team helping wave with other things. Everyone else was focused on Wave.
groovy2shoes 13y ago
As an Android user, the new Hangouts app that replaced the Talk app feels like one step forward and four steps back (in terms of UX). The one step forward is that the chat windows look prettier. The four steps back, from most annoying to least annoying: 1) Chat windows give me no indication of the presence of the other participant(s) in a conversation. If they sign off, I have no idea they've signed off. They frequently get messages from the tail end of a conversation much later, which is confusing for them. 2) The contact list is in alphabetical order, regardless of their presence. Talk used to separate online contacts from offline ones. This was nice because I have a lot of contacts in my gmail account, and only a dozen or so ever sign in to chat. There's no obvious way to change the sort in Hangouts. 3) The UI is higher latency. If I touch a notification in my tray, I often have to wait upwards of two seconds for the Hangouts app to load. The various screens within the app also take longer to load. 4) I used to have a custom notification set when I received a message. Hangouts replaced it with its own and there's no obvious way to change it back. I hadn't noticed Hangouts had abandoned XMPP. I find this rather unfortunate. Adium on my Mac still connects fine, but for how long?

deepblueocean 13y ago

I was always under the impression that the core Hangouts protocol _was_ the Wave protocol, in which case it's _already_ an open standard. What would be awfully nice is if Google (which is a category mistake - what I really mean is "the Hangouts team") would clarify this, release any updates to the protocol that they've made, and perhaps define something more than the weak API provided for the current Hangouts platform. In particular, the right test of openness is this: can I build an interoperable client that could participate in a Hangout as a first-class entity?

saraid216 13y ago
> I was always under the impression that the core Hangouts protocol _was_ the Wave protocol I've never heard this. Do you have anything that backs you up? I found a Quora answer that says that the Hangouts API is based on the the Wave API, but that's it.
josephg 13y ago
As a former google wave developer, I can only say that I hope this isn't the case. Wave's federation protocol embedded an XML-like data structure (wavelets) in protobufs (binary) which were then encoded using base64 and embedded in XMPP extensions (ie, more XML). That way lies madness.
- mh- 13y ago
  thank you for giving me a new 'something' to contrast some of our internal transport cruft. i can now, at least, think positively: 'well, at least it's not XML encapsulated in base64-encoded protobufs shipped over XML.'
- Camillo 13y ago
  How did Wave end up with that sort of mess? Isn't Google full of Very Smart People?
  - zanny 13y ago
    They do love their XML in Android layouts, though @.@
  - DannyBee 13y ago
    The internal architecture of wave was very abstract. a lot of this abstraction was exposed in the first federation spec, somewhat due to necessity, somewhat due to lack of time.
  - rachelbythebay 13y ago
    Here's a thought: what constitutes a very smart person? How often do those occur in the global population? Now, how many people are there on the planet and how big is the company? The Earth may not be big enough for that to work out. This is before you remove people who aren't in this industry, people who are too young or too old to work there, people who don't want to work there, people who DID work there and left, and so on. It might explain a lot, particularly when they go on a hiring bender. Where are all of these new people coming from?
drivebyacct2 13y ago
Where oh where oh where did you get that idea?

spankalee 13y ago

As another Googler, I mostly agree with you, but I also sympathize with the product and engineering teams. They keep seeing very popular apps and messaging products that are completely proprietary and locked in, and that are able to move and innovate fast because they either don't have to conform to an existing standard, or worry about publishing and support whatever internal protocol they do use. Sure Hangouts could publish their protocol like Wave did, but Wave was a complex mess of different protocol formats and transports and publishing that as a "standard" was way premature. Who knows how good the current Hangout protocols are, or how well they might play with real standards like WebRTC. It's probably too early for them I remain optimistic that these things can be standardized in the future.

cromwellian 13y ago
I agree with you, history is pretty much full of committee designed specs that failed, but full of defacto standards from commercially successful products that are later standardized. A lot of the features, like group video calling, first need their use cases polished by user trial, then hopefully, they can be implemented on top of either existing standards, provide inputs to change those standards to satisfy the requirements. OpenID/OAuth is an instructive example. The specs were built very much driven by committee oriented thinking, and the resulting UX implementations out of the gate were much more complicated than the Facebook Connect experience. I think actually focusing on the "design" aspect of how users use it, and then extracting the relevant technical requirements into a spec works better.
rjzzleep 13y ago
i'm sorry i fail to see the argument. it's perfectly fine to have your own proprietary format, but publish the specs so others can interact with it. who said anything about ietf having to sign it off.
- ChuckMcM 13y ago
  This is exactly right. It is a false choice to suggest that "open" means "slow". But that is fostered in part by folks who think "open" means "community driven." It is perfectly reasonable to publish the specs of what your doing with no commitment of support, simply for folks to see and possibly use at their own risk. That said, the reason companies don't do this is often one or two reasons. Reason one is that it results in a 'noisy' side channel as people who read the specs share their opinions, but they also get bent out of shape if something they said, or think they said, appears in the spec later. The other issue is that there is always a sanitization/prep process to take essentially internal information about a service and create an external representation for consumption (even if that consumption is unsupported). So the 'easy' choice is to not publish.

deleted 13y ago

[deleted]

saraid216 13y ago

I have to say I really do admire the way the EFF has taken to presuming that Google is a governmental body.

godgod 13y ago
The EFF is correct. Google is in lock step with the US governments plans of the complete erosion of our privacy rights. Google knows a lot about us all and the feds want that info.
- pekk 13y ago
  It isn't accurate to state that the US government "plans the complete erosion of our privacy rights".
  - cmiles74 13y ago
    It certainly seems as if it does. They repeatedly pursue strategies to gain access to private data and actively work against compromise or safeguards. If that is too strong, I think everyone has to agree that shoring up privacy rights is something they are clearly hindering.
- moultano 13y ago
  Poe's law.
kps 13y ago
Where does the article conflate Google with a governmental body?
- mwfunk 13y ago
  With the implicit assumption that there is any expectation or obligation for Google to conform to some level of openness, especially in (relatively) new products, as if it were paid for with taxpayer money and they owe us something in return. We can say that we wish it were more open, or that we won't use it because it isn't open, but I don't understand the attitude that they are committing some colossal ethical lapse or failing some social contract by not having it be more open at this stage.

zmanian 13y ago

It always seems to be my look Google is heading in the direction of a WebRTC based messaging service/client and then suddenly the product group veers off into another direction. WebRTC has been nearly here for several years now but it does seem to arrive...

graue 13y ago

> It's inevitable people will reverse engineer the client, as was done with MSN, Y! Messenger, and AOL. I hope you're right, but to my knowledge, this has never been done with Skype, and to this day you can only call a Skype-using friend/colleague if you use the official, closed-source Skype client. So let's not be sanguine.

fryguy 13y ago
or the closed-source plugin with an API (skypekit.exe)
- lsaferite 13y ago
  I was so hopeful they would release that at a library so all the open-source IM clients could link to it and get Skype integration. They indicated, years ago, that it was going to be released, but as far as I know, you can still only get it via a developer account.
josteink 13y ago
I hope you're right, but to my knowledge, this has never been done with Skype It was done, but Skype has a rule about this which they apply quickly: Press the cease and desist button. I've been using IM clients with support for skype, only to see it get dropped. Which makes it doubleplus sad that MSN (which was fairly interoptable) got ditched for Skype and not the other way around. The only "supported" way for third party IM clients to access Skype's network without risk of lawsuits is piggybacking on its COM API and have the user download and log into the official client, and have that handle all the actual communication. You probably think "He's gotta be kidding", but sadly I'm not. TLDR: Skype does not only not care for or provide an open-source implementation, but they are actively fighting it.

rogerbinns 13y ago

> ... necessitated by new technical demands As a bystander, this comes across as "we aren't smart enough to figure it out", or "we are smart enough, but this is a business decision with ulterior ("evil") motives". Neither of those look positive for Google. I don't expect multi-person video conferences to work, but plain old textual messages, as already work today, shouldn't be a problem.

aneth4 13y ago
Wanting to maintain a competitive advantage is not evil in and of itself. Google Hangouts is far from a monopoly and they are under no obligation to make every product completely open. Not only would it be competitively stupid, but it would also hinder product development to be so heavily tied to standards publication.
- rogerbinns 13y ago
  Google has a marketing approach of being different by not being "evil", being open & accessible, and having smart people work there. The steady drumbeat now is one of being no different than the other guys. Google held themselves up as taking the high road, which is why so many are calling them out on this (and why people don't call out other companies for the same antics). The issue isn't even about making hangouts open, but rather about chat messages in hangouts also being able to relay with federated XMPP servers - something GTalk does today just fine and has done so for many years.

pyre 13y ago

| It's inevitable people will reverse | engineer the client, as was done with MSN, | Y! Messenger, and AOL That's not the end-all be-all though. I remember that AOL was pretty aggressive about keeping unauthorized clients off of their Oscar protocol (the original protocol was 'toc,' IIRC and didn't support all of the 'advanced' features like Buddy Icons, idle times, etc). At one point, AOL's servers would require random chunks of the official AOL IM client's binary as a protection measure. Obviously you can get around this, but it's not something you can do out in the open (distributing AOL IM with, say, Pidgin/libpurple would be copyright infringement).

DannyBee 13y ago

Google Wave was not really done in the opposite way when it came to specs. The spec were largely written by an an intern and a person not part of the wave team helping wave with other things. Everyone else was focused on Wave.

groovy2shoes 13y ago

As an Android user, the new Hangouts app that replaced the Talk app feels like one step forward and four steps back (in terms of UX). The one step forward is that the chat windows look prettier. The four steps back, from most annoying to least annoying: 1) Chat windows give me no indication of the presence of the other participant(s) in a conversation. If they sign off, I have no idea they've signed off. They frequently get messages from the tail end of a conversation much later, which is confusing for them. 2) The contact list is in alphabetical order, regardless of their presence. Talk used to separate online contacts from offline ones. This was nice because I have a lot of contacts in my gmail account, and only a dozen or so ever sign in to chat. There's no obvious way to change the sort in Hangouts. 3) The UI is higher latency. If I touch a notification in my tray, I often have to wait upwards of two seconds for the Hangouts app to load. The various screens within the app also take longer to load. 4) I used to have a custom notification set when I received a message. Hangouts replaced it with its own and there's no obvious way to change it back. I hadn't noticed Hangouts had abandoned XMPP. I find this rather unfortunate. Adium on my Mac still connects fine, but for how long?