Google opens up Wave federation

Google took an important step on Monday in the development of Google Wave, opening its servers up to outsiders who want their own waves to communicate with the outside world.

Wave servers belonging to Acme and Initech can now talk to each other with the opening of Google Wave federation.

(Credit: Google)

A "wave" is a stream of messages that blends traditional e-mail, instant messaging, file sharing, and workplace collaboration tools. There have been plenty of supporters and detractors of Google Wave, Google's bid to reinvent e-mail as a combination of such services. But Google's implementation of Wave is going to be only one part of the story: outside developers will have the opportunity to build their own wavelike services using the Google Wave API set.

And those outside implementations will be able to communicate with each other using the Google Wave Federation Protocol, now that Google has opened up federation of wave servers. This means that if Company A built its own wave servers, it could interact with Company B's wave servers through a public peer-to-peer network facilitated by Google.

At the moment, this is just confined to the developer preview sandbox that was the initial proving ground for Wave. Since its launch, Google has opened up Wave to a wider audience for further testing and bug squashing, with a formal launch not scheduled until early next year.

Wave's complicated interface has not been a resounding hit with early testers, but the combination of external development and a federation service means that others could create more compelling ways to use the technology.

[thefinite]

There's one more step beyond federation that will be sure to get people using Wave, and that's an extension that allows waves and standard email protocols to interact.<br /><br />For example, if the extension wrapped the current version of a wave into an email, highlighting the newest blips, and sent the email out, then a standard email user could read and respond. The same extension could then receive replies and apply responses into the wave.<br /><br />It still wouldn't work as well as it would if all parties were using wave protocols, but it would allow wave users to ditch email all together. The email users would recognize in the interaction that waves work better.<br /><br />All that said, I think Google should have used a slightly different convention for wave addresses (not [e-mail]) so people could visually distinguish wave addresses from email addresses.

[sadiq815]

Maybe require that the server use server.wave instead of server.com. A new TLD wouldn't be a problem would it?

[Hunnter2k3]

&gt;All that said, I think Google should have used a slightly different convention for wave addresses (not [e-mail]) so people could visually distinguish wave addresses from email addresses.<br /><br />But why try to fix that which does not need (much) fixing?<br />DNS is pretty fine at the moment, no need to add any fancy new stuff to it when the system is already there.<br /><br />You already have an "address" of sorts, [e-mail]<br />An e-mail interface would be pretty trivial to create.<br />Gmail already partially works like Google Wave, in the sense of grouping connected e-mails like conversations.

[molotov]

Forget Google Wave, when will I finally get my Google Voice invitation?!

[TWDarkflame]

"and that's an extension that allows waves and standard email protocols to interact."<br /><br />Having a standard client server protocol would be a more logical first step.<br />Currently its a little like email without IMAP/POP3. <br /><br />Wave has applications far beyond inbrowser text-based clients, yet its a little hard to realize without c/s standards. (currently google uses their own protobuffer system).