The Future of Email
Contents
What is Email, Really?
Email is, and has always been, a way of sending and receiving messages. This is important, because email shouldn't limit the type of messages or who you can send and receive to and from.
What makes an Email Message?
An email message has:
- A recipient
- Standard headers describing where the email message came from and who it is going to and what it is about. These headers may also include metadata to help in the sorting of the email.
- The message body. Traditionally, this is in text format but realistically, it could be any format imaginable.
What about technology X?
Email really encompasses all the following technologies:
- USENET: Usenet was a way of distributing messages to a wide audience on-demand. In reality, this is a universal email inbox that people share and where the data is distributed.
- Chat / Instant Messengers: Chat and instant messengers are really very fast email systems. Conference rooms just ensure that the messages are sent to everyone in the conference room. If the speed of the email delivery system is improved, then email can serve as a chat protocol.
- Blogging / Micro-blogging: These are really email message to the entire internet. Like USENET, if you consider the internet as a giant inbox, then each blog is really one of the folders and each post is really a message.
- Document Store: Some people use email to store data. The inbox of an email system is no different than a directory on a file system. If the data is in the cloud, then it is a director in the cloud.
Rethinking Email
We need to rethink what email is really about. It isn't about sendmail or SMTP. It is about messages from someone to someone. Each of the different protocols for distributing messages to the intended recipients (SMTP, HTTP, IRC, AIM, blogging software, etc...) are really extensions of the email system.
The new way to look at email:
- There are people (real or virtual)
- People send messages.
- These messages are intended for specific people, or perhaps large groups of people, or perhaps anyone who cares to read the message.
When you read your inbox, you're really saying, "Computer, tell me all the messages intended from me from people I want to hear from." See, you have spam filters to keep people out of your inbox. The way blogging and USENET work is that you have to ask to see the messages before you see them.
With this model in mind, the end system becomes more apparent.
The New Model
The new model looks something like this.
- There is one or more inboxes. These are places where people can put messages. Of course, you will control who can access these inboxes by controlling who knows about them as well as putting in your own protections. One of these inboxes might be your public inbox that everyone who knows you will know about, but which will be heavily filtered.
- Once you see a message, it is archived forever and indexed for easy retrieval.
- Public inboxes are really collections of messages that the public may read. Some are access-controlled so only specific people or groups of people can access them. Others are open to anyone who cares.
Push vs. Pull vs. Subscribe
One of the problems of SMTP is that it was a push technology. You would wait, passively, for others to toss email at you. This had a number of drawbacks. The most obvious was spam. I don't think we'll ever see a return to this type of messaging system. Instead, we are going to see a new subscribe system.
The way it will work is this. Let's say you want to join Amazon.com. You'll go to their site and share your identity with them, at least only the bits they care about and you feel comfortable sharing. They will encourage you to subscribe to their email feeds so that they can message you. So you setup your message system to pull messages from those lists, or at least inform you when messages are ready. Your system will contact Amazon, notify them that you are subscribing, and then Amazon will send notifications of new messages from time to time to your system. You can then go and retrieve those messages at your leisure.
This eliminates the problem of spam. See, you can't get notification messages unless you asked for them. All other requests are simply ignored. Also, the sender cannot consume your resources, except in sending a tiny message indicating that there are new messages available to be retrieved.
With your friends, a similar approach is used. I can only watch my friend for messages for me. He can only do likewise.
High-speed communications
Can a similar system be used for chatting and VOIP and video conferences? Yes, and this is the only way it can happen.
Let's say Alice wants to talk, real-time, with her friend Bob. She and Bob have already set up their systems to watch for when either of them want to talk to each other.
She tells her computer she wants to talk to Bob. This sends the long-awaited message, "Alice wants to talk with Bob." Bob's computer then notifies him about this. When he accepts the incoming call, then their systems begin the exchange of data as it becomes available.
Alice can leave her request open for as long as she wants. When she is no longer available, she simply cancels it. Bob can see how long she waited and whether she canceled the request.
