In his white paper Collaboration Software Clients: Email, IM, Presence, RSS & Collaborative Workspaces Should Be Integrated for Business Communication Part 1 Michael Sampson compares strengths and weaknesses of different collaboration tools. He calls for a “super client” that integrates the strengths of these different tools. While we agree with this call to arms, and would love to have (or build) this super client, the reality in the business world is, that we are going to be stuck with the existing technologies for some years to come.
Changing a core piece of work infrastructure is a daunting task an no organization will take it up lightly. Besides that – there is no “super client” on the horizon yet, so the wait for a better collaborative work environment is going to be long.
In the meantime, people in business have a definitive need to collaborate. As Sampson outlines, much of this collaboration is done by email, even though email by nature is not ideally suited to the task. Sampson lists 10 specific issues with email, that make using it for collaboration difficult or undesirable.
ZAPPATA Networks is in the process of delivering a software for “Personal Groupware”. It relies on proven infrastructure (of which email is a fundamental piece) and combines P2P (Peer to Peer) technology and other concepts to alleviate those exact problems Michael Sampson lists.
This white paper will take a look at each of the problems and show how ZAPPATA eliminates them – resulting in “email” as a viable tool for collaboration.
The original metaphor for email was that of the letter, delivered electronically. Today, email often consists of small snippets of conversations between people. In traditional email systems, these conversation fragment beyond control, when more than two people are involved in it.
ZAPPATA follows the “mailing list model” where a central instance contains the complete conversation. Replying to a fragment of the conversation sorts threads the answer into the correct context. Looking at such conversations with an email client that understands threading (as most do), the complete flow of the conversation can be reconstructed and understood – independent of how many people have participated in it.
According to research, between 50% and 95% of email is spam. The fundamental problem is the SMTP (Simple Mail Transfer Protocol) used for transmitting email between users and servers. SMTP has no provisions for authenticating the sender of a message, making it extremely easy to forge sender and sending server. Several proposals are underway that plan to remedy the situation, but it’s unlikely that the Internet will be spam free for the next couple of years.
ZAPPATA uses the SMTP protocol to deliver email but has added strong authentication based on private/public keys. A ZAPPATA instance will only accept email from another ZAPPATA instance, if the sender is able to authenticate itself. While it’s still possible to use ZAPPATA to send junk email, it is not possible to forge the sender – he is always known. By guaranteeing that the sender is in fact the real sender and not somebody acting as if, and by not allowing unauthenticated communication, all emails that are received can be accounted to their respective senders. The chance of a spammer sending spam with his real identity are very slim.
Communication through ZAPPATA are therefore bound to be spam free and relevant – much like the communication happening in internal corporate networks that use proprietary email programs like Lotus Notes or MS Exchange.
Traditionally, email is delivered in a store and forward manner from server to server. There is no immediate feedback on what the status of a message in transit is.
ZAPPATA routes email directly from one client to another. There are no intermediaries that store the information. Therefore the sending ZAPPATA knows exactly if it was able to deliver a message to the recipient or not. When an email has been delivered, it is available at the receivers end.
People receive to much email.
This is a fact, and it seem that ZAPPATA does not help immediately. However, we think that ZAPPATA email becomes a “higher priority” email because it will relate directly to projects or work the user has expressed an interest in. In addition to 1-1 email, ZAPPATA has the concept of a “subscribed folder”. Anyone can create a folder and share this folder with peers. The receivers have the freedom to subscribe to specific folders. In that case, ZAPPATA will poll the originating ZAPPATA for new additions to that folder, they will not be delivered to the recipients, rather they retrieve it – very much like the pulling of RSS feeds from interesting sites. It is therefore in the recipients discretion to unsubscribe from folders that have little interest to him.
Regular email is in general transmitted in plain text across the Internet. It is easy to intercept email with easy-to-obtain software. Confidential messages must be encrypted to be secure, however few people know how to do this or bother. In addition, there are no clear standards so interoperability is difficult.
ZAPPATA encrypts all communication between ZAPPATA instances. The private/public key infrastructure to do this is maintained totally transparent to the user and there is nothing he must do to enable this security. All communication across the Internet and between the users email client and his ZAPPATA instance are encrypted using SSL (Secure Socket Layer). In addition, messages are passed directly from sender to receiver. There are no intermediaries that could intercept or read the communication.
Individuals organize messages in any way the want, for example via a hierarchy of nested folders. There is no universal principle across email correspondents.
When ZAPPATA users create shared folders and subscribe to them, they subscribe to a fixed hierarchy. While they still can organize mail individually in their email clients, there is always a “master list” that contains the one hierarchy. This hierarchy can not be changed. Therefore there is a central reference to all messages in a folder (“look at message number 3 in the discussion about the “Acme Widgets”)
Microsoft Outlook is one of the two most used email clients in the market and it suffers from many security problems. While newer versions of Outlook supposedly have less problems, many users or organizations can’t or won’t upgrade.
Unfortunately, there is nothing ZAPPATA can do about this. It is email client agnostic and works with any email client that supports IMAP and SMTP.
Email is asynchronous in nature. While communication can be very quick, it’s not real time and once a mail has left the sender, there is no feedback on it’s status.
ZAPPATA doesn’t change the fundamental metaphor of email communication. If you are looking for synchronous communication, you will have to use another medium (like the phone). ZAPPATA gives you feedback on the status of each email sent, because it controls the flow of mails directly.
Email is stored separately from a users documents and is difficult to extract.
ZAPPATA can be used to collaborate on both messages and files. The user interacts with files and messages through his regular tools (email client and file system).. ZAPPATA integrates these things and presents them to the user via a standardized protocol. Internally however they are stored and transmitted together and can be exported to other applications without problems. ZAPPATA has no proprietary storage mechanism (like Exchange with PST files, Notes with NSF files or Groove with their binary XML storage). Instead all information is stored in plain text or plain files in the file system and can be exported from there.
Many Email servers limit the size of attachments, garbles or renders them unreadable to others.
Because ZAPPATA is it’s own email server, there are no limits on what and how many files can be transfered. The forthcoming File Sharing component of ZAPPATA will make away with file attachments to emails altogether and allow the user to seamlessly work with files / folders as he is used to. ZAPPATA handles the synchronization of files between different ZAPPATA instances. Again, this process is seamless to the end user.
50% – 80% of email addresses change each year. Users can “fall of the face of the earth” if no mechanisms are in place for coordinating addresses.
In ZAPPATA an email address is in fact a username@hostname combination. The host name is managed by ZAPPATA Networks, meaning that each user (or rather each computer that runs ZAPPATA) has his very own host name in the “zappata.net” top level domain. This is a unique and unchanging entity that can be transferred across computers and ISPs because it is totally independent of both.
ZAPPATA thus combines the strengths of email, eliminates many of the weaknesses and combines email push with the RSS pull model. It is well suited for business collaboration here and now, and brings a lot of desirable features to the business now. By integrating into existing structures, leveraging existing and proven protocols and not forcing the user to adopt a different set of tools to work with, ZAPPATA is a cost effective, easy installable solution. There is no central administrative setup or maintenance needed to keep ZAPPATA running. In true Peer to Peer fashion, ZAPPATA organizes itself and is able to bridge companies, corporations and individuals. Due to it’s strong authentication and encryption it doesn’t expose any sensitive information to the outside world and gives the users a seamless infrastructure for private collaboration.
The ZAPPATA beta can be downloaded via the download page
The ZAPPATA beta test program will be open to the public starting on August 25th, 2004
Please come back on Wednesday, August 25th to download ZAPPATA.