Will RSS Replace E-mail?
There seems to be a great deal of discussion lately about the highly exaggerated death of e-mail as the RSS camp starts to make a case for moving to an RSS-centric model per individual communications.
Ross Mayfield has a rather lengthy look at the higher-level issues which tend to revolve around the different paradigms used in mail (push) versus RSS (pull). Here's some of those thoughts for background:
Push Models have higher transaction costs because risks and costs are not evenly distributed. It costs nearly nothing to compose and send a message and costs practically nothing to send an additional copy to someone. Costs are borne by readers, something well known and the cause for spam, the burden of processing messages coming to you without your control. Risks are borne by the Receiver for having an address alone. The real costs are incurred when the Receiver tries usurp control over costs.
[...]
Contrast this with Pull Models. The difference is the Reader chooses and can control whom they want to subscribe to and when they want to be interrupted. Risk is borne by the Sender with every message they put out and the quality, albeit with a low bar and informal culture, they are consistent with. Costs are controlled by the Receiver. They choose what to subscribe to and more importantly unsubscribe from, on average less than 150 feeds, an expected group size.
Though the possibilities of it all are something to marvel at, I'm left still at a loss to reconcile a system like this. Practically speaking, here are some of the issues I seem to have with a pull-based model for e-mail:
Expediency - E-mail has the notion of speed built into it. Though it's not characteristically a real-time technology, our widely consistent connections to the Internet provide many with a near real-time experience. This affords us the ability to have urgent issues delivered to someone quite efficiently.
How exactly does one convey urgency in an RSS-based system? There current is no standard, whereas e-mail has a flexible, established protocol. More importantly, how to we insure that messages get through?
Security - In general, e-mail is protected by one of many layers of security that protect access to an account. Granted, the majority of these are plain-text and easily corrupted, however, they are still in place and more secure methods already exist.
Though there are provisions to secure RSS, these are narrowly implemented. To add to the acceptance of this layer of security, we need easily understood implementation and social protocols as well as wide vendor support for these mandated features.
The current state of RSS negotiations casts a dim light on the future of a unified vision.
Efficiency - the RSS camp tends to rely on the use of the If-Modified HTTP headers as the main combatant against bandwidth bloating. This is a very efficient system and certainly assists in the problem. However, it is NOT quite the same as how mail is retrieved. When mail is retrieved via POP, for instance, we have two options. The first option marks the message as read/delivered/not new and removes it from view (if Leave on Server is not checked). The second option provides us with the ability to physically delete the message from the inbox.
This becomes important when we physically retrieve that information. How much data do we pull back in these models? Clearly, there is optimization in one and not the other.
That matter aside, there is an additional multiplier worth considering. In an e-mail-based system, the user polls a single location. In an RSS-based solution, we are potentially lookng at tens or hundreds of individual one-to-one streams. Though this provides an opportunity to use relatively-smart pinging intervals (assisting with the expediency issue), it also means that more and more checks are actually required.
Experience - The experience of RSS-based e-mail need not be different from how we work with e-mail, but there are significant hurdles. Here are just a few simple tasks that present issues:
New accounts - Is the e-mail address the permanently-linked, universal addressing system we use? Though they can sometimes be complicated, they are relatively easy to remember, store, and distribute. Will things be reduced to a complex arena of URIs instead? Will we be modifying the DNS system to do re-directs from MX to URLs?
Account creation / ownership - How exactly would new accounts be forged. E-mail provides a simple mechanism whereby the account is provisioned once and announced any number of times. An RSS-based solution may need to actual repeat this for every unique combination. How will new relationships be forged? How greatly do we limit new and happenstance connections as a result of this potentially complex process? Who hosts this new account, the initial sender or the initial receiver? How do I even let them know I wish to send them something? Should I call them up first?
Forwarding / CC - Forwarding or copying a message to another party is quite simple with e-mail. This process becomes somewhat more convoluted, at least behind the scenes. There seems to be too much "paperwork" involved.
Threading - Grouping messages provides a context for understand the histroryof a conversation. It will be interesting to see if we turn to the comments seen in blogging as the reply machanism. This, of course, gets complicated in situations where multiple people are involved and notification is required.
These are just some preliminary observations on the subject. It will require some more investigation to see what solutions, if any, are being provided to these potential pitfalls.
This week, I hope to tackle the SPAM arguments that seem to increasingly fuel this movement.