I wasn’t very happy with where my last post ended. It all boiled down to “I wish Facebook was open source” or “I wish App.net had worked out better”. Part of that was that I spent the whole post operating on the assumption that underneath any application using this social network would be, well, 1 central model that everything would use. I think that assumption may be flawed. What if there wasn’t a central model behind all of these applications, but rather just a single protocol creating multiple models of people we connect to and how.
Here’s where I’m going with this – we have a lot of different interactions with different people, and sometimes different interactions with the same people. What determines the type of interaction, and if one is making a concerted effort not to spam their friends with crap, who we interact with is determined by the type and content of what we’re putting out there (either as original stuff or stuff that we’re merely passing along). Trying to do everything through 1 “true” social networking app just creates a very cluttered mess, instead of the simpler applications that focus on doing 1 thing really well. The reality is, we have different types of interactions with different people, and sometimes we have different types of interactions with the same individuals. Context and content make a huge difference in how social interactions should be handled, and that’s just not something you see in the current crop of one-size-fits-all applications out there now.
Instead, what we really need is an open protocol that can be used to model connections for lots of different (and different types of) applications, each with the ability to support their own data storage and state. In other words, instead of one central source of social networking truth, we need lots of them. In fact, we need different networks for different types of applications. In other words, 1 social network-backed application for shop talk with co-workers, another application with its own unique model for long, detailed conversation with friends, another for sharing pictures with families and friends, and yet another for simple status updates, another for article-style posts. All of these examples involve different types of activity, and use different social networks from each user. Right now, what we’re dealing with are applications that try to maintain all of their user’s social networks in 1 model, and try to perform all of our interactions. It’s a setup that makes it too easy to over-share or let stuff be seen by the wrong audience. And not only that, but you’ve got proprietary lock-in for all of your data as well.
On the other hand, an open protocol that supports a wide variety of applications, each with their own model of their users personal networks, gives us the option of having specialized applications for the types of interactions in question, opens up the possibility of several different applications each with their own take on the types of interactions in question, and a standard format for exporting user data between applications. In other words, create a profile in 1 application that uses this protocol, and you can just load that information into other applications, essentially keeping the existing single-sign many people use their current social networking app of choice for.
The real advantage of a 1-social-network-backed-application-to-rule-them-all setup is that there’s one place to check for any updates with all the members of all of your social networks. On the other hand, if this hypothetical open protocol communicated in an open, well-defined format that’s been around for a while, like…say…RSS, then checking on updates from all of your various social networks in one place is still feasible, just use your existing RSS reader. If you don’t have one, there’s plenty of good ones out there to choose from.
Just like with blogs, this architecture also distributes the models and data that social applications rely on. There wouldn’t be just 1 central model and data store, there would be different models and different data stores per application. In other words, you wouldn’t have to come up with a business model to pay for a massive, ever-growing hosting and data storage. All you really have to build and maintain is a code model for social networks, and an API for how data looks coming into and out of the model. An extendable protocol would let you leave data storage itself up to individual applications, just use the plugin that supports the database engine of your choice.
The issue here is that we actually have several social networks, depending on the context at hand. That context is determined by the nature of whatever it is we’re trying to say. Is it brief? How interested are we in getting a response? What types of responses do we want? Are we interested in a lot of back-and-forth after we’ve said what we want to say? Is what we want to communicate even mostly text in the first place? The best way to address these questions isn’t through a single universal application that does everything, but a bunch a little applications that fit the niches the content demands. With a universal, open protocol behind these applications, experimenting and switching applications is easy thanks to a model that supports data exporting. In fact, it should be entirely possible for individuals to communicate back-and-forth over the exact same content using completely different applications. We have a lot of different social networks in which we engage in a lot of different types of communication. It’s high time that we stopped trying to find ways to cram this all into 1 monster application and instead start operating under a philosophy of using the best application for the job.