An Open Social Network

Introduction

Facebook is a hit. Really, sites like Facebook have always been a hit.

However, the problem is summarized as "walled garden". Facebook has done more than any previous successful social web site to encourage people to develop features for their walled garden. But it is still owned by Facebook, and you only have a tiny number of software freedoms. Thus, innovation is truly limited.

There is a lot of excitement over distributed software. That is, software that runs independent and yet integrates well with each other. Git is a powerful distributed source code management tool, and very successful. The same could be applied to the social network scene.

The ideas below is probably not new. However, I think I see a few details that need to be exposed.

Overview

First, I will talk about why API is important, and what kind of API is ideal for such a distributed social network.

Then, I will talk about what the API must provide, and how it could provide it.

Next, I will address some implementation issues.

Finally, I will address market adoption strategies.

API and Distributed Software

Facts:

• API is how two separate processes communicate.
• There must always be a reference implementation for other implementations to build against.

Observations:

• Simple, clear API is easier to understand.
• The less that is needed to be said about the API, the better.
• Internet APIs build on HTTP do the best.
• We must not forget the human-program API, or User Interface.

Conclusion:

• The API for inter-process communication will be HTTP.
• Since many clients will not have a public IP address, there needs to be publicly HTTP-accessible distribution nodes.
• The clients will poll the central server for updates. A browser or an app can do this.
• There must be a reference implementation of the distribution node.

What does the API do?

• Identity: Universal, unique IDs. The ideal is the email address: you@yourdomain.com.
• Authentication: Figure out if the process trying to communicate with the distribution node actually represents who they claim to represent.
• Authorization: Nodes need not be open to access for anyone.
• Sharing: Alice can share information with Bob, but has full control over what kind of information.
• Content: Alice can create content, and classify content as "private", "for family", "for friends", "for business", or whatever categories she likes. We can use copyright law to protect people's content from abuse. We can also have a system of marking content's origins so that if Bob is allowed to see Alice's family information, he won't inadvertently share it outside of the circle she is comfortable sharing it with. We can also insert markers into the content that are not easily discoverable to allow ex post facto discovery of who compromised the data. We can use encryption to ensure that only those authorized to see content can see it.
• Facts: Facts about Alice are content that can be shared just like a post, picture, movie, etc...

Notes on encryption:

• If everyone has a public/private key pair, then content can be encrypted so that only specific people can read it.
• When Bob asks to see Alice's content:
  • Bob identifies himself to Alice's distribution node
  • Node and Bob authenticate each other.
  • Node checks if Bob is authorized to view the content.
  • Content is encrypted so only Bob can view it.
  • Content has markings added so that if Bob decides to share it without Alice's permission, Alice can trace who did the original sharing.
  • If Bob wants to share Alice's content with Charlie, and the content is not publicly available, he has to point Charlie to Alice's node, where Charlie needs to authenticate and authorize himself.

Implementation Issues

• Start with an API specification.
• Code up something that solves it.
• The solution must be cross-platform, able to run on anything that might be a server on the net.
• Open source development is critical here.

Authentication Process:

• Both parties need a server running. (To solve this, we can provide public nodes with the disclaimer that we don't do any sort of authentication of the people there.)
• The node stores the private key of the user in the most secure way possible. This is because if the key is lost, all the data is gone.
  • This means the user has to trust the node. That's why we allow people to setup their own nodes.
• The user has to first authenticate themselves with the node.
• When the user visits another site, all we have to show is that the node representing the user is authorized to do so, and that the user can demonstrate that he is authorized with the node.
• This is basically Kerberos for the net, or SSL with dual-authentication.
• This is a generally useful solution for almost everything.
• Unfortunately, I don't know that it is possible with today's technology. I imagine a plugin to Firefox could make everything work.

Basic features:

• Address book data. When Alice and Bob become friends, they can both see their contact info. Some contact info is private, or only accessible to certain groups of people, and thus not publicly available.
• Photo / Music / Video sharing: Alice can share her content with her groups of friends, family, and colleagues.
• Blogging
• Software Development: Alice can host her projects via SVN, Git, Mercurial, etc... with whatever bug systems and mailing lists she likes.
• Friend Discovery: Alice can ask Bob for his list of friends (that Bob wants to share with Alice or people in the groups Alice belongs to.) Alice can compare notes and discover new friends from each of the networks of her existing friends.
• Email: The system also supports email.
• Email 2: The system supports a form of email where only Alice's associates can send her email, and she doesn't receive it until she asks for it.
• Instant Messaging / Chat / Video Chat: The network could also host instant messaging and chat as well, but a similar mechanism.
• 3rd Party Apps: 3rd Party Apps could be permitted to access Alice's data with her permission. At the node level, the administrator can shut down certain apps, or only permit specific apps.
• Cloud Storage: The node could also store data for the user and be the user's primary cloud storage node.

Market Adoption

• Initially, build up a set of beta users. Ideally, these will be developers and administrators who run their own node and who can add their own features to their nodes.
• Establish a public node for those who don't have permission to use one of the private nodes and allow anyone to join.
• When people want to access private content, they need to join an existing node or establish their own nodes.
• Eventually, the power of the network will be seen, and lay people will join in.

Profit Model

How can one profit from building the initial software? I believe the network itself is more valuable than the work to build it, and this will be self-evident, particularly after more and more features are added to the nodes. At some point, you simply decide to setup a node rather than a new, independent website.