- 71comments
- 158comments
- 24comments
- 211comments
- 54comments
- 10comments
- 40comments
- 232comments
- 70comments
- 234comments
- 3comments
- 5comments
- 13comments
- 49comments
- 27comments
- —discuss
- 157comments
- 14comments
- 18comments
- 55comments
- 172comments
- 132comments
- 87comments
- 9comments
- —discuss
- 257comments
- 25comments
- 118comments
- 15comments
- 16comments
You are the administrator for one or more Google App Engine applications that may be impacted by an upcoming new product release. Google will be releasing a new communications product called Hangouts which users may choose to use instead of Google Talk. The new service does not support XMPP.
As a result XMPP bots such as the App Engine XMPP service will not be able to communicate with users who adopt the new service. There are two ways to keep your App Engine XMPP service working for end users:
1) Your users may use any chat client that supports XMPP. XMPP clients will continue to work as usual with the App Engine XMPP service.
2) End users will be asked to opt-into the new service when it goes live. Note that the go-live date may vary for Google Apps domains. End users and google app domain administrators may choose not to opt into the new system. If they do not opt in they will remain on the current Talk client and there will be no change to their existing functionality, including being able to exchange messages with App Engine XMPP bots. Users who already opted in may toggle back to the old XMPP based chat clients in Gmail.
Note that the changes discussed above have no impact on non-Google XMPP clients, which will continue to work as usual with the App Engine XMPP service.
If you have any questions, comments, or concerns, please don't hesitate to email us at app-engine-xmpp-questions@googlegroups.com.
Sincerely,
The Google App Engine Team
© 2013 Google Inc. 1600 Amphitheatre Parkway, Mountain View, CA 94043
You have received this mandatory email service announcement to update you about important changes to Google Cloud Platform or your account.
Yep, I already warned about this a few days ago. I would like to encourage everyone to avoid using this walled garden service and make sure you tell both your friends and Google why. Say NO to proprietary network protocols!
So, what do you propose as a realistic alternative?
Personally I'd love to see a community driven extension to XMPP, with its corresponding RFC, which would allow feature parity with Google's proprietary crap while keeping interoperability and federation, so people could give Google the finger on this one.
I've long dreamed of a resurgence in the open source community, attacking big media much as the community attacked Microsoft in the late 1990s. It's depressing that the PR machine has so thoroughly succeeded that most of those who still call themselves "geeks" now consider building throwaway hacks on big media services cooler and more meaningful than coordinated efforts to replace the services themselves (in the name of serving some ideals much greater than say, amateur entrepreneurialism).
Talking here about Docs, Gmail and so on. Somehow it became embarrassing for a nerd to straight out clone the competition, much like AbiWord and suchlike once did, simply in the name of freedom. Nowadays we have to compete on "sexy" innovative site designs and related sundry crap, and how many cloud "services" we integrate with.
I'll keep hoping for this resurgence, in the meantime I'll continue privately working toward cloning some of these services myself, until such a time as there is an established community for me to join. We basically need something like the (early day) GNOME foundation, but for the web.
Free-as-in-freedom replacements for many services do exist. By and large nobody knows about them, perhaps because the community isn't unified on the issue like it was against Microsoft, as you point out. I'm not sure privately working toward cloning services is a good way out of this situation. :)
autonomo.us is one mostly silent place to talk about it.
You may be right that there needs to be a (I think you might mean GNU project, not GNOME foundation?), but for the web. My guess as to why there hasn't been one is that the task is far messier, and there are a lot more choices about implementation. The usual thought following this is that free services need to federate rather than be part of the same project. But this thought could be wrong.
Thanks for the link, will check it out. GNOME was the first environment I used that had cohesive e.g. system preferences across the environment, and later a consistent update process (if I remember it right, Ximian were the first to include an updater in GNOME).
Half the battle isn't producing the software, it's ticking all the boxes that make people "go cloud" in the first place – you never need to run software update for Google Docs, you simply don't need to care about it.
What I'd love to see is a Ximian-styled system where you could subscribe to some release cycle (bleeding edge, 6 months behind, long term support), and behind the scenes a vast team of idealist monkeys worked to provide some of that cloud comfort – at the very lest, security updates.
The concept can be extended to quite elaborate proportions. But the low hanging fruit - let an admin create user accounts, let users login painlessly, and figure out how to make updates work safely & painlessly - and I believe half the war would already be won.
As others have noted, the pieces are already (mostly) there, they just need to be put together properly. FreedomBox is one effort in this direction, and they've already got an eye on XMPP, at least for chat. I don't know about extending it, but that is where I would start. IIRC, XMPP was created in response to the last time chat was balkanized; remember ICQ, AIM, MSN, etc, etc, etc?
One solution is to use Google Docs and more, but to only store encrypted data there. This gets you the convenience of SaaS without the privacy issues (see http://rdist.root.org/2011/05/09/encrypted-google-docs-done-...).
Priv.ly has an interesting approach to this somewhat analogous to the above: http://www.kickstarter.com/projects/229630898/protect-your-c...
Tent is a protocol for distributed social networking that I'm very optimistic about. You can message me at https://elimisteve.tent.is (sign up at tent.is).
jitsi.org
http://www.jabber.org/ maybe?
Or run your own xmpp service, if you are a business/company. I personally use prosody. Works great.
I think that's the entire issue. Those of us with our own xmpp servers can no longer talk to hangouts because we have to have an account with google. s2s is going away, and I really am not interested in creating yet another account on some external system so I can chat with everyone on the non-federated system.
"both your friends"..I think I might have more than 2 friends :)
They mean both Google and your friends. :p
So now Facebook chat, which partially supports XMPP, is the most open of the widely used IM networks. There's a thing.
Hangouts supports xmpp clients (but not federation), so it's similar to facebook afaik.
No, if you have a client connecting to Google's XMPP servers, your messages will not show up if the other user is only logged in on Hangouts. Hangouts ALSO can't send messages to an XMPP only user (even if Google is hosting the talk servers, as is the case for my Google Apps domains).
Did you try it? (that doesn't match what other people have explained to me)
Yes, I did try it.
Larry Page seemed very upset [1] that Microsoft is basically leeching off their Gtalk contacts into Outlook, without returning the favor (with Skype I assume), and he said he'd prefer if things weren't like this and everyone was more open.
He didn't continue that idea, but I think he would've continued it with "...but since nobody wants to do that, then we won't do it anymore either". So they are probably responding in the same way they responded to the leeching of Gmail contacts by Facebook a few years ago, by blocking that API, or in this case replacing the XMPP protocol with a proprietary one. It's too bad it had to come to this, though.
[1] - http://www.theverge.com/2013/5/15/4334242/larry-page-to-tech...
Gtalk will still be available though.
"... which users may choose to use instead of Google Talk."
I don't think it's reasonable to expect Google Talk to remain indefinitely though - if you need XMPP you at least want an exit strategy if Hangouts isn't suitable. It's quite telling that the Hangouts app on Android is called "Hangouts (replaces Talk)" and takes Talk's URL in the play store.
In GTalk's case any XMPP client will do so an official app is almost irrelevant in its case.
Right, but you still need Google's XMPP server to support it.
It's still there.
For now.
Despite the clear warning signs, I am willing to put money on people whinging in a year or two when they shut down those servers, just like everyone got all upset about Reader.
"may" my ass. Google forced the Google+ extension on me faster than Steve Jobs used to declare that white was the new black.
Until it gets killed, in 2 years from now. Or less.
don't expect that to last too long. the google talk android app updates to become hangouts, and the chrome extension became hangouts automatically today.
Will GTalk be able to communicate to users of Hangouts, though, or will everyone be forced over to Hangouts in order to continue to speak to the people who move over? I'm guessing the latter.
Yes, for now they're basically the same service. I'd imagine that this will change as Hangouts diverges more and more from what Talk supports, to the point where Talk will be killed due to disuse.
Google is "open" unless everyone else isn't, in which case, forget about it?
Google is "open" unless they have the big stick, then they're not.
Seriously! The real question is why Google isn't sending Microsoft direct donations. They're so uncharitable.
That's rich when just today Google sent a C&D to Microsoft to take down the Youtube Windows Phone 8 app and refuse to make one themselves.
"Google demands Microsoft removes YouTube Windows Phone app, cites lack of ads "
https://news.ycombinator.com/item?id=5714520
That was after they started serving a degraded experience to Windows Phone on Google Maps, and restored access after people complained and called their bluff that it didn't support needed features.
http://arstechnica.com/gadgets/2013/01/google-maps-windows-p...
Then they dropped support for ActiveSync from Gmail and Calendar so Microsoft had to scramble to add CalDAV support.
http://www.theverge.com/2013/1/21/3832838/windows-phone-card...
And then comes a second round of Spring Cleaning, which deprecates CalDAV support and moves to the Google Calendar API!
http://www.sparsebundle.net/posts/google-deprecating-caldav-...
Edit: Predictably, that post about Google asking for a takedown on the WP Youtube App is getting flagged.
http://i.imgur.com/4MBcGom.png
Just like the Windows 8.1 Blue being free post yesterday.
https://news.ycombinator.com/item?id=5707805
Google can do no wrong on HN, whereas everything Microsoft does is wrong.
That app shows Youtube videos without ads. That seems like a clear violation of Youtube's TOS and I don't blame Google for being upset about it. Edit: I woulnd't flag the story though.
Is there a YouTube API that provides the ads, or is Microsoft's only alternative to embed a YouTube web page?
The issue is that Google has refusing to give Microsoft access to the Youtube API for close to three years
See my comment in the other post.
https://news.ycombinator.com/item?id=5714520
The AppleTV YT app doesn't show ads either.
Google negotiated a contract with Apple in that instance. This is the way the old iOS app worked too - Apple licensed the API in exchange for them building it.
The main issue is that partners that use revenue sharing couldn't restrict their videos from playing on WP devices that wouldn't generate ad revenue. Normally, you can block devices from having content if revenue sharing is unavailable, something Microsoft circumvented.
So, for years, Google's stated reason for lack of a Youtube client was that Windows Phone didn't have enough marketshare, and now suddenly it has so many users that it loses so many ad impressions because Microsoft's Youtube that the content creators are suffering because all the millions of freeloaders using Windows Phone?
i.e It doesn't care enough for the ad impressions on Windows Phone to itself make an app , but when MS does, the loss of the same revenue is the reason for sending the lawyers in and pulling the app?
Google's "lack of marketshare" reason seems to be a bit lacking to me. Windows 8 sold 100 million and they still don't make any apps for it.
In contrast, Yahoo Mail which is barely making any money by manages to make a nice one.
http://apps.microsoft.com/windows/en-us/app/yahoo-mail/f90f3...
And Vimeo has apps for both WP and Win8.
http://www.windowsphone.com/en-us/store/app/vimeo/ff8dadc8-8...
http://apps.microsoft.com/windows/en-us/app/vimeo/6608d199-0...
They make a Windows 8 app which provides access to all of their services (with ads): Chrome.
I'm pretty sure Google makes a ton of apps that work just fine on Windows 8, a user has but to open their browser to access them.
I think it has more to do with not having access to the API to display those ads. I have strayed from Google ever since I got a windows phone. Found decent replacements for most of their services, however Youtube is one thing that has and may never have a real replacement!
Had it been a Google startup, it may not have bothered me so much. I was using it way before Google brought it and now I am punished with a second class service for my choice of phone? That is just sad. :(
Just hope the same won't follow when Ubuntu and Firefox launch their phones.
Apparently it also has a button to download videos from YouTube. Google's been C&Ding anyone that does that for years.
I wonder how Google would react if the websites that fuel it's search database started having TOS terms for search engines like "In your search results, you must also display the advertisements on the pages that you scrape".
A few sites doing that wouldn't have any effect. Google would probably just remove them. How many websites it would take for Google to actually pay attention though? 20%? 30%? 50%?
That wouldn't work. Search and display snippets of search results have been ruled as fair use in multiple cases for their transformative value. You wouldn't have a copyright claim and robots.txt has been upheld as an industry standard/easily implementable escape hatch to make it known that the crawler should not index the specified sites/pages.
You could certainly say, "I'll keep you blocked in robots.txt (or block by IP or whatever) until you show my ads", but you are unlikely to succeed in that, and then there are still the downsides of not being listed in search results to consider.
The point of a search engine is to drive traffic to the pages that contain advertisements. MS was putting "eye's" on the content without the ads.
I'm not sure how these compare. The XMPP case and demanding the youtube app are two examples of Microsoft taking from Google but not wanting to return anything. In the case of Youtube, they're taking bandwidth but not giving back ad revenue, which is legitimate.
While I don't think that every action you list is necessarily Google trying to screw over Microsoft (dropping support for common protocols hurts everyone, not just Microsoft), I also can't deny there's some obvious bad blood between them. It doesn't help that Google has a fair number of ex-microsoft employees, and they have A LOT of products in competition with each other (google vs bing, gdocs vs office, android vs wp, chrome vs IE, etc etc etc)
And the fact that HN would have a slight bias towards Google should not be a surprise, as Microsoft veers more towards the business side of software while Google veers more towards the open source, free stuff, etc etc. Which do you think people would honestly be more supportive of?
Given Microsoft's track record, for, oh, I don't know, their entire existence, it's no surprise they're not well-liked. Whereas Google just hasn't had nearly three decades to be evil; give them time.
Drop of activesync meant google don't have to pay a license fee. But your right, the world revolves around you.
They dropped caldav too.
Google have not dropped support for CalDAV. It's still available, you just have to fill out a form first.
As a user, I am upset that it is getting harder to communicate with people. Everyone has their own non-interoperable (but cross platform!) protocols/networks/gardens now.
As a user, am I supposed to have an account with one of each of these things? Have nine different apps open all the time? This is as bad as icq/messenger/aim/etc was back in the day. sheesh.
It's very simple: no XMPP? Then I'm not IM'ing with you. No SMTP? Then I'm not emailing with you. I might be the exception, but I don't care. I encourage others to do the same, and don't support in any way, shape, or form companies that keep doing these things. Someone comes to you with a problem caused by this BS (or just a problem with, say, the offender's platform in general), refuse to support them. Tell them to talk to their vendor.
I wish it were that easy. The problem with that is it at the end of the day, you're the only one at a disadvantage. The vendor doesn't need you and doesn't care. If your casual contacts and non-technical friends find communicating with you to be uncomfortable, they'll just move on without you.
And that sucks, and I don't like it, but I'm still not giving in. To be honest, I have a hard enough time keeping up with people I know IRL (which thankfully doesn't have these problems), and I can't see any of them cutting me off because I won't "upgrade" (they haven't yet).
This is a very good point. I think a lot of people tend to greatly overestimate the degree to which technology has the keys to their social life.
I'd love to live in this world with you. Literally, I think one friend I know, even of techie friends of friends that work in tech (msft, etc), would know what I meant if I said that without having to think for [too long].
It's why I'm so upset that a large network that had the potential to include a huge amount of people and volume AND LEVERAGE XMPP just spat in our faces.
I agree. I have only XMPP contacts for IM, and simply don't use any others.
Slight nitpick, Apple's iMessage (edit:) and BlackBerry's BBM) aren't _really_ cross platform (unless you consider OS X to iOS cross platform). It isn't really useful beyond Apple's walled garden.
Is BlackBerry's BBM available to other platforms?
Not yet, but it is slated to come to Android and iOS in the near term.
http://mashable.com/2013/05/14/bbm-ios-android/
Until then your nitpick should also include that as another walled garden ...
If you don't support Desktop you are not cross platform
This is why I am long on SMS.
iMessage is transparent, so that doesn't bother me. I have three [edit: four] solutions: GTalk, Email, Text, and Facebook. Except GTalk, they're all passive (i.e. I get messages from them on my phone without the app being open). Now that hangouts are available, it's 100% passive. This doesn't seem like that bad of an outcome to me.
That's 4. The old "off by one" error.
Well, I am a software engineer, so it's traditional. :P
I need a client for Ubuntu then :(
Chrome app: https://chrome.google.com/webstore/detail/hangouts/nckgahada...
That extension is essentially broken (running iceWM), as the text input box dips below the taskbar. Furthermore, it requires chrome to be open. I don't necessarily want to keep my browser open at all times, nor do I care to use my browser as a chat client. (Also, what happens if switch to some non-standard browser? There is no way that my choice of browser should impact my ability to chat.)
I'm trying to stay open-minded, but so far I really dislike this product. I hope gtalk stays open.
You can always open a Gmail tab.
I think the Chrome app is an excellent cross platform solution (written once, easily maintainable). As for the protocol I don't think it is practical or even possible to built this sort of all encompassing communications platform on top of XMPP (see the competition).
I do hope there will be a Hangouts API.
I think the chrome app is one aspect of a cross-platform solution. But what if I'd like to chat without opening chrome?
I'll cross my fingers for a Hangouts API that allows me to write a standalone client. However, if chatting through a semi-broken browser extension (or memory intensive gmail tab) are my only options, then I guess the service isn't for me. I think the reason I'm annoyed is that I have a lot of important contacts on gtalk, so migrating away will be a challenge.
I know change is inevitable, that the service is free, and that they want to offer a better product. Perhaps my use cases are just too expensive to support in the long run.
Just to clarify: If you think you need a client because you are currently using an XMPP client with your gmail account, then you do NOT need to switch. See bullet point 1 — XMPP _clients_ are still supported.
XMPP _federation_ is going away :(.
Google enthusiastically kills legacy and niche products. I'm making wild guesses, but I don't think we'll have support for XMPP clients in the long run.
They're saying XMPP clients still works with the App Engine XMPP service (which is "An App Engine application can send and receive chat messages to and from any XMPP-compatible chat messaging service, such as Google Talk"). The email says that Google's new service no longer support XMPP.
I wonder how long google talk will last in Outlook.com
Serious question: how practical is it to build something like Hangouts that is meant to compete with iMessage, WhatsApp, Viber etc on top of XMPP? is it even possible?
Sure. Much of the Google Talk video stuff was all designed for XMPP; they actively took part in the standardization at times.
WhatsApp is XMPP, fundamentally, in any case.
Why is it not utilized more widely then? foregoing for a minute that everyone is cultivating their own gardens - what are the weaknesses of XMPP that would make it so easily avoidable for most of these apps?
It's definitely not the lack of features, since XMPP is extendable. I've heard that the protocol is quite chatty and would cause power drain on phones. That could probably be solved with a binary serialization alternative to XML, though.
Is XMPP asynchronous?
Yes, it is. The very start of a session is usually synchronous (authentication, etc), but after that it is async. Request/response commands have an id value to link the request to the response so it doesn't matter if other data arrives first.
Yeah, there's http://xmpp.org/extensions/xep-0286.html which discusses some ways to mitigate the power issue, but, from what I understand, we never got much feedback from mobile developers about it. In particular there are several extensions which remove the need for a lot of network traffic (capability hashes, roster versioning, stream management to immediately resume a session that got disconnected, etc). The fun part is that 1) a lot of mobile client developers haven't implemented those and 2) most require server support, and Google never added support for them.
As for a binary serialization, XMPP traffic does compress very well already (TLS/zlib/lzw), but we have started the process on standardizing the use of EXI (https://en.wikipedia.org/wiki/Efficient_XML_Interchange).
While the use of XML in the protocol might be considered verbose, stream-level compression from TLS quite makes up for that. With many contacts, the number of presence stanzas might indeed drain the battery because the antenna will be 'up' quite a bit.
However, the XMPP community has been active in quantifying such issues and providing solutions. The beginning of a document with background information is available as http://xmpp.org/extensions/xep-0286.html. There are also various opinions on the topic to be found online, like http://www.deepdarc.com/2008/02/14/mobile-xmpp/, that, as you can see, dates back half a decade already.
The only thing Google actually did fro mobile XMPP was google:queue, which bunches together presence updates such that the antenna efficiency is improved dramatically.
Facebook also have a private extension, as I understand things.
I should actually submit that extension - I wrote it up as a XEP ages back, but various things have held it up.
There are no weaknesses in XMPP. The issue are the protocols on the side, the ones that do video and voice. XMPP allows to chat and create a voice/video session, but:
1) the free protocols to do voice and video are not as good as the proprietary ones
2) it seems that every client use a different set of protocols for video and chat
Except there is no way to interface with it on the desktop level.
Yes there is. The maemo/meego community reverse engineered it and created a proof-of-concept java app, and a totally working meego app for the N9. Check their forum for protocol info, etc, but there's clearly enough to create a desktop app (you'll still need a phone to create the account though).
This seemed inevitable. This interface and backend is so inextricably tied to Google+ and Google's new infrastructure. I'm very disappointed. Google's services work well for me, they're well integrated, I love Android, but Android is no longer the bastion of freedom and openness I'd hoped for.
I'll be very happy with Google Hangouts but I'm still waiting for the properly federated chat that appeals to the masses.
Well, the XMPP still works and is decentralized. Is also the biggest network. If that is not enough for you then I'm afraid you won't find any other alternative.
You can set up your own XMPP server or use one of tons of the public ones: http://xmpp.net/
Edit: There's also jabber.org http://www.jabber.org/ which probably will operate as long as XMPP is still relevant.
Yeah, I (and tons of people, apparently) misunderstood the changes to XMPP. They are removing the federation however and that does affect interop with their network.
Well done everyone.
Instant Messaging is now dead for me because all the people I used to chat with are now fragmented across 4 or 5 different services. Aside from those who gave up on IM for the same reason I now have to.
You've all literally killed IM. Well done.
XMPP/Jabber has the concept of Transports to address this very problem.
Sure, you usually get a common denominator of features between the various networks, but presence and chat usually is enough.
You mean the transports that spams my buddy list with tons of inactive contacts and duplicates?
No dude. I'll just create one more alternative and amass a user based and then ??? and then profit! But I'll have an iOS app and an Android app, so that should cut it right? Fuck feature-phone users, Symbian/BBM/etc. Don't have a browser/desktop app.
Whatever. Google Voice is a dying product, and I hate them for what they've done, but at least the underlying transport is SMS and a portable phone number -- if I want I can host it myself in Plivo, which I plan on doing soon.
Windows 8 and the windows phone 8 messaging apps bring a bunch of these together very nicely. My usage of IM (which includes SMS and facebook messaging) has gone up significantly ever since I switched.
Ironically, after all this new fragmentation, a few friends and I have decided to move back to IRC. It has all the features we need, we know how to use it, it's not going anywhere, and it's not gonna start changing privacy settings on us.
I run two user accounts in Chrome during the day: One connected to my personal use the other to Google Apps for Business. I use Chat for Google for both (Adium sucks)
About an hour ago, the personal account had a changed icon, started looking nicer, and is now called Hangouts. The Apps for business one stayed the same.
I've never been closer to being a fanboi than I was with Google, but this seals it...I'm pissed. Closing off (yet another) service in favor of proprietary protocols is not something a "Don't Be Evil" company does...in fact it's why you have the motto in the first fucking place.
You could have made the change without breaking XMPP. This is just shitty all the way around.
You're wrong on almost every point. "Don't Be Evil" is not Google's motto, XMPP chat still works fine for my hangouts account and no, they couldn't do it without breaking the XMPP.
I just hope they'll keep XMPP running for the chat. I'll stop using it the second it'll stop working in bitlbee.
Are messages from your XMPP client going to users of the Hangouts app and vice-versa, though? The e-mail implies that users of Hangouts can still continue to use XMPP clients, but that they're connecting to a totally seperate XMPP-compatible chat system by doing so.
Why not? XMPP is pretty extensible, and Google's Jingle spec was open. Is there a technical reason that Hangouts had to be based on something other than Jabber?
Ahem. This[1] is close enough to a motto to make this part of your comment irrelevant.
[1]: http://en.wikipedia.org/wiki/Don%27t_be_evil
Whether or not "Don't be evil" is their motto, it's clear that they've failed to manage expectations.
Yay, the balkanization of chat. So much for babel/babble. Now you have iMessage, WhatsApp, Viber, Skype, Hangouts, etc. etc.
The biggies will be the ones supported by large companies (ie, Skype, iMessage, Hangouts).
So when will Amazon buy Viber or another smaller chat community?.
So... we're back to the 90s? AIM and ICQ and YIM and MSN? I CAN'T WAIT.
Sadly, it means the same tech as in the 90s will win out, because it is TRULY platform independent.
SMS. And as much as I hate to say it, iMessage has the best support/transparency for it so far
I think that, at this point, the only Google service that still supports standard, interoperable APIs anymore is Gmail. All the other ones have been discontinued or are in the process of being discontinued. I wonder how long it'll be before Gmail gets closed off.
Something interesting is going on here. If you log in to Plus, you can use New Hangouts _right now_. And they _do_ interoperate with XMPP users _right now_ -- I just tried it.
So does this mean the rollout is not complete, and what they rolled out as Hangouts today is not what they'll ultimately roll out? Or does it mean -- as I suspect -- that New Hangouts is XMPP under the hood, but they plan to flip the 'interoperate' switch to 'off' once they think nobody will notice?
No, what it means is that 3rd party clients can still interoperate with Hangouts. What does not work is XMPP the way app engine uses it.
Are you sure? From my reading, it's saying the exact opposite - XMPP clients still connect to a seperate XMPP chat service that's compatible with the App Engine XMPP support and completely seperate from Hangouts. The Verge also had a chat with the head of that department and he said that Hangouts drops XMPP support, apparently with no caveats about it still partially supporting XMPP: http://www.theverge.com/2013/5/15/4318830/inside-hangouts-go...
I have heard from somebody else that using XMPP on Hangouts on Plus works. It doesn’t work for me. When I enter an XMPP address, all I get is “send invitation”, but nothing happens when I chose to do that. When sending a message from my XMPP client, it does not show up in Hangouts on Plus.
When someone sends me a message over XMPP I don't get it in my G+ Hangouts as a received message, and sending a message to an XMPP address in Hangouts asks to send an invite and does nothing.
Hangouts CAN NOT communicate with XMPP clients.
Ugh, and to think that the only thing needed to prevent this was one other "big" IM provider using XMPP. If we didn't have to rely on a single point for everything, and were, instead, more distributed, like email, then Google would have found it much harder to cut federation off.
"Google Talk [..] was based on an old standard that predated the advent of cloud computing" - what an extremely poor justification... He is not even trying to sound credible !
woah :(
Oh, how I wish I was a Facebook employee today. Nothing like a good fight when you have the upper hand and the other party is being a jerk.
I'm amazed at people complaining about the fragmentation of IM clients and how it's going to kill instant messaging.
IM has never been unified. In the mid-90s you had the war between AIM and ICQ, then came along the IM clients from MSN, Yahoo and Excite. That's what led to the rise of multi-protocol IM clients like Gaim, Jabber and IMVU and out of that rose XMPP (one of 5 major "cross-compatibilty" IM standards).
Then you had a new generation of IM wars as desktop clients died out and were replaced by browser chat like GTalk and Facebook Messenger. As the desktop IM clients died, Skype pretty much absorbed their desktop users into their voice chat platform.
But now web IM clients are being wiped out by a new generation of mobile IM apps like WhatsApp, Vibber, etc.
IM has never been unified, and given it's track record, I doubt that's going to change anytime soon.
XMPP is standardized and works, right now.
Gtalk and Facebook messenger both used XMPP. XMPP is federated so it allowed many people to easily communicate. Even MSN messenger got on board:
http://msdn.microsoft.com/en-us/library/live/hh826554.aspx
AIM also has limited XMPP support (although that is just from a quick Google search, can't figure out if that is still the case).
Either way more and more clients and chat protocols were beginning to converge onto a single standard, that allowed people to easily communicate across different "domains". That is now going away.
MSN is dead, Microsoft migrated users over to Skype.
Microsoft Lync has an XMPP gateway role as well. Unfortunately, Lync Online (Office 365) lacks this ability.
Am I the only one that's thinking that "backend" for this is actually whats left of google wave?
Considering that XMPP federation has been turned off for some time now, this really only hurts users using XMPP clients.
I was wondering why my friends with non-Google Jabber IDs were never showing up as online, and one day figured out federation was turned off.
This is as if a few months ago your email provider silently discarded emails to and from other domains, and just today abandoned SMTP and IMAP.
The true failure happened way back when federation was abandoned, not today.
Federation was turned off temporarily to fix an exploit then turned back on. I guess it's moot now.
Right - there was a lot of noise about federation being turned off, although it never was.
1) Subscription requests to/from other domains were blocked.
2) Only for a short period (about a month, tops).
This is incredibly confusing. The sentences seem to alternate, between "Your end users will be affected, you must do something" and "Your end users will not be affected". Some of the sentences seem to imply this is isolated to AppEngine ("Your users may use any chat client that supports XMPP","the changes discussed above have no impact on non-Google XMPP clients") and others seem to imply that Hangouts is going to completely stop working with XMPP, if not now, very soon.
Can anyone clarify if this actually impacts your average standalone XMPP client, not connected with AppEngine, sending and receiving messages to Google Talk users?
Standard XMPP clients still work. If you use Pidgin or Adium or other similar clients, you can still send and receive messages to Google users regardless of whether they're using Hangouts.
If you have an App Engine instance, and it uses the App Engine XMPP Service[1] to send messages to people, then that will stop working for users who switch to Hangouts.
[1] https://developers.google.com/appengine/articles/using_xmpp
Thanks - that would seem to make the title of this submission to HN quite misleading (even if it is extracted directly from text of the source).
Thanks, this clarified things a lot.
With Google focussing on G+ like crazies(even though I don't know many people who use this service) and seeing Hangout is almost fused in G+, this very much looks like a Google Reader waiting to happen for Google Talk.
So,
1) Competitors use Google's APIs based on open standards for their own advantage.
2) Google gets annoyed.
3) Google stops supporting open standards.
Well, that's my honeymoon with Google over.
It seems a naive mistake to have assume an enlarging Google would stay true to their roots.
It's time for those roots to move. Onwards and upwards.
I'm reminded of the story about an angry RMS accosting some devs saying they should be creating their own open APIs rather than using X company's closed API.
It turns out Open Source's weird uncle was right again.
They're still supporting client-to-server XMPP, so third party apps can always just connect as a client rather than doing federation.