Thursday, May 28, 2009

A Technical Look at Google Wave

When I visited Stephanie and Douwe in Sydney last year, they would not tell me what they were working on, to the point of paranoia. When visiting Google's Sydney office, Stephanie made sure I couldn't see any of the screens. I eventually came up with the hypothesis that they were going to replace one of Google's central products - one of Google Search, Apps, or Gmail. Turns out, I wasn't far from reality: Google Wave seems to want to unite the last two.

This is a grand and ambitious plan. From a quick look at the Draft Protocol, here's the rough game plan:
  1. the traditional MIME-based email structure is replaced by wavelets (an atomic message, with multiple documents inside) and operations (a change delta between versions of a message).

  2. SMTP is replaced with XMPP.

  3. IMAP is replaced with "Request elements" against the Google Wave server.

Is this better than the MIME + SMTP + IMAP? I think so.

Here are some big open questions that I'd like to know an answer to:
  1. What's the migration path to Google Wave? This is clearly aimed at replacing email as your main tool. If I'm currently using Exchange or Google Apps for my domain, is there going to be an easy way to switch over to Google Wave?

  2. Authentication across servers: Can any server publish to any other server? How can a client or a server access waves on another server and restrict access to validated users?

  3. Could this architecture worsen the spam problem: Can't spammers just publish a bunch of waves to another server? I'm not familiar enough with XMPP to answer this.

Lastly, I'm very happy that with reMail, I'm not stepping on Stephanie's and Douwe's toes, but working on the orthogonal problems of better priorization, better search, and better views of your email data. Good.


Update: As for my points about spam and authentication: In IM-like fashion, users need to be added and removed from a wave by someone already a part of the wave (see the addparticipant / removeparticipant calls in the spec). Thus, spammers won't be able to spam existing waves. I'm still not sure who can initiate waves and invite participants - anyone from any server? Or is there some spam protection mechanism I'm missing?

Update 2: Maybe a better way to look at this is taking email, which people have been abusing as document transmission + versioning + IM, and rolling those features into the core protocol. Instead of messages, we create a document and send around deltas of it. Just like SVN, but with better views and features.

Update 3: I need to look through my inbox and figure out what % of conversations and use cases this would solve for me. A lot of my email is external notificiations ("someone sent you a Facebook message"), which Google Wave wouldn't improve. Google Wave's use case is clearly collaborative work and decision making.

Update 4: I just had a Scary Thought. Maybe the masterplan isn't to migrate everyone over from email, but to create a parallel world of Google Wave. Ugh. Another inbox to check, in addition to email + RSS + twitter + Facebook + bug tracker + Hacker News.

Update 5: Just saw this comment on HN. A pretty good summary, if a bit too negative.


pheelmore said...

I think you could use features like folders in RSS readers to create a hirarchy based on importance. I think this is a great combination of different technologies resulting in something like a unified inbox for everything. If that is then sorted by a technology like yours, it would be pretty much perfect.

Jared Hanson said...

If Wave gains traction, it may well be an inbox with even *more* messages and notifications demanding attention. reMail's focus on improved prioritization and search could be applied just as well to Wave as it is email.

Petr Buben said...
This comment has been removed by the author.
Petr Buben said...

I'd be interested in your comments regarding openAjax technology, .. thanks

pmby said...

The presentation reminded me Steve Jobs's style :)

Ian Bicking said...

There's also an old-school way of dealing with spam: when someone spams, you notify their provider, and that provider either suspends them or the provider is eventually ejected from the network.

This stopped working for email because SMTP forwarding made it hard to figure out where email originated, and it was hard to tell who wrote the email, and it was hard to report the spam to providers, and ultimately there was just a lot of fraudulent providers and no one could keep up. These shouldn't happen so much with Wave.