User-centered storage, inspired by Twitter

I’m working this weekend on a little project inspired by Fred Wilson’s Blog Scrobbler. The idea is to keep a published record of blog posts that you view.

Pretty simple. But it’s got me thinking about a much bigger idea, which is starting to come into focus.

You see, even a few years ago this weekend’s project would entail setting up a dedicated server to hold the data, creating a web interface to display it, managing a user login/registration system, creating an API for accessing it, and much more. That’s hard.

But I can do the project in a weekend because Twitter has done all the work for me: it will be the “data bucket”. I don’t have to set up any servers or write any user registration systems. I just have to collect my little bits of data and ship it off to twitter where it will be stored and published for others to consume.

There is something profound about this.

Already, twitter itself is primary a storage and distribution system, NOT a website. People interact with it via numerous clients and phones. The fact that there is a web interface to view and enter tweets is not the selling point.

I see the possibility for a service that provides huge, generic, user data storage. Users could use any applications they like for adding data (like I use tinytwitter on my blackberry) or for viewing data (like I use tweetdeck on my laptop). Except that “statuses” would be only one of many types of data that could be stored and published: photos, posts, friend lists, song scrobbles, blog scrobbles, current weight, morale, classified listings, emails, etc.

Your hard drive for the web.

There could then be an ecosystem of services like gnip that continuously crawl this data and republish it for consumption by other services. New breeds of services could emerge from mining this data, in the same way the Summize creating a new type of search application by mining twitter’s data.

More importantly, this would allow a user to keep their data (or at least the gold-standard version of their data) in one place. Presently, using any web service means that your data is stored only on *their* servers. This means that your data is spread across, e.g. gmail for email, twitter for tweets, flickr for photos, zoho for docs, etc.

A geeky way to look at it is to again consider the MVC (model, view, controller) paradigm: Twitter provides a model (storage) for tweets, a simple view (the web or incoming sms), and controllers (web form or outgoing-sms). But twitter allows you to use other views and controllers (e.g. tinytwitter or tweetdeck).

If we can separate the storage of our data from the viewing and editing of it, more cool projects like this weekend’s “Blog Scrobbler” –and whole new breeds of companies– would be possible.