What I Need is a Universal Receptor Protocol
Have you ever grumbled that a particular application you use doesn’t work the way you want it to, or doesn’t have a specific feature you want?
Sure you have. I have too. Everyone has. But what makes coders and developers different is that they usually hunker down and implement the feature or fix the code themselves. Especially in the world of open source, whining for a new feature will just get you, at most, a derisive comment. You are expected to pull your own weight, get the ball rolling, and then people will join in to your effort.
That said, this post is going to be an unabashed whine for an essential tile that is missing in this blizzard of puzzle pieces called social media. And that piece I will call the universal receptor protocol.
APIs and Protocols
API stands for Application Programming Interface. Basically, an API answers the question, “I want to write something that can directly interface with this application, can I do that?”
I’ve touched on web applications with APIs in the past, such as RSSmeme. Not all web-based applications have an API, and often if they do they might be in a specific format that is somehow restrictive. For example, for years, America Online (AOL) had two ways you could use their instant messaging (IM) client, through their official client software, or using a 3rd party IM client that connected to their API implementation called Oscar. It was cool that AOL had an API for their closed system, but the Oscar system limited the 3rd party clients a lot.. it went down more often than the official interface, you couldn’t go invisible, etc.
More recently though, especially with the rise of standard feed protocols like RSS and ATOM, we are seeing more web-based applications opening up to allow third-party software to directly interface with it. Twitter is a great example, there are literally dozens if not hundreds of small web applications that work with Twitter data, either to abstract or analyze Twitter data or simply to give a Twitter user a nice desktop client.
A protocol doesn’t require there to be an existing application that one can interface too — it simply defines how to structure data or signals in a certain way so that two applications or nodes will be able to communicate. Communications protocols are usually developed to overcome a hurdles or unique constraints that can’t be overcome with existing technology. For example, a telephone modem (modulator-demodulator) was a piece of hardware that was specifically designed to send data over an essentially analog connection. It used a communications protocol to be able to talk to the modem on the other end, no matter what manufacturer made the other modem.
Push and Pull
Along with access to an interface and communications protocol, something that deserves consideration is how that communication between two points is initiated. Although you hardly ever see unidirectional communication anymore (see morse code and the original irda spec), how two systems get started talking to each other can make a big difference. Here is a summary of the two primary models:
- Pull Technology - This is what is used primarily in internet communication. In short, this is where the client or recipient system makes a request to the server system for data. That data is then served to the client. When you open a web browser and go to a web site, you are using a pull technology.
- Push Technology – You can probably guess that this is the opposite of the pull model. This is when the server, when it determines that there is data to be distributed to a client, will make a connection with the client and deliver it. A good example of this were the original digital pagers. They would register with a pager tower and then wait for a page to be delivered. Another example that came up a few days ago was the old pointcast news network.
On the surface it may not seem too important to worry about which one to use. If the pull model is used more, why not go with that? But the two models can make a big difference in user experience.
Just ask anyone who has owned a BlackBerry phone. Sure, they can pull email from a standard POP or IMAP account. But ask any executive.. the real magic happens when they are configured to have email pushed to them from the server.
Suddenly, there’s no 5-minute wait for a new email. The phone gets it when the server gets it.
For some, this small difference means everything. I am being completely serious.
The Universal Receptor Protocol
Writing a technology primer is fun, but let me get to the point of my issue. Currently, we have plenty of web applications for doing things like content aggregation, social bookmarking, feed reading and microblogging. The problem is, each one requires a separate login, and by and large live in their own little domain.
Of course, lifestreaming and aggregation sites are supposed to mitigate this, to an extent. And they do. The problem is that they, too, are in their own walled garden once the data is collected. Sure, they will give you a widget or pretty destination page, and if you are lucky, a rss feed. But without some work, it’s hard to get at that data. In other words, there’s usually no API.
What I wish for, if I could wish for such a thing, is a protocol has these elements (in no particular order):
- Based on push technology
- An extension of the RSS feed XML protocol
- Able to handle meta-information for everything RSS supports: text, hyperlinks, video, and mp3
- Additional meta support for comments, meta-aggregation (different posting types on the same topic), conversational threads, encapsulated email and trackbacks.
- Optional support for 2-way updating, in case the server involved handles conversations.
- An open standard so that both clients and and servers can support the protocol.
- .. basically everything your standard blog supports.
Why Not Use A Blog
Good question. A blog almost gets me there. However, here’s the high-level concept. I want a protocol that allows a client that can act as a universal lifestream, microblogging and social network synchronizer.
The beauty of working at the protocol level means that client can be as complex or as simple as people require — you could have a web, java, or 32-bit binary client. And you could potentially use logic on the client side as well.
Scenario
Lets say you use a client app. You have the app configured with your favorite sites, which the app didn’t know of specifically — you just put in the URL for them and it discovered support for the universal receptor protocol on the site. Once the sites were added, you were able to create a profile with avatar picture that got pushed back to those sites. You also set up logic so that quotes and pictures you bookmark go to one site, blog entries to a different site and bookmarks to two sites.
You leave the app running. During the day, it alerts you to new conversations from your friends and colleagues, new email, and new links. You are able to quickly reply to conversational threads and email from within the app.
When you are ready to move to a different system that does not have this app installed, you save your profile onto a flash drive. When you get to the new computer, you can hit a website that supports a significant percentage of the URP protocol, upload your profile and you are ready to go.
Ramifications
I’m sure there is a lot I haven’t thought of, and I welcome feedback. One thing I wanted to touch on was advertising, I’m not sure how the servers would push advertising if the client was so strongly enabled. Also, the push model means that the servers need to maintain a list of clients to send updates to. If a particular content server is really popular, this could cause a load on the server, keeping track of what needs to be pushed to which client.
I welcome discussion. Please join in and let me know if you think this is an interesting idea, or if I’m full of hot air.