The key foundation set of constructs, web services and APIs to support when building the mesh - is the area of profiles, personas, friendships, relationships, social graphs and groups. It all starts with humans and every construct, element and component of the open social web we’re building has to do with people. So that’s I’m starting here.

Luckily for us- we have OpenID2, oAuth, FOAF and XFN/hCard as great starting points. And the new Social Graph APIs are now available to get us started building up portable social graphs.

Luckily for us - end-users are starting to become aware of their own ID rights, privacy and security. And the kinds of controls that THEY should be able to assert over their own data. Standards for access controls and privileges need to be established so as I move between systems or I opt in and allow others to move my profile, content and social graph data around - I have the ability to control who sees my data - and when.

That’s how DataPortability effects MY profile data.

Everyone needs to have their own personal pages, preferably one for their public persona and one for their private dashboard kind of interface. This started off in the blogosphere as the ‘About Me’ page. But now the Me page is more important than the blog page!

Nowadays folks love to share what’s going on with their digital lifestyles and they love to track what their friends are doing as well. Activity streams, rivers of people or News feeds all satisfy this craving. And services like Friendfeed are aggregating these ‘activity feeds’ across systems.

Groups is another area where humans interact and congregate. Call them message boards, mail lists or social network clubs, tribes or groups; Groups are a key construct of the open mesh and social web - especially when they can be used to connect people together ACROSS social networks. Aggregating Groups is gonna be the next Twitter or FriendFeed - real soon now.

This series of blog posts will make up the foundation of a white paper I’m working on about “How to build the mesh”. When I heard Ray Ozzie’s speech at Mix08 - I realized I could have been giving that same speech, but instead of giving the speech as the CTO of Microsoft, I’d present it as a strategy for the open web. My keynote would be focused on the independent software developers who wish to mesh together with both the huge behemoths out there like Google, Facebook, Microsoft, Yahoo and MySpace as well as the smaller players and independent developers like themselves.

Its crucial that the mesh leave room and provide ways for the small guys and gals to contribute and participate in their own way - while sharing common infrastructure, standards, namespaces, web services and open standards to normalize the eco-system.

But the only way that standards evolve is through the marketplace - like RSS.

So how do we resolve this push-pull conflict between proprietary standards that vendors establish versus open standards which no one owns, and non one entity controls? Some vendors - like Google and their OpenSocial efforts - have attempted to create a balance to this inherent conflict. The establishment of the OpenSoical foundation not only shows are serious they are at achieving interop and cross-vendor compatibility, but also provides a great balancing act of the behemoth we’re seeing forming in front of our eyes of Microsoft, Facebook and soon - Yahoo - all ganged together around semi-open affiliations of networks - like the Windows Live Contacts alliance.

Other organizations, like Dataportability.org and the IDCommons are advocates (sort of like hi-tech cheerleaders) rooting for the side of all things good and right to win out in the end. (Can you hear the soft sounds of Kum bah Yah off in the background?)

Ideally the mesh would have a DNS-like backbone available for of us to utilize which would connect to multiple copies of the same kind of server code (Twitter, Events, video streaming, etc.) sharing a single member database.

Ideally the mesh would have shared Ad servers (like OpenX) where anybody could access an inventory of ads and promotions to help monetize their site or services.

Ideally the mesh would enable content producers to route their content to a myriad of distribution points (we call that service - OutputThis.).

Ideally teh mesh would include one’s social graph which would be pooled and aggregated with all your friends friends, decoupling your social capital from the control of a single vendor. Brad Fitzpatrick and David Recordon talk about that - here.

Each chapter of this “how to…mesh” blog series will cover another unique aspect of the mesh, and the business models, cultural norms and politics involved with that area.

Each chapter will cover the open standards, open data and open source solutions available to implement the chapter’s domain and focus on dataportability and interoperability within the chapter area.

Each chapter will also look at the area leaders, the proprietary APIs and vendor based standards that are often formed by the marketplace and the mesh node points and anchors which make up the fabric of the domain.

The enemy to the mesh are closed platforms and systems which don’t allow the mesh to happen. The enemy are patents, DRM and other forms of ‘toll-gates’ which extract and exploit revenues - right out of our asses. The enemy is the old boys club, the VC cliques and exclusive clubs which attempt to run things behind closed doors, set up barriers of entry and ultimately lock-you-into the world of Web 1.0.

Here’s a rule of thumb. Whenever you see a coolio new construct, platform or service - which is available from a single source vendor - you’ve got problems.

Twitter would be perfect if there were 100 different, compatible Twitters, Pownces and Jaikus. MyBlogLog would be perfect if a back-end DNS united 25 different MyBlogLog clones. Same thing goes with IM (hurrah for Meebo!), music tastes (think Last.fm and iLike being compatible together), shared databases of events (Eventful, UpComing, ZVents and Renkoo all working together) and just about every other important construct in our world - being compatibile with their competition.

So locations, places and Geo related stuff (Dopplr, Plazes) and Reviews (Yelp, Aint-it-cool-news) will also be part of the mesh. Just about every on-line service around will eventually mesh into this distributed, loosely coupled architecture - which we’re figuring out how to build - right now.

Lock in is the enemy and the mesh will route around the closed systems and unite all the open meshed systems - together.

All of these principles and constructs are personified in the drawing below. It is the first of a series of puzzles pieces - which hopefully - when laid on top of each other will help solve the puzzle as to “how to build the mesh”.

The ID is at the center of everyone’s mesh.

Each persona (one can have multiple personas) has it’s own unique set of data, content and social graph. One can have friends (their social graph), be a member of one or more kind of Group, have a separate Contact list (for their email and IM), a whole bunch of stuff (media, widgets, feeds, links, comments, blog posts, interests) and keep track of all sorts of information - which I call collectively their ‘digital lifestyle‘ (”where I am, what I’m doing”.)

So then one connects to the system via their ID - both for signing onto a whole bunch of sites at the same time (federated single sign-on) as well as prove to the world - who they are and what their reputation/trust level - is. They connect to the world via two-ways APIs - so they can suck, as well as they can spit and they achieve interoperability and dataportability through a combination of closed proprietary APIs as well open standards APIs - as well.

The key thing to keep in mind is that one can maintain multiple personas - so just when you’re feeling conflict between whether you should be open or closed - just use the appropriate persona to decide which:

- avatar or image

- blog postings and voice - be it with video, audio or text

- set of friends, groups,

- personality to review, comment, rate, rant and seduce with

- access privileges, roles, administrative responsibility, power

- people you’ve granted permission to track, subscribe, opt in

So personas are for separating your digital life into manageable chunks - which can have their own separate settings, context, usage patterns, etc.

That’s how I see this domain called ID, Persona and Groups. I’ll probably be adding to this over time - and it’ll be linked up to a whole bunch of other domain posts.

Action Items in this area include:

- Group aggregation - connecting and collecting disparate groups (and members within those groups) across disparate networks

- standards for access and privileges controls - so when one defines who can see what - those controls are interpreted correctly by other networks

- opt in controls - so the end-user can control who can take their ‘data’ and move it somewhere else

- the pervasive notion of ‘multiple personas’ - so that one can maintain multiple sets of friends, content, etc. all within the ‘umbrella’ of a single account.

- DNS-like infrastructure - so that multiple copies of the same service - can share member databases

- and (of course) we need to continue to educate end-users on the importance of their control over their own data

Action Items in general include:

- make sure that ALL the open standards continue to rise in popularity, that all implementations are compatible with each other and that more open standards get created

- testing and compatibility labs - a place where we can guarantee that everything works together. Building a COMPATIBLE mesh will be a challenge - and it won’t ever happen if things break or don’t work.

- two-way APIs - until we can write back into systems and services as easily as we can get data from those services we won’t have a symmetrical architecture and a successful mesh environment

- establish OutputThis as a standard for content producers to list all of the destinations they’d like to route their content - to. SEE Dataportability.

Summary of open standards we have already:

- OpenID, OpenID2, oAuth, XFN, hCard, FOAF, OpenSocial, Social Graph APIs

Some leading proprietary APIs:

Facebook, MySpace, Bebo, Windows Live Contacts, Plaxo Pulse, Twitter, Pownce, FrendFeed

Major players and people to watch and listen to:

Kaliya Hamlin, David Recordon, Joseph Smarr, Dare Obasanjo, Doc Searls, Kim Cameron, Brad Fitzpatrick, Dick Hardt, Scott Kveton , Julian Bond, Dan Brickly, Tantek Celik, Phil Windley, Drummond Reed, Chris Messina, Andre Durand, Johannes Ernst, John Musser, Robert Scoble

Major organizations, events and advocacy groups:

DataPortability.org, OpenSocial Foundation, OpenID Foundation, DataSharingSummit, Internet Identity Workshops, Liberty Alliance, Higgins project, ID Commons, i-names, Jan Rain, Sxip Networks, Ping ID, DigitalIDWorld, Burton Group Catalyst

Final NOTE: I’ve been working on this for a while - and we’re about to ship a big system, so the follow-up posts may take a while - but I’ll get there!

This entry was posted on Friday, March 28th, 2008 at 10:19 pm and is filed under Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.