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.
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.
http://www.youtube.com/watch?v=v_UyVmITiYQ
License: OpenSource. Federated servers, also Open Source. Runs on HTML 5.
Features:
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:
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.
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.
Limitations:
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:
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 http://www.waveprotocol.org/ 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… http://news.cnet.com/8301-17939_109-10255402-2.html
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?
Lion,
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.