One hoary truth of computing technology is that most of the pressing problems today have solutions discovered or developed, at least in part, twenty years ago. (This nicely avoids the patent problem.)
Google’s announcement of the OpenSocial API brought up yet again the persistent problem of walled gardens on the Internet, as myriad social networking sites spring up, offer to invite all of your friends if you divulge your address books, and then slowly wither as you realize that visiting half-a-dozen sites every day to read messages from your fragmented social groups is busy work.
Wouldn’t it be nice if all of these disparate messaging systems could interoperate?
Over the weekend I encountered a dusty old RFC written in 1982 that might solve this persnickety interoperability problem. Jon Postel’s Social Messaging Transport Protocol describes a system that relies on the combination of your unique identifier (username) on a social networking site with a unique identifier (domain name) for such site to produce an Internet-wide addressible identifier uniquely identifying, well, you. Given this unique identifier, any conformant messaging system can use this Messaging protocol to send you, well, a message.
Lest you fear such a system (a quarter century old!) is inextensible for the 21st century uses of zombie bites and pokes, the system builds on the tried-and-true HTTP style header/body distinction, where headers are simple key/value pairs that get ignored if unknown but offer plenty of ways to encode Gravatar or OpenID information, if necessary. (Admittedly, an extension of SMTP in RFC 2821 is only six years old, but provides further useful updates.)
The Social Messaging Transport Protocol enables the lovely store-and-forward behavior we’ve all come to expect from social networking sites, where you can send a friend a message and he or she does not have to be online to receive it. (Unfortunately, there is a flaw in the system; sending messages does not work if you are on an airplane. I can’t find a technical reason why it shouldn’t work, but I probably overlooked a MUST NOT in the RFC. One potential solution is for social networking sites to offer miniature versions of their sites that users could download and use directly while offline, but is that really easier than never traveling anywhere you don’t have broadband access?)
There are other tremendous benefits from adopting this ancient protocol for interoperability between social networking sites, but there is one drawback (besides the fact that you can never fly again): there’s a slight potential that you may receive unsolicited messages from people you don’t know. Fortunately, unsolicited commercial messages are almost unknown on all popular social networking sites thanks to the diligence and exemplary customer service shown by their operators.
A final benefit is worth noting. The Social Messaging Transport Protocol has a companion protocol revised most recently in RFC 3501, the Instant Messages, Advertisements, and Pokes protocol, which allows you again to use the unique identifier granted to you by a site with the site’s own domain name to login, view, and manage all messages held for you at the site. An IMAP widget could be embedded in any web page to allow you to check your messages from any web site.
(Imagine if we could solve the problem of local storage of data from Internet applications!)