Wave is intended to be an open communications protocol to subsume email, instant messaging, and presumably other things such as wikis. It is still under development. It is extensible. There is a very nice looking (at least as far as I can tell from the demo video :) ) reference implementation.

The Wave system provides real time, versioned, collaborative document editing. The system can be used for instant messaging as well as collaborative document editing.

Chris Saad and Elias Bizannes apparently agree that Google Wave will replace email and wiki (!). They merely disagree on how long that will take.

Technical Summary

The following description of the threaded conversation data model is a simplification and may be slightly incorrect. A “wave” is a tree of message nodes (i.e. a threaded conversation). Each node is associated with a list of users, and can contain a list of content documents. Each user on a node’s list has read and write permission to the attached content. Users not associated with a node cannot see that node or its subtree. The content can be rich media. The content can be dynamic “gadgets” (see below).

The Wave system provides real time, versioned, collaborative document editing. The system can be used for instant messaging as well as collaborative document editing. Amazingly, the client-side part of the keystroke-level simultaneous editing is implemented within HTML 5. A personal RecentChanges (for all conversations that you have access to) is provided, although it is not called that.

Gadgets: programmable extensions which are embeddable as content. A Gadget’s state is tracked by the Wave versioning system. A Gadget’s state is automatically synced between all users by the Wave system, so that all you have to program is:

and the Wave system propagates the state to all users, for live simultaineous editing.

Branching: Wave provides support for copying a message from a source conversation into a destination one; this branches the message’s version tree; the different branches can later be merged (I think the merge feature is as yet unimplemented though…).

The Wave APIs (will) allow you to programmatically access everything, so you can write different clients, bots, etc.

In addition to the technical advances, a major benefit here is that Google will basically be introducing the idea of what we might call wiki-style discussions (i.e. discussions composed of versioned, editable messages) to the world. The Wave people seem to prefer Interrupted Thread Mode in their demo.

There is a federated server architecture. Privacy: private messages don't get sent to servers which don't serve any recipients of that message. The Wave server-to-server protocol is an extension to XMPP (the Jabber protocol).

Google plans to open source “the Lion’s share” of the code, both client-side and server.

License: OpenSource. Federated servers, also Open Source. Runs on HTML 5.


Google Wave does much of what the OneBigSoup suggests, and what it can’t do, I think it can fairly well be extended to do. It basically forms a DevelopersVirtualWorld.

I think you could implement:

  • LinkLanguage & NearLink & LocalNames by making a robot that alters documents to perform hyperlinking by a specific language. I can easily imagine it reading from a CommunityLocalNames page that is itself a wave.
  • OverHear, also via robots, and/or specialized “over-hearable” clients.

Frankly, this is the most amazing thing I’ve seen in a long time.

Writing a robot to add the internal links – that’s a very cool idea. I think you’d need a protocol to name blips, however. But I guess you could handle it like permanent anchors. A certain markup names a blip, and slightly different markup refers to a name – and will end up being linked. I like it. Maybe something simple as using bold. Sure, it would also create a lot of useless names, but those would hardly ever be used by people, so would not be linked.

In this example [[a protocol to name blips]] would link to the previous paragraph.

Now that I’ve heard about the emoticon robot, I see how it would work.

I like it.

A lot.



Are you actually considering using it for some purpose?

It looks pretty awesome to me. At a first glance, it looks as if it really could subsume email, IM, and almost subsume wiki. We’ll see if it as awesome as it looks.


Wave may provide a programmatic interface that could possibly (by the force of Google) become part of the standard Wiki API that I have hoped for. However, various operations may not be quite simple enough:

  • The precise way to retrieve RecentChanges is not yet described in the documents that I could find. It is not in the Wave Robot API, which is concerned with operations at the level of a single conversation node (or is it an entire conversation?). It appears that the architecture only defines RecentChanges as personalized to a user: “User-data wavelets are used to store information which is private to an individual user (that is, the user is the sole participant), such as read/unread state.” – [1]. If you want an impersonal RecentChanges, you could add a bot which subscribes to a list of documents and exports a list of RecentChanges.
  • I did not see anything in the APIs purporting to provide access to both source text and marked-up text, which isn’t surprising, since I don’t think this concept is native to Wave (a similar thing is present in the state associated with Gadgets, though – the source text would be the state, and rendering would be done client-side).
  • Edit conflicts: If two people edit the same Wave at the same time while one of them is offline, I’m guessing that edit conflicts may occur, preventing one of the user’s message from being read by the other. In this way, Google Wave does not subsume email, since edit conflicts cannot occur in email, hence if your email is successfully delivered, you may assume that the text you wrote was received. I suppose that if you and the other users socially agreed to a certain protocol (e.g. perhaps: always adding new replies at the end), edit conflicts may not occur, but this is still placing an additional requirement on the users compared to email.
  • Integration with distributed version control systems: Not so much a limitation but a potential missed opportunity. Not being a version control expert, I’m not sure how Wave’s versioning algorithms and data structures compare with those of DVCSs such as Mercurial, Git, and Darcs. Perhaps it would be possible to build a Wave-like thing that conforms to the existing data structures and/or protocols of one of those guys?

In addition, a general limitation is that the data model seems to me to be unnecessarily complex (although perhaps I don’t fully understand it). Above, I described it as a tree of message nodes, where each node is associated with a user list and a list of content documents, and noted that this is a possibly incorrect simplification. The data model actually consists of “waves”, which contain “wavelets”, which contain “blips”, according to this (the whitepapers at don’t mention “blips”, except as an example of an XML start-tag). I don’t understand why there isn’t just one type of node, rather than three. I’m going to ask about this on one of the email lists.

The server protocol seems complex, but not unnecessarily so (it has to define delta operations, i.e. patches, which are sent back and forth to do the simultaneous live XML document editing), so I don’t have a problem with the complexity there (my issue is only with the wave/wavelet/blip data model).

re: Hans: well, someone will surely write a wiki based on it :). I think a Wave wiki (which would get support for simultaneous live editing, embeddable gadgets, threaded discussion, Wave-style access controls, and interoperability with Wave bots, all for free) could be written using the robot API and gadget API, without actually writing a Wave server.

Bayle, Thank you for this summary. I find it sufficiently informative to at least make me start thinking about how to try working with this enough to be able to assess its value in a “real” business context.

For a few additional insight…

Wow, I didn’t realize there was so much activity here lately..!

To answer your question, Hans: “Yes,” – when Wave comes out, I’ll be using it for just about everything.

It will be nice not to have a separate wiki, forum, mailing list, and etherpad for the various groups I’m participating in.

This all presupposes that it works, … But hey, it’s Google.

Right now it seems to me that Google Wave affords private affairs. A wiki is public by default. A wave requires some sort of opt-in or invitation. When I have a conversation on Twitter regarding a topic, all our friends can listen-in. Actually, they have to. A Wave would require some sort of invitation to get them into the fold.

A Google Wave is built by threads (wavelets) containing little documents (blips) that remain editable. There is a parent-child relation, thus a Wave has a tree structure. Furthermore, some messages have a reply-to relation between them. As such, Google Wave does not support building a link language because the blips are ordinary Google Documents. Sure, they can have external links, embed multi-media, etc. They look like forum posts or discussions on a Flick page. It’s probably possible but tricky to link to specific blips as external links. But a wiki has named pages, and in the case of WikiNames invoking the name creates an internal link, and in the case of Free Links adding minimal markup (double square brackets) creates an internal link.

The presentation as a thread is not mandatory. A client could be built that uses a Google Wave but looks like a wiki. Right now a Google Wave lacks the tools for HubAndSpoke navigation, or it was well hidden. Following links and backtracking, some starting points like RecentChanges at the top – all of this is missing and would have to be added.

Wikis have had a bit more time to work on user interfaces. I think wikis scale down – even if you know very little, you can still create pages and links. The Google Wave interface looked a bit trickier.

Have you seen the firehose of public waves yet?


Just wondering: how would the linkbot know what to link? I mean, wouldn’t it need []’s or _’s or CamelCase?

If not, then wouldn’t this approach suffer the same problems of PlainLink and AutoLink?

As an aside: I’ve thought of a similar thing, but implemented as a Firefox plugin that would add links to any page you visit according to a list of “Link Databases” that you could subscribe to - including your own, locally stored “Link Database” that would ‘override’ any of those targets and add any not-yet-created definitions that you felt were valid. Optimally you could also choose to share your “Link Database” so others could subscribe to your set of definitions.

I am overwhelmed and haven’t read all responses prior, so I am negligent; However, I will answer from the fragments I have read.

The linkbot would take titles from the titles of the Waves (presently determined by the first line of the Wave.)

It would then recognize uses of the title in other documents.

My preference is to use CamelCase by convention, so that titles are consistent (having a standard,) and so that it’s clear what is LinkLanguage and what is not, and so that it is effortless.

EditNearLinks: HubAndSpoke OpenSource CamelCase WikiNames


The same page elsewhere: