Ray Ozzie, creator of Lotus Notes, founded Groove Networks in 1997 to take groupware in a new direction. His new product, Groove, enables groups of collaborators to form in a decentralized, ad-hoc, administrator-less fashion, within or across corporate or other firewall/NAT-governed realms. Groove is a peer-empowering form of groupware -- what the company likes to call "peerware." In Groove, group members interact in highly-secure shared spaces. These spaces collect all the documents, messages, and applications ("tools") related to a group activity. Everything replicates to each member's computer -- possibly, to several devices per member -- and is available for online or offline use. Exchange of data is very granular, so that Groove-aware applications can support activities like shared editing in real time.
Jon Udell, author of Practical Internet Groupware, has been using Groove for several months, and says "it's what I've been waiting for."
Jon Udell: Like many of the products in the peer-to-peer space, Groove is really a hybrid of centralized and decentralized strategies. What does Groove centralize, and why? Conversely, what does Groove decentralize, and why?
Ray Ozzie: Groove can operate in a purely decentralized manner, but generally that mode of use will only be typical in home network or small office network environments where there's a single LAN segment and peers can be discovered through an efficient broadcast mechanism. More typically, Groove makes use of a variety of centralized services in a pragmatic fashion in order to make the communications experience feel more transparent to the user:
PRESENCE - When a computer running Groove connects to the Internet, it registers with a "presence server". Other computers interested in communicating with that device may have "subscribed" with that same server to be notified when that device comes online. This "publish-and-subscribe" awareness mechanism is a highly-efficient (e.g. generally non-polling) means by which computers can find out not only when a computer comes online, but also its IP addresses and whether or not it's behind a firewall or NAT.
RELAY - When attempting to communicate with a peer, it may be discovered that that particular peer is off-line. In this case, communications destined for the remote peer are instead routed to a "relay server" designated for this purpose. When the offline user reconnects, Groove retrieves communications from the relay server as it is also taking inbound peer connections. Also, if the users are operating from behind barriers, such as firewalls or NATs, relay servers can be useful as intermediaries to efficiently "switch" communications between them.
FANOUT - When one computer has the need to send the same information to multiple peers, it is sometimes more efficient to have a different computer doing retransmission to those peers. For example, if you are connected to the Internet over a 9600-bps GSM modem link, and you are trying to send the same information to five coworkers, it is more efficient to send one copy to a server that redistributes the content to the five others.
MAIL - When inviting other peers into shared spaces and activities, a common mechanism for distributing invitations is through standard SMTP-based e-mail.
DNS - When connecting to servers, e.g. presence, relay, or mail, Groove uses DNS lookup services in order to translate from server names to IP addresses.
Jon: You've said that human error is the Achilles heel of computer and network security. Can you elaborate on the strategies Groove uses to make strong security a mode that's always-on, yet fail-safe?
Ray: Based upon my past experience, vulnerabilities present in the systems management process dwarf technical vulnerabilities, from a practical sense. Two specific examples:
In systems based upon a PKI, the control of higher-level certificates represents a single point of vulnerability. Unless multiple-person password schemes are used to control the certificates, a rogue or disgruntled employee might create and certify identities, thus weakening trust in the certification authority.
In systems that route or authorize information based upon a directory (without cryptographic protections on that directory), rogue or careless employees can cause information to be routed to the wrong destination, can cause the wrong keys to be distributed, can cause access controls to be overridden, and so on.
The simplest way to minimize vulnerabilities is to minimize human interaction by removing the "knobs." For example, in Groove, you never have to worry about your information going over the wire unencrypted because there is no option to turn it off. You never have to worry about your information being disclosed when you lose your laptop because everything is encrypted to the disk, and there's no option to turn it off. You never have to worry about a rogue central directory administrator or certifier because there are none.
Groove, like products such as PGP, uses a peer-based person-to-person trust model, as opposed to a hierarchical certification model. This works because the product's design center is to support small group interactions, generally with people that we recognize.
Jon: If the objective is secure, yet spontaneous, collaboration that can work within and across corporate borders, Groove beats e-mail hands down -- assuming everybody you need to communicate with runs Groove. The aim, of course, is to make Groove ubiquitous. But for the foreseeable future, it's going to continue to be e-mail that makes the world go round. Groove can use e-mail as the vector for an invitation into a shared space, but otherwise doesn't facilitate communication among mixed groups of Groove and non-Groove users. How can Groove best co-exist with the current e-mail habit, while at the same time reforming that habit?
Ray: As you are subtly implying, the best co-existence strategy is one of integration. And, as you say, this is specifically why we've embraced e-mail as a key mechanism for invitation into Groove shared spaces. That said, two mechanisms are available -- albeit currently in prototype form -- that will assist in bringing e-mail-based users into collaboration with Groove shared space users. As Groove matures over the upcoming months, we plan on integrating more and more of this level of function into our base tools.
First, it's possible to send e-mail directly into a shared space (through a Relay Server) -- provided an appropriate method of addressing the e-mail, and a cooperating tool within the shared space. Thus, e-mail users will be able to, in essence, send or "cc" e-mail directly to a group of users sharing a Groove shared space.
Second, if designed to do so, it's a trivial exercise for a tool implementor to send a copy of shared-space activity to one or more external e-mail users, provided that they can format the content and activities in an appropriate way for the medium. Specifically, it's easy to copy messages (e.g., discussion items and documents) to e-mail users. It is a bit more challenging to understand how one might copy sketchpad strokes, changes to outline items, or chess moves to e-mail-based participants.
Jon: You've said that unlike NetWare or Notes or NT, Groove does not require an enterprise to deploy new directory or naming infrastructure, but that it can ride on existing infrastructure. How does that work?
Ray: When a user downloads and begins to use Groove, s/he enters one or more names by which s/he is commonly known. In my son's case, it might be his real name to his parents or a player name to his Quake friends, and yet another screen name to his EQ friends. Because most of us have multiple personas, Groove enables you to present yourself differently to different groups of people with whom you're working or communicating.
But many organizations have spent hundreds of thousands or millions of dollars investing in the assignment of unique or distinguished names for their employees. I might be email@example.com or CN="John Doe"/OU="Finance"/O="Big Corporation Ltd" within corporate boundaries. For this reason, Groove provides IT the capability of issuing and distributing files containing the official, preferred organizational identity -- the one from its corporate directory -- to its employees. Thus, everyone at BigCorp will know exactly what everyone else is called, and there won't be yet another redundant namespace to deal with.
Jon: Groove's security algorithms are plug-replaceable on a per-shared-space basis, so that a user who joins two different shared spaces can use two completely different security regimes. Why does this matter?
Ray: In dealing with security issues in Lotus Notes for something more than ten years, I learned a number of important things about cryptographic implementation.
First, security technology (algorithms, key widths, protocols) is virtually inseparable from security policy (law enforcement, national security). Just when you think that you've dealt with an export issue, you run into an import issue.
Second, there are issues of vulnerability -- both from a systems design perspective as well as the vulnerability of specific algorithms, specific key widths, etc. Nothing is static. In time, almost anything that we have confidence in today will at some point be questioned or questionable.
Finally, there are issues of customer preference. For whatever reason, some customers choose to standardize on specific security vendors, algorithms, implementations, and so on.
By designing our product to enable a variety of plug-in implementations, and by enabling a number of them to be used concurrently, we feel that the architecture has more than enough flexibility to carry us forward through many years of service for a wide variety of customers worldwide.
Jon: Groove generally thinks of peer-to-peer in the sense of person-to-person. But my Groove account can also propagate to many devices -- my desktop PC, my notebook PC, and so on. What's the best way to think about the relationship of people to devices in Groove?
Ray: Groove cleanly separates the notion of personal identity and device identity. We did this for a variety of reasons, but perhaps most significantly because individuals are naturally dealing with more and more devices in their work and home environment. Dealing with notions of synchronization -- trying to keep them all up-to-date -- is becoming more and more painful. The notion of just keeping simple contact lists in sync between a PC, a cell phone, and a PDA, has spawned many a new company.
In Groove, although you install the software on a given device -- e.g., a PC -- every user of the software has what we refer to as an "account," which contains all of your identities, all of your shared spaces, and so on. Through a procedure involving only a few clicks, you can duplicate your account on any other supported device. After your account has been brought to that device, all of your activities on one device are naturally and automatically kept in sync with things that you do when using your other devices. It's that simple.
Thus, we embrace the model that you may (and will likely) have multiple devices: a computer on your desk at work, a notebook computer that you use when traveling, and a computer in your den at home. Furthermore, because Groove allows more than one account to be present on any given device, the computer in your den at home can be used in Groove by you, your spouse, and your children.
Groove embraces multiple devices-per-person, and multiple people-per-device.
Next: Opportunities for other players, and enhancing the value of the pipe.
Jon: Groove uses a central relay server, if available, to store and forward messages, and to proxy connections between firewalled devices. This service is one of the business opportunities that Groove Networks, Inc., your company, has staked out. What are some others? And what are the opportunities for other players to deliver Groove-aware services?
Ray: Groove applications and tools are built with contemporary "component" technologies; Groove dynamically assembles applications by automatically downloading the requisite components from the Internet. In many cases, companies will wish to serve their tools to many, many consumers in a scaleable manner. For this reason, Groove offers its customers component hosting services, so that applications (as well as updates to those applications) can be delivered to millions of consumers quickly and efficiently.
Another service that Groove will provide is a backup service. This service is designed to give users confidence that they can recover everything stored on a device should the device be lost or stolen.
Because Groove is fundamentally based upon XML technologies, and because we fully integrate XML-RPC and SOAP services directly into our platform, it's very straightforward to communicate with Web-based services. Thus, we fully expect that many players will offer Web-based transaction services, information services, search services, etc., that are fully interoperable with and leveragable by Groove applications and solutions -- whether or not originally designed to be used in conjunction with Groove.
Jon: To the user, the Groove transceiver looks like a suite of applications -- chat, sketch, notepad, discussion, file archive. These apps are Groove-aware. When users make changes, the apps modify the Groove data model, causing updates to be written to the encrypted object store on the local disk, and also sent as encrypted packets over the wire to synchronize with all other Groove endpoints involved in the shared space.
Users, of course, will immediately wonder how they can achieve the same benefits with the best-of-breed apps they're already using -- for example, Visio instead of Groove's built-in Sketch app. What are the prospects for integrating popular apps with Groove's data model, so they can enjoy the security and synchronization features of the platform?
Ray: Groove tools use COM as their component model, and thus are afforded tremendous leverage when run on the Windows platform. For example, we've implemented an ActiveX wrapper component that enables us to add collaborative capabilities to many existing ActiveX components such as Microsoft's PowerPoint, Autodesk's WHIP!, and Macromedia's Flash, by transferring property changes and events between computers in a synchronized manner.
That said, we'll surely be working to enlist other software developers to build creative, interesting and useful collaborative tools for the platform -- either from scratch, or by enhancing existing application componentry.
Jon: You've said that Groove implements the model-view-controller paradigm. Can you describe what that means in the context of Groove, and describe the various APIs that developers can use to add value to Groove?
Ray: Groove applications are constructed using the MVC application-factoring design pattern that originated, I believe, in Smalltalk-80. In Groove, this generally means that the View components are the platform-specific user interface design elements such as UI controls. The Model components are the 100%-portable components that store data and expose interfaces and methods to effect changes on that data. The Controller components are the glue that binds the Model and the View, and in essence contain the business logic of the application.
A more sophisticated programmer may wish to implement new UI controls or new data models, and will generally do so in a language such as Visual Basic or C++.
Jon: Groove's adaptive communications layer ensures that the product will always work, configuration-free, even behind firewalls and NATs. How does it do that?
Ray: The product's communications layer is quite sophisticated. Without going into agonizing detail, it has the capability of dynamically sensing what communication adapters or interfaces are active at any given time. For each, it understands the dynamic performance characteristics at any given time, and what obstacles are between it and the open Internet such as NATs and firewalls. Furthermore, it can do protocol adaptation, using a variety of things such as UDP, a specialized compressed multiplexing protocol over TCP/IP, or HTTP, as necessary. It even has the capability of throttling its own use of communications resources, so that it doesn't unnecessarily interfere with foreground browser activity.
How does it do that? It's a mere matter of code.
Jon: It's tempting to imagine that wireless networking will soon make the disconnected client an endangered species. Obviously, though, you've put a huge amount of effort into ensuring that Groove does support the disconnected client. Why?
Ray: I believe that the ubiquitous, high-bandwidth, always-on, wireless Internet is a fallacy. Many 3G experts believe that many if not most cells will exhibit bandwidths in the 50-to-150kbps range, as opposed to the megabit numbers being touted. As today, sometimes you'll be in-range, sometimes out, sometimes moving between cells, sometimes moving through tunnels, sometimes in an elevator, sometimes in a building, sometimes on an airplane, sometimes in your basement.
And look at the current wired Internet. There is no less than a three-order-of-magnitude difference between the 45 Kbps of many dial-up connections to the 45 Mbps of many college dorm T3-over-100baseT connections.
We designed our product pragmatically -- for a real-world Internet of variable bandwidth, variable latency, variable jitter. Furthermore, we believe that "disconnected mode" is something that is not only a reality from a connectivity perspective; it is also a reality from a workstyle perspective: sometimes you simply want to disconnect, do work, and then share the results.
Jon: Groove today runs only on Windows, yet the aim is to be ubiquitous. Will the product be ported to flavors of Unix and to the Mac? Will it scale down to PDAs?
Ray: Although we're not announcing our non-Windows platform plans at this time, we are indeed demonstrating a Linux port. The product was designed with a multi-platform porting architecture, with an eye toward "best of breed" user interface on any given platform, but also permitting full-fidelity data synchronization regardless of UI.
Jon: Groove's minimum requirements -- 233-MHz Pentium, 64 Mbytes RAM -- push somewhat beyond the center of gravity of the PC installed base. Likewise, the download size of about 10 megabytes is a bit daunting for the 56-Kbps modem crowd. How significant are these obstacles for rapid and wide adoption of the product?
Ray: Initial system requirements were chosen conservatively for our Preview Edition 1; they are likely to shrink. The download size is indeed a substantial download for a modem user, however -- to put it in perspective -- it's about half the size of AOL or a browser download, or about the size of Layla as an MP3. OK, think Crush, or Firestarter.
In this day and age, for corporate users, for campus users, for cable and DSL users, surely it's not going to be a problem. For modem users, if they hear that it's useful or cool, or if they have a close friend or coworker who wants to interact with them, they'll download it.
Jon: Groove's trust architecture is more analogous to PGP, or SDSI and SPKI -- which we had better spell out as Simple Distributed Security Infrastructure and Simple Public Key Infrastructure -- than it is analogous to hierarchical x.509-style PKI. Why did you take this approach, and how will it make life easier for users?
Ray: Groove was designed from the outset to support the way that people really interact with one another in small groups. That is, in a small group, I don't need a certification authority to tell me that Jon is Jon -- I know that Jon is Jon. I recognize Jon because I work with him; I know him.
When we set out to build the product, the closest thing to my requirements was PGP's web-of-trust model. It was a great mental starting point. The result is a product oriented around a peer trust model for dynamic peer group formation, but one that internally supports x.509-style distinguished naming, so that we can service a customer who has made an investment in client-side certificates.
Jon: Groove looks like a great way to help users work around the IT bottleneck, creating for themselves the secure, distributed, and universally-accessible workspaces that they desperately need. Why shouldn't IT fear Groove, though? How can Groove help IT manage the empowerment that Groove's users enjoy?
Ray: Groove solves many problems that are high priorities right now for IT. If you look at virtually every major enterprise worldwide right now, they're deeply entrenched in partner relationships. Structured partner relationships such as supply chains, semi-structured partner relationships such as product design partners, less-structured partner relationships such as external Web design shops, accountants, lawyers, and so on.
In each case, the IT person is hammered by one set of people asking to let their partners "into the network" by exposing a VPN to them, and another set of people asking the IT (or line-of-business) group to develop an "extranet" or "portal" for the partner -- essentially a controlled crack in the firewall.
But many if not most interpersonal relationships between partners operate in more of a symmetrical manner. Extranets or portals generally operate in a unidirectional manner, and the site capabilities are generally relatively static and limited. Opening a VPN "hole" in the firewall for a partner is very, very rare because it's so difficult to control.
So what happens? Everybody uses e-mail ... because it usually works. Regardless of how clunky the rendering is, regardless of whether it looks the same on either side, regardless of how unsecure it is. It just works.
Groove enables the IT or line-of-business manager to create workspaces that are much more appropriate to the task than plain e-mail, when the task involves collaborative design, supply chain exception handling, or product support, among many others. But these workspaces operate across the firewall transparently and in a highly secure fashion. It's like a highly secure VPN that is limited to the scope of a relationship or a project. It's more in the hands of the participants than a centrally-designed extranet or portal, and far more controlled than a raw VPN.
Jon: It's obvious why enterprise IT should care about Groove's automatic and comprehensive security. Why should ordinary users, who are just chatting with friends and sharing photos with family members, care about security?
Ray: Although this is highly individual and personal, let me reduce it to this: Security, control, and privacy are intimately related, and they mean a lot to us. And we hope that they increasingly mean a lot to you.
The things that you're sharing with your friends and family within Groove are not occurring on our Web site, or anybody's Web site. Nobody's recording what photos you're looking at, and nobody designed the application awkwardly in order to monetize your page views. Nobody is watching how you interact with your friends and family, and trying to figure out why so that they can sell you something. Nobody's going to take your photos away when they realize that they can't sell you anything that you don't really want.
A New Groove - DevX's interview with Ray Ozzie
And it's not just about photos. It may be about family health issues that you're discussing with your doctors or your close friends. It might be about personal and private financial or legal matters.
Groove is a tool that is intended to help you to communicate with the people that are important to you. If you find it useful and valuable for those communications, as I know that many will, you may ultimately buy enhanced versions of the product and services from us. You'll also likely buy tools and solutions from our partners that will make it even more useful.
Groove isn't an indirect marketing play. It's about enhancing the value of the pipe that is connected between us, in a way that gives you control and respects your privacy. It's a way for you to share and do things with the people who are important to you. It's about value, and trust.
Jon Udell is an author, information architect, software developer, and new media innovator.
Return to the P2P DevCenter.
Copyright © 2009 O'Reilly Media, Inc.