Tangled in the Threads

Jon Udell, October 25, 2000

Let's Groove

Ray Ozzie unveils a groundbreaking new groupware platform

Yes, Groove's a P2P product, but that's only one of several technological underpinnings. What Groove does is empower small groups to form spontaneous, secure, and coherent shared spaces for collaboration.

Every once in a while, a great programmer gets to start with a clean slate. When Dave Cutler rethought VMS, he created Windows NT. Now Ray Ozzie has rethought Lotus Notes, and created Groove. There's been a lot of buzz and speculation but, until last week, no hard information. Ozzie and his team worked in stealth mode for three years on the project. The coming-out party was held last Tuesday at Internet World. I've been working with and studying the software for several months. Now I can finally talk about what Groove is, and why I think it's an important breakthrough.

As many suspected, Groove embraces the peer-to-peer model that's all the rage nowadays. Recognize, though, that the project began in 1997, long before Napster and the ensuing P2P hullabaloo. P2P is one of a number of Groove's technological underpinnings (security and synchronization are some others), and it's P2P that gets people's attention nowadays. But the term that defines Groove for me is not P2P. It's groupware.

I've spent years trying to define what groupware is, and imagine what it can be. It's a slippery concept. Lotus Notes was, before Groove, the product that best embodied the essential nature of groupware: a system that brings together people, messages, discussions, documents, and applications in the context of a shared project or activity. Notes does this brilliantly, and was many years ahead of its time. Too many, as it turned out. Some Notes deployments succeeded dramatically. Many corporations, though, found Notes to be a deluxe email system that didn't ignite the frenzy of knowledge sharing that they hoped for.

Groupware analysts will tell you that the problem lies with human nature, not Notes. Most people in most organizations don't really want to share information; power flows instead from hoarding it. There's more than a grain of truth in this. But such cluelessness isn't the whole story. Notes, as it developed, became a heavyweight system in many respects: heavy expense, heavy administration. A Notes rollout within a large corporation was a multi-year, multi-million-dollar proposition. And once it was done, the employees in that corporation could talk to...each other. The huge Notes investment couldn't help them collaborate with colleagues in other companies unless those companies also ran Notes, and even then, administrators in each of the companies would have to engage in a mind-numbingly complex process of cross-certification and credentialling.

With Notes you can't spontaneously collaborate across corporate borders. We tend to work with the people that our infrastructure make it easy to work with. But as a scientist whom I interviewed for my recent groupware report noted:

We collaborate amongst ourselves too much, and with other people not enough. If we have a well-defined internal project, we can get IT to set up the Notes support, but collaboration shouldn't only be internal.

Groove proceeds from a different set of assumptions than Notes. Among them, Groove assumes that collaborative projects can and do involve people in every imaginable circumstance: on LANs behind different corporate firewalls, on dialup connections with dynamic IP addresses, behind cable-modem or DSL NATs, or even offline. In any of these situations, a Groove user can create a shared space and invite other Groove users into it to work on a project. The tools that support collaboration include (in the initial release of Groove) threaded discussion, chat, a notepad, a sketchpad, a calendar, a file archive.

The shared-space data that members create using these tools doesn't live on a website, or in any canonical location. It synchronizes among all the devices used by all the members of the group (in some cases, to several devices per member). If I'm working on a project and need to bring you on board, I invite you into the shared space. If you're already a Groove user, I can invite you using a Groove instant message. If not, I can send you an email that will guide you through a Groove installation. In either case, your device will receive a complete copy of the shared-space data. The process is as spontaneous as mentioning somebody on the Cc: line of an email message (modulo the effort of installing Groove, admittedly), but it delivers much richer context. It's not like being drawn into an email conversation midstream, and having to reconstruct the state of the project from incomplete fragments of quoted responses. When you join a Groove shared space, you get all the stuff, and it looks the same to you as it looks to everybody else. It's no more effort to invite a colleague behind a foreign corporate firewall than it is to invite a colleague in the next cubicle. And here's the kicker: the shared space formed in this spontaneous way is secure. Really, really secure, both on the wire, and on every hard disk to which it synchronizes. Think of a Groove shared space as an instant VPN, which you can extend to anybody you need to collaborate with, and do it right now, without asking an administrator to punch holes in firewalls and do all the other nasty configuration that nobody ever has time for. This is a capability I've wanted in the worst way, for the longest time.

From Notes, to Internet groupware, to Groove

What prompted me to write a book on Internet groupware was my discovery, circa 1995, that Netscape had crammed a lot of the essence of Notes into Internet-standards-based software that was suddenly ubiquitous, and that tied into communication channels -- email, primarily -- that enabled spontaneous collaboration within and across private and public realms. It could even do these things securely, though I'm probably one of the few people to have discovered, and exploited, the power of private, secure, and rich-text-capable NNTP discussion groups as accessed by Netscape or Microsoft newsreaders.

The fact is, you had to be pretty determined to squeeze Notes-like functionality out of the web/mail/news combo. I was, and I did, and folks who've read my book tell me they have too, but I've got to admit that it's beyond what many people can or will do. Even at its best, the style of Internet groupware I promote in my book involves too many standards. When you cobble together a system that uses NNTP for discussion, and email for messaging, and the web as a document archive, the result feels -- predictably -- like something that's been cobbled together. What I always admired about Notes was the way that messages and discussions and databases and applications are all made out of the same stuff. There's a unified data model, a single API, and a set of common services -- such as data replication -- that you get "for free" when you use, or build on, the Notes platform.

Groove is like that too. Ozzie describes its underlying communications engine as "an XML object router." The objects exchanged among Groove endpoints need not be whole documents, though they can be. More typically, they're incremental edits -- a line of text in a chat window, a stroke in a drawing. Like Notes, Groove makes sure that these pieces of data get where they need to go. Unlike Notes, no central server needs to be involved. Groove works just fine between two notebook PCs connected by a crossover cable. On the other hand, Groove is -- happily -- not religious about its peer-to-peer nature. It's not meaningful to tout the notion of a "pure" P2P architecture, and Groove doesn't. When Internet-connected Groove devices converse, a relay server can provide a number of useful services. Like Napster, but more aggressively, the Groove relay brokers connections for devices behind firewalls and NATs, or on dynamic-IP dialup connections. It also provides store-and-forward service for Groove delta messages (every piece of user or administrative data exchanged within a shared space is such a message) so that shared-space members can go offline, then reconnect and resynchronize.

All crypto, all the time

For the basic apps that ship with Groove, as for the more robust apps that I hope will follow, these services -- synchronization, store-and-forward -- are a powerful draw. Knowing that everybody on a project team is seeing the same calendar, the same threaded discussion, and the same file archive is half the battle. The other half is making sure nobody else is seeing that stuff. I've signed my emails for years, but can count on the fingers of one hand the number of people who've used the public key in my signature to encrypt a sensitive message to me. The reality is that we routinely send information as plaintext email, no matter how sensitive it is, because it's been too hard for most people to figure out how to do otherwise. So we cringe when we hit Send, in order to transmit that nondisclosure agreement or product specification or sensitive personnel document across the open Internet, but we still go ahead and do it, because life's short and the mail must go through.

This is nuts. We ought to enjoy some basic guarantees -- that our messages come from authenticated sources, are confidential, and haven't been tampered with -- as a matter of course. And Groove makes those guarantees. Crypto is always on, period. You can't even turn it off if you want to. There's nothing to configure, and this was a key design constraint. What Ozzie observed with Notes, over many years, is that security failures almost invariably boiled down to human error. There were too many choices, too many knobs. Groove does away with the knobs. There are just two things you have to do in Groove to secure all the apps and all the data in all your shared spaces. One is to choose a strong passphrase, because that governs the master key that protects your Groove account, and by extension all the other cryptographic keys that protect your data on the wire and on disk.

The second thing you have to do, if you care to authenticate your discourse with others, is to check the fingerprint (that is, the hash of the public key) of someone you have not previously communicated with in Groove. In this regard, Groove works more like collegial PGP (Pretty Good Privacy) than like hierarchical PKI (public-key infrastructure). Groove is not antithetical to PKI; in enterprise deployments, it can be configured to ride on top of existing directory and certification systems. But out of the box, it's attuned to the needs of small groups of collaborators who don't need third-party authentication because they work together and know one another. If I invite you into a Groove space and you're not sure about me, you might want to call me and ask me to read off the fingerprint of my Groove identity, which you can then compare to the fingerprint your Groove software computes from the invitation message I sent you. Alternatively, we may have met in person, and I may have given you a business card bearing my Groove fingerprint.

Will users actually do this? Honestly, in most cases, probably not, any more than most users will check the fingerprint on a digital certificate presented by an e-commerce server whose domain name doesn't match what's in the certificate. (This happens all the time; in theory you're supposed to investigate the mismatch; in practice nobody does.) But here's the key point: Groove always secures (i.e., encrypts) your data, even when you don't choose to authenticate your communication partners. That's very different from, say, S/MIME, where encryption is not even possible until both parties acquire and install PKI-based certificates. In reality, for most of the projects and activities for which I expect to benefit from Groove, identity-spoofing isn't going to be an issue. What matters, in these cases, is confidentiality, and we'll have it. When authentication does matter, it's a peer-to-peer operation, where the peers are people, not machines. Authentication, when needed, is just a phone call away.

I've been using Groove to work with some folks at Groove Networks on a project. We had to exchange and discuss some highly-confidential documents. Doing so in a secure shared space that we conjured up just for this purpose was, for me, a dream come true. Will Groove achieve the browser-like ubiquity that it seeks? There are obstacles. Price isn't one of them, because you can download the software for free. It's big, though -- you might want to think of Groove as a next-generation Internet-oriented operating system -- and at the moment it only runs on Windows. But unlike the Web, which is really a single huge shared space that produces its network effect in proportion to the aggregate number of sites and users, Groove aims to support lots of little (or, you might say, right-sized) shared spaces. On a per-project basis, you don't need millions of people to be running Groove. You only need the people you're working with to run it. As the product matures, I plan to strongly encourage the people I work with to Groove with me.

Jon Udell (http://udell.roninhouse.com/) was BYTE Magazine's executive editor for new media, the architect of the original www.byte.com, and author of BYTE's Web Project column. He's now an independent Web/Internet consultant, and is the author of Practical Internet Groupware, from O'Reilly and Associates. His recent BYTE.com columns are archived at http://www.byte.com/index/threads

Creative Commons License
This work is licensed under a Creative Commons License.