Metafluence

The 4Cs of the decentralized social network

At Ignite Portland, I made a public call to begin development of a decentralized social network (DSN). My principle assertion was that with an identity layer the blogosphere could be a DSN. This past Friday, I had the pleasure to join in a group discussion about the possible elements that could power that identity layer. We opened a can of worms that this blog post does not even come close to covering. I hope that this post will incite discussion, feedback, and action from those who read it (that means you :).

We had a few requirements that guided our thinking. The social network must be decentralized. Make the identity layer as thin as possible to allow for as much innovation on top of it as possible. It must integrate with the rest of the Internet’s protocols.

After some discussion, we believe we need three things for an identity layer:

1) ID database

Like domain names, each identity would need a unique value and would need to be maintained by a single authority. In order to maintain it’s decentralized requirement, we’d follow the logic of the OpenID project and use domain names. Not only is the domain name system already an established record for unique names, but they are also locations for the ID data itself.

2) ID data

Each ID would need a standardized structure for the ID’s contents such as a name, email, and address. We believe a standardized XML file would be the ideal format for structuring the ID data. We’re calling this standard Extensible Identification Markup Language (XIDML).

3) An authentication protocol

In order to provide ID information control (commonly referred to as privacy), the ID data would need an authentication protocol. We’re calling this the Identification Authentication Protocol (IDAP).

We believe a subscription model offers users the most control over the access to their information. A subscriber would start by requesting access to a user’s XIDML. Then, that user would approve or deny the request. If the user approved the request, they could select or create a contract with the subscriber that would control two things: 1) how much of the XIDML the subscriber can see, and 2) permissions for the user’s profile (such as whether or not the subscriber can see certain pages or leave comments on blog posts).

XIDML files would be served from a user’s ID, which means a person would need a domain name and hosting in order to participate on the identity network. We felt these requirements were reasonable given that a person needs a telephone and service in order to participate on the telephone network. We’re also confident that businesses would sprout up to offer ID hosting and provide the URL and hosting at no cost to the user (likely in exchange for the right to place ads on the user’s profile).

We concluded that with those pieces, developers would have the most freedom to create features around the 4Cs of the decentralized social network—Contacts, Contracts, Content, and Context.

Contacts

A user on the DSN can subscribe to the XIDML of other users on the network. This list of subscriptions would be similar to today’s contacts list with one major advantage: portability. Instead of keeping a redundant copy of someone’s contact information, you would have a feed. Anytime that person updated their information, the changes would be disseminated to all of that person’s subscribers.

Contracts

Because user’s need the ability to control access to their identity information, users would maintain contracts with their subscribers. A contract would provide a filtered set of data from one’s XIDML. For example, a person might allow a best friend to subscribe to all of the XIDML, but might only let a coworker see their name and email. The IDAP would ensure that the contract is being enforced by authenticating the subscriber.

A user could have saved contract templates to simplify the contract establishment process with subscribers. For example, a person could have “friend” as a contract that would allow someone to have access to

Content

In addition to providing a filtered XIDML, a contract could also define permissions for content outside of the scope of XIDML, such as XHTML files. For example, a user might maintain a blog at their ID URL. That user could create a contract with a subscriber that would define whether or not the subscriber could comment on posts or view private posts.

Context

Devices such us GPS enabled cell phones, can be context aware. If a user is in London, the cell phone could update their XIDML’s current location value. XIDML data could also be used to provide contextual information. For example, a user could pull up a map of restaurants that meets the dietary needs they list in their XIDML.

Additional Opportunities

Here are some opportunities that a DSN would create:

Contract manager

A contract manager might be a plugin for a WordPress blog that makes contract management simple. Lots of room for potential here.

Contact manager

Like a feed reader for contacts.

Contextual services

Location broadcasting, GPS triggered SMS alerts, proximity profile browsing, and more contextual services would be possible if we were all on the same social network.

ID directories

Like phone books of yesteryear.

ID hosting

Enabling the technically uninclined to have a simple sign-up service for their domain name and hosting pre-configured with a profile and contract manager would be big business.

Dynamic addressing

Instead of having a single phone number, email address, or IM handle a person could change that information regularly to prevent dropped subscribers from using old data.

In order for IDAP and IDML to have the highest adoption rate, I believe the best course of action would be to form a work group within the ISOC aimed at drafting an RFC that would later be ratified as a standard. RFCs that earn the distinction of standard are incorporated into a variety of products from routers to browsers.

Again, this post barely scratches the surface for the details that would need to be worked out in order to realize a DSN. Please tear theses ideas apart, suggest new ones, and share this with people you think would be interested in joining the discussion.

A big thanks goes out to Rob Neild who pulled together a meeting between Stephen Johnston, Kevin Tate, Keith Gerr, and myself. Perhaps Stephen will send me the photo the technologically challenged server took of all of us at Huber’s and then I can add it to this post. :)