- the end of horror stories about accounts and company pages being shut down arbitrarily by Facebook
- privacy settings that give you fine-grained control, and that are not forcibly changed for you
- an ad-free viewing experience (depending on the policies of the node hosting your profile), and
- the easy implemention of desirable features in the interface, without waiting for a single company like Facebook to adopt them.
(Not to mention an interface that stays relatively stable until you decide you want to change it --
no more waking up to find out you've been "timelined".)
Consider the main things that we use Facebook for today:
- Finding old friends and re-establishing contact with them.
- Receiving a stream of updates from your friends, viewing photos, posting comments, etc.
- Creating events and inviting friends.
- Creating branded pages for your company or product that other people can "like," and receiving updates from pages created around other people's companies or products.
There's no particular reason why any one of those functions could only be carried out on a
centralized system. I can envision a distributed protocol with many different servers, or 'nodes,'
run by different hosting companies, and each 'node' can be used to store many accounts; users pick a hosting company and a node to create their new account, and their account on that node could be used to store their friends list, their photos and status
updates, and any events and groups that they had created.
I'll get to the protocol design in a second, but let me emphasize something more important first: to make the protocol censorship resistant, it would have to be possible to move your entire account from one node to another node at
a completely different company,
without breaking any of the existing links with friends, your events, etc. That way,
the node hosting your profile wouldn't be able to lean on you by saying, "Delete that one photo
you posted, or I'll delete your entire profile and you'll lose all the friend links and
events that you created."
To make a profile "seamlessly portable" in this manner, my suggestion would be to have the profile associated with a domain name owned by the user, with a URL like http://yourdomainname.com/profileprotocol/yourusername/. The domain name could be hosted with any hosting provider, as long as you paid their hosting fee (or as long as you were willing to display their advertisements to people who viewed your profile). But if your hosting company ever kicked you to the curb, you could simply change the domain name to point to a different hosting provider, and be back up and running after just a few hours of downtime (assuming you had backups of all of your data!).
No one would be able to shut down your profile permanently, unless they wrested control of your domain name away from you, or convinced every hosting provider in the world not to host you. (A user who didn't want to bother with their own domain name, could still host a profile under someone else's domain. This would probably be the default option for most casual high-school users, and thus companies like Facebook could still exist to serve them by helping them create new profile accounts in two minutes. But then those users would have to accept the risk that the domain name owner could shut their profile down.)
Thus I'm distinguishing here between two levels of censorship-resistance that could be provided by a distributed model. In the weaker type of censorship-resistance, profile-hosting companies would compete for your business by providing more permissive hosting policies, which would enable people to post edgier content than Facebook currently allows -- but once you're hosted with a given company, you couldn't easily switch without breaking all of the inbound "links" from your friends' accounts, so your hosting company could force you to self-censor, by threatening you with the loss of your account. In the stronger type of censorship-resistance that I'm advocating, you could switch seamlessly from one hosting provider to another, as long as you kept control of your domain name.
Of course this is exactly the type of "censorship resistance" enjoyed by people who run their own websites under their own domain names. The challenge would be to bring the same freedom to an open social networking protocol, but I see no technical reason why it couldn't be done.
Consider a protocol where "Bob" creates a new account on a social networking hosting node (together with a public/private key used to authenticate his actions to other nodes — if you're not a crypto geek, don't worry about that, it just means that users wouldn't be able to forge friend requests, "likes," event invites, etc. from other people). "Bob" could then find the profiles of his friends, and add them to his own "friends list" (which would be stored on his node). If Bob adds Alice as a friend, then Bob's node can also download Alice's current friend list (unless Alice has disabled this feature, or unless Alice has customized her friend list so that only portions of her friends list are viewable to other users — something not currently possible with Facebook). That way, when Bob searches for new names of users to add as friends in the future, the search will first default to searching the friends-of-friends lists that he's downloaded from his own friends.
When Bob signs in to his account on his node (either through a web interface, or a dedicated application, or a mobile app), his "news feed" consists of the comments, photos, and other items that have been published from his friends' accounts. He can post comments on any of his friends' items, which are then transmitted to his friends' accounts and stored on their node along with their content, unless they choose to delete the comments. And of course he can publish his own photos and status updates just like we all do on Facebook today, which would be downloaded to his friends' news feeds. (I'm hand-waving over whether the notifications would be "pulled" by users' nodes periodically polling the nodes of their friends to check for new content, or by their friends' nodes "pushing" the content to all known subscribers.)
Alice could meanwhile create an "group" of users would would be stored as an object on her node, and invite other users to join the group. Then any messages or content posted to the group would show up in the news feeds of all users who had joined. And Alice could create "events" which are also stored as an object on her node, and send out invites to her friends or other members of her groups. Pretty much any Facebook feature could be duplicated in this distributed system, with the benefit that users wouldn't run up against aggravating limitations imposed by Facebook — like the fact that Facebook used to block you from messaging the guests of your own event after it reached 5,000 attendees, and then removed the ability to message guests of an event entirely.
There's only one Facebook feature that I think could not be implemented on a distributed social networking protocol, and that's the practice of accruing hundreds of thousands of fans for your company fan page, basically as a form of "social proof" to show potential new customers that you're serious. Under Facebook's model, if you see a fan page with hundreds of thousands of fans, your first instinct is to assume that the company must be doing something right in order to be that popular, since Facebook makes it difficult for a company to create hundreds of thousands of fake users just to be fans of their product. On the other hand, in a distributed model, suppose I run across a company's fan page which claims to have 1 million fans. It's not just a case of the company lying about having 1 million fans — you could use digital signatures to verify that 1 million "users" really are "fans" of the product — but since anybody can set up a profile hosting node, you have no way of knowing how many of those 1 million "users" are real. "Acme Soda Company" could have just set up a dozen profile hosting nodes and created 100,000 fake users on each one, and have each of them sign up as "fans" of their product. (I just made up that company name, but this is incidentally something the real Acme Soda Company is apparently not doing.)
But how useful is it for regular users, after all, to see that a company has hundreds of thousands of fans? I've never assumed that a company makes a quality product just based on the number of Facebook fans that they have. I'd be more interested in checking out a company if a high proportion of my own social networking friends are fans of the product — and that is something that could still be implemented in a distributed model, since if a company claims that 3 of my 100 friends are fans of their page, I could use their digitally signed "fan" relationships to verify that this is true.
So I hope that the future of distributed social networking arrives soon. It may or may not be in the form of the Diaspora Project (in true Dr. Evil fashion, their most recent press release announced that they've already attracted "thousands" of users), but there's no particular reason that a distributed protocol would have to be a grass-roots effort. My guess is that if it took off, it would have to be started as a side project by an established company that gave it name recognition, and which could possibly provide free hosting for the first wave of users. Google+ never gave most people a compelling reason to switch, but imagine if it had been released not as a website but as an open protocol, complete with an open-source implementation that could be installed anywhere. Thus, complete freedom to create pages with whatever content you want, to amass as many fans and subscribers as you could legitimately earn, without having to worry about it all being controlled by a single entity who could mine your data or delete your content. I definitely would have given it a closer look.