After a lot of thinking a blogging aloud about what I think social networks are and what I think a social network (and social applications) should be, it’s time to revisit my original thoughts about a next-generation social network and see how well they stand up, as well as flesh out just what features a social network should support. After trying to get myself to separate the social network itself from the application people may be using to tap into their particular social networks, I wanted to re-visit how my original app idea and see what features should be moved to the actual network itself.
Still all RSS, all the time
I said in my original post that this hypothetical social networking application should output RSS. RSS has been around for a while, and has a well-defined schema. In fact, you can probably very easily find tutorials on how to build an RSS reader for just about any language out there. In other words, reading RSS is essentially a solved problem. In fact, there’s tons of RSS readers already out there being used by people all the time. With a social network that outputs content in RSS, it’s easy to get your updates all in 1 place, regardless of what application(s) using that underlying model you happen to subscribe to. RSS also gives you a standard format for outputting your data to other applications, which makes switching between applications or porting a subset of your data (say, some contacts or conversations) between applications easy.
Normally, for something with an open API like this, I’d prefer JSON, but something like RSS means that as soon as you have the social network in place you have a sea of clients out there (at least for reading updates) that are easy to install, if people aren’t using them already. As long as it’s possible to have a social network’s API spit out some form of RSS, it should.
Dynamic Visibility
This is important enough that it needs to be baked into the social network itself, not left up to applications. Social networks model your real-world connections, but it’s borderline impossible to predict all the possible subsets of those connections you’ll want, so this idea of just defining static lists for everything isn’t going to cut it. Don’t get me wrong, lists are still handy and should still be a feature, but initial visibility needs to be able to be defined by any arbitrary identifying criteria (such as people who work near a given location, people who are my in-laws, or people on my “Development” list and live near me). Defining who you want your initial post to be seen by shouldn’t require pre-planning and a tedious listing process.
1 of the pipe dreams I had for this network was the idea of distributing the data within the social network, essentially only giving part of your network to particular applications, but I don’t think that’s going to be a viable option. For dynamic visibility to be a viable feature, you’re going to need to have access to all of your connections and lists from any given app at any given time. In other words, all applications need full access to your full network (which raises some security concerns, as Warren has pointed out). All in all though, dynamic visibility is a good enough feature that it’s worth the security concerns.
Required topics
Honestly, this could probably be more of an app-level feature. It’s main purpose was to work with consumer-side filtering (more on that below), and it still probably can, but the network wouldn’t be “broken” without it.
Consumer-side filtering
Consumer-side filtering ranks right up there with dynamic visibility – it’s too important to making this a compelling, workable model to not have baked into the social network itself. The combination of dynamic visibility and consumer-side filtering are this social network idea’s answer to the noise level in social networking applications being so high they have to filter the content that you theoretically subscribed to receive. Given the ability, users are a lot better at pruning out noise than algorithms, and user filtering leads to a lot less user surprise which is good all around.
No upvoting
I still believe that upvoting is the primary driver for most of the noise on social networking applications today, so I believe that the concept of upvoting, in any form, shouldn’t be part of the underlying social networking model. There’s nothing stopping this from appearing in individual applications, but they wouldn’t be supported by the protocol itself.
No “discovery”
If you look at the main feeds in Facebook and Google+, they have recommended posts for users. You know, Facebook, that same company that actually hides stuff your “friends” and people/businesses you follow post because there’s so much crap coming through the feed, suggests posts utterly unrelated to your contacts in there (in addition to the ads). Twitter’s really the only social network that seems to the bringing in outside content thing right – limit it to stuff retweeted by people I follow. There’s already a problem of excessive noise on these networks, we shouldn’t be risking more when there’s perfectly valid content to be seen instead.
Not just a single project
Building a social network like this is really multiple projects, actually a lot of projects. First and foremost, is the social network itself, to model users’ real-life social networks and push content out amongst them. This social network should have an open API that everything built on top of it use. That API needs to be as well documented as anyone can think up, it needs to simple, and it needs to do everything you’d possibly want to do with a pure social network.
Another is at least 1 demo application running on top of this network as a proof of concept. This demo application should also be open-sourced so it can serve as a good set of code examples. Oh, didn’t I say “at least 1” sample application? There should also be something running on this social network early on that’s more than the basic social networking application (a.k.a the Facebook clone) to explore the possibilities of a social network not being tied to any sort of application.
Of course, this social network being an open protocol, that means an open API. And open APIs beg for libraries in various programming languages. That part would probably involve a lot of heavy community support, but anyone who’s setting out to build a social network like this should probably be as involved in as many of these libraries as possible. People would be putting a lot of time and effort into libraries that make building on this network easier, and they deserve support.
I think a project like this, while incredibly ambitious (i.e. difficult to get right), is entirely doable. You’re still faced with the daunting challenge of supporting such a venture, and getting a critical mass of people signed up, which is a massive undertaking all on its own. However, I think this network has the features needed to leap those hurdles once it can get some momentum. Of course, first things first, we need an open social network and the apps to run on them.