Slashdot Mirror
Google Talk Claims Openness, Lacks S2S Support
rm writes "This LiveJournal entry by Nugget quite well sums up the disappointment in Google Talk among many Jabber users, caused by the service's complete lack of XMPP server-to-server communication support: '...Google has uncharacteristically missed the real strength of the Jabber design. Despite all their self-congratulation about open communications they've only embraced the smaller, less important aspect of the Jabber openness.'"
the article starts with "This LiveJournal entry by Nugget..."
That is, after all, the point of open source, is it not?
Surely it's too early to be slating what they're doing with this technology. Don't you think they might be taking an incremental approach?
Then again, I *do* sound like another Google apologist, don't I?
caused by the service's complete lack of XMPP server-to-server communication support
I tried to explain to my 15-year-old niece how she shouldn't use Google Talk because of its lack of support for XMPP server-to-server communication. Then she discovered some new emoticons and stopped paying attention to me.
I'm a big tall mofo.
Remember this is still in a very early beta stage. On the developer page, they claim that they're moving toward interoperability with other networks and fully documenting the custom VOIP protocol they use.
They encourage people to comment in the Google
Talk Interoperability Google Group. It seems like they're trying to determine how to balance openness with security, privacy concerns (i.e., avoiding spam). I frankly don't know enough about Jabber, etc. to know if this is BS or not, but it sounds reasonable enough to me.
Their client may not run on Linux yet but you can use Google Talk on Linux using gAIM or another Jabber complient client: http://www.google.com/talk/otherclients.html
It has been out for a week or so, and we should cut them some slack as they work out the kinks and add new features. GMail lacked a number of things I wanted it to have when it first came out, but Google seems to be slowly adding them with time. Google seems too happy to call things beta for just about forever, but at this stage I think we all should consider it as a real beta and just wait and see
What do you know I wrote a novel
Thank you Slashdot editors, please continue to keep me informed of any breaking news stories from this "LiveJournal" news organization.
If only S2S was the only Jabber feature that Google "left out" when rolling out GTalk... but they also forgot to activate all these standard jabber features
"The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
Until I RTFA I didn't realise that inter-server communication was the really useful thing about Jabber. It looks like Google didn't either.
Leaders in the jabber community have made it fairly clear that s2s support just hasn't been coded yet. Its on its way.
Yes google did realize this. If Jabber wants to bein S2S with GTalk, they should e-mail federation@google.com. You could start your own jabber server and go S2S with Google. They fully support it and they know its strengths, they haven't implemented it yet because a) They have their own issues with just releasing a new service, b) they are treading carefully and looking for solutions to "spim", i.e. They are Google, they can't just open up their IM service to every "Joe" in town, it'd be akin to an open proxy for spam. They are doing this right, let them be. The last thing we need are bayesian filters for IM.
Regards,
Steve
Everyone come down out of their ivory towers and quit trumpeting how great they are for pointing out yet another reason why Google ain't the bees knees. Climb down out of your ivory towers and take a nice dose of reality.
Incremental improvements are a good thing - Starting w/ the absolute minimum feature set and building on it, all along making sure it works as advertised is a sound strategy. This approach allows you to continuously improve the software, and focus on addressing the issues that arise with the current feature set in a manageable way instead of having to address a mass of problems from all of the half-assed features you had to squeeze in because you had to have all of the bells, whistles, and even legit features. A frequent improvement/release cycle is a common practice for open source software products and Google is adopting a similar approach for its service.
You can't simulate this kind of load accurately - Sure you can run computer models of how the traffic load will behave and how the infrastructure will handle it, but you really don't know how it's going to work until you start putting some real user load on the system. By limiting the feature set, and in particular limiting inter-server communications you naturally limit the amount of load on the system. The users aren't going to switch completely from their current service to GTalk all in one day... so as traffic builds they can adjust the service settings, tweak the servers, do whatever to make sure they can continue to provide a quality service. And back to point #1... once you have a good understanding of the traffic patterns and capacity you can begin introducing new features that may change those patterns in a controlled way.
You can't predict how people will abuse the system - By limiting the feature set Google can better ensure that the system is not seriously abused by individuals who would want to use the system in a way that would annoy/harm the general user population or impact system performance. Connecting to other servers is a risky proposition that deserves careful attention and control to ensure that it works correctly. If Google make a misstep here and allows spammers to spam all of their users, and virii to spread across their system, and poorly managed Jabber servers to cause their messages to not reach their intended destinations you'll have a system that most people wouldn't want to trouble themselves with using. Google can start by controlling the environment while providing a base set of services... and then expand in a way that they can monitor and control to ensure that service is not impacted.
Get real feedback from real users - Instead of dreaming up a hundred things users probably want and squabbling over them internally, why not just release a base product that people will use and get direct feedback from them on what they want. This is what Google has setup... now they can ask their users do you want to jabber w/ other non-GTalk servers? Do you want more emoticons? What about real voice call capabilities? What about being able to search your conversations? What about... The point is let the users help direct the next round of development instead of spending a lot of time developing features for people who don't use the product.
Protect the service the customers want - The underlying principle behind all of this is that you have customers who want a service. The way to attract and keep those customers is by offering them a service they want and that works. Google has started by offering GTalk to a group of users. They'll hone the system, make sure it works, and if it meets their objectives and draws in customers they'll continue to expand on it's feature set in a way that keeps their customers from moving to some other service and continues to attract other customers... all the while being very careful not to make the service unstable or give something to their customers only to have to take it away (premature release of poorly test
> You can't really make any money in a decentralized system,
> which proves Google is still looking to captivate us because
> they have always been quite central.
Ah, but you can provide a for-profit service through a decentralised network.
Imagine this: Google runs their IM network on the open XMPP/Jabber standard, and builds SIP based VoIP into their client (they say on their dev page that SIP is coming). Both are open standards and as such will be integrated into many clients and Jabber server implementations.
Jabber supports gateways onto other IM networks, but that isn't the full extent of gateways. Google build a VoIP -> PSTN gateway (say voip.talk.google.com) that allows all these new clients with integrated SIP VoIP to dial out to the old PSTN network for a cost.
What a lot of people don't realise about Jabber is that you aren't limited to using the gateways on your own Jabber server, so if Google then throws open S2S connections on their Jabber server user@jabber.org can access the Google VoIP->PSTN gateway and dial his parents (provided he has signed up with Google VoIP and has enough credit in his account) phone.
Google has been buying up a lot of Dark Fibre lately and could seriously undercut their rivals. No more need for Skype or other such providers, and normal Jabber users can voice chat without going via Google due to the nice open VoIP standards implemented in all Jabber clients.
Well, from the FAQ on Google talk page you can read:
"4. What other communication services will you federate with?
We look forward to federating with any service provider who shares our belief in enabling user choice and open communications. We do believe, however, that it is important to balance openness with ensuring that we maintain a safe and reliable service that protects user privacy and blocks spam and other abuses."
They will be open, but in a slow way and only if your server can be trusted!