“Wait,” you say, “there’s only one?” Well, no, but there is the one that irks me the most at this moment

I just watched Leisa Reichelt’s presentation on Ambient Intimacy at FoWA London and it started churning my gears about the things that drive me nuts in social networking apps. We’ll call this the Problem of Interconnectivity (or the lack thereof). I’ll snarkily refer to it as “One App To Rule Them All”.

I am not talking about just one social network app that everyone uses and refusing to publish to the rest of the world. Leisa said “People use different types of applications to facilitate different forms of communication…” and I believe that to be true. But there’s a lot of overlap between different applications, and I want a touch point by which I can manage those various applications with ease.

The Problem

I spend a lot of time contributing to various parts of the social graph: LastFM, Facebook, Twitter, Pownce, Upcoming, Flickr, Dopplr, TripIt etc. etc. Each site has its own login and password. Each site has it’s ups and downs. Some are great and some aren’t so great. But I use them all, and many of them have overlapping datasets. For example, Myspace, Pownce, Facebook, LastFM and Upcoming all have event objects. Dopplr and TripIt contain ancillary information about those events. Flickr later will have photos associated with those events.

This means that I end up with redundant and split-up data. Not just in the publishing of data from me to the sphere, but also via the manner in which that information is commented upon and how feedback returns to me. I don’t mind that it comes back to me in various ways, but it’s difficult to find that comment that was not in the normal pipeline six months after the fact.

The problem, at the core, is one of time—a lack of time. It takes an excessive amount of time to update all of these sites on a regular basis. And it requires that I visit each and every site in turn in order to enter the aforementioned data. That takes about five to ten minutes per site. Adding one event can take 30 minutes or more. Even if I’m bulk loading, I can easily drop a few hours doing data entry.

There has to be a better way.

The Pieces That Exist

There are a variety of technologies that could facilitate these things to come together.

1. OpenID | A distributed identity system that lets you use one login across many applications.
2. APIs (or Application Programming Interfaces) | These are tools created by the developer of the application that allow for other developers to create interactions with that application. The API is a concept and a series of things that can be done. What one does with them is entirely different.
3. DHTML | Dynamic HTML is basically made up of the DOM (Document Object Model), XHTML, CSS, and JavaScript. This is the base of the building blocks for interacting in new ways with the browser.
4. XMLHttpRequest | Also known as XHR, this is the core of AJAX, this allows for things to happen in the background while one continues to interact with the application.
5. AIR (Adobe Integrated Runtime) | A new technology from Adobe, this allows for people to build either AJAX, Flash, or Flex applications and deploy them across multiple platforms utilizing the AIR framework.
6. Ruby | The Ruby Language is a very easy to use and very powerful programming language. With ERB and some light Apache hacking, you can use this without having to install a full stack framework (such as Rails)

There are a variety of other protocols and technologies that could also be employed (such as Jabber) but due to my lack of experience with them, I’ll provide them only a cursory mention.

A Potential Solution

It’s easy to consume these streams after the data is input via RSS. A great example of merging multiple streams into one is Jeremy Keith’s creation of a collected stream on his site. So we’ve got the ability to pull multiple RSS feeds into one location and display them in a new manner. I’ll write a post in the future about doing this with some lightweight ERB.

But sending to each of the sites becomes a much larger endeavor. The API is a series of potential calls, not a plug-and-play piece of code. So even with some heavy lifting, you still have to manually identify the data fields in the models you wish to update on the remote server and make the proper calls. This is great and horrible in the same breath. The power of the API means that you can, in fact, push the data into the system (in most cases). It’s just a lot of work for little, if any, reward for the developer of said system.

The most obvious example of something that i have difficulty with in this arena is events. I play a lot of shows in my band. I also do a lot with various travel for work. So, I’d want to add a show and have it add a show at MySpace, an event at Facebook, an event at Upcoming.org, an event on Pownce, and update my Dopplr account that I’m going to be in that location.

Or how about a blast status update to Twitter, Myspace, AIM, Pownce, and Facebook? Information is only as relevant as the last post. And if it’s easy to distribute, a more complete view of communication exhibits itself.

I’m sure there are even more potential uses that I can’t envision myself and that is the beauty of the web in that people will use systems in new and unexpected ways.

Potential Pitfalls

Let’s call it out right now. Public enemy number one in this space? Spam.

Any system that lowers the barriers for the mass push of information very quickly enables the spam attack that everyone dreads. Spam, however, is subjective. I think 99% of us would agree that penis enlargement and “Get your free viagra now!!!” are a complete waste of time, effort, and electrons. But where is the deciding line? If I post a show to my network is that spam? If I post about a web conference is that somehow different? If I’m speaking is it more spam-related than if I’m just attending?

Another potential pitfall is asyncrhonicity. This could be planned for using something like Adobe’s AIR system and intentionally alowing the user to input massive amounts of data into a submission queue. When the user connects to a network, the application begins to sync up with various APIs in succession. So that could be a benefit over a pitfall, but covering user expectations would be very important. Does it sync automatically? Does I have to hit a button? Does it save previous syncs? What happens if there’s an error in the sync? What if I was really looking for a kitchen sink?

Truly. A potentially insurmountable obstacle. Especially the garbage disposal.

So what next?

Well, after writing this I happened to be reading MetaFilter and saw a post to NoseRub, which claims to be a decentralized social network protocol that lets you sync data between places. It appears to be more of an aggregator as opposed to a publisher as far as can see by reading their about section.

I’m going to chew on this and come up with some visual ideas of how this might work. How would you like to see this kind of application work? Is it even possible?