The web-wide social network

November 19, 2008

Ross Dawson has an excellent summary of a Gartner presentation on the Distributed Social Web by David Cearley. A web where each participant is their own central node on a web-wide social network.

It is the only natural conclusion of the vision of Data Portability.

It will be made possible by a series of futurists, technologists, philanthropists and engineers developing core building blocks like OpenID, oAuth, APML, PortableContacts, XMPP, RSS/ATOM, OPML, Microformats and more.

It will be commercialized by a series of entrepreneurial start ups with stars in their eyes running in and around the feet of the giants who are each fighting each other to keep up. Startups like JS-Kit.

It will be fueled by traditional and not so traditional media companies, steered by young, idealistic intrapraneurs, who are willing to take a bet in order to stake their claim on the next generation of social networking and human communication.

It will be monetized by a recognition that one can’t monetize word-of-mouth. Instead Attention will emerge as the ultimate way to measure, discover and interact with participants. See Faraday Media.

It will be popularized by bloggers, smart IT journalists and conference organizers who understand the importance of open over closed.

We have already started to see a preview of the world to come via the early attempts at rudimentary aggregators and proprietary data portability implementations. This is just the beginning of the beginning.

For a more details around the emerging trends, check out Ross’ post.

Chris Messina has posted a fantastic post on his blog about DataPortability. It is a real pleasure to read his thoughtful and well articulated questions, concerns and compliments about the project.

I am going to try to answer or comment on many of his comments below by quoting big chunks and including my ideas.

Contrary to what some folks have argued, I think that the semantics and meaning of the phrase “data portability” are important. To me data portability denotes the act of moving data from one place to another, and that the data should, therefore, be thought of like a physical thing, with physical properties.

So if you ask me what is “data portability”, I’ll concede that it’s a symbol for starting a conversation about what’s wrong with the state of social networks. Beyond that, I think there’s a great danger that, as a result of framing the current opportunity around “data portability”, the story that will get picked up and retold will be the about copying data between social networks, rather than the more compelling, more future-facing, and frankly more likely situation of data streaming from trusted brokered sources to downstream authorized consumers. But, I guess “copying” and “moving” data is easier to grasp conceptually, and so that’s what I think a lot of people will think when they hear the phrase. In any case, it gets the conversation started, and from there, where it goes, is anyone’s guess.

I do understand the concerns about names and the underlying meaning they convey. I do think, however, that the ship has sailed on the branding of the movement. We can call it Data Availability, Data Connectivity, Data Streaming, Data Accessibility or we can call it what everyone is already calling it – Data Portability. I think the nuance of meaning is probably one that only affects the technologists closest to the issue; not the broader audience we are trying to reach.

Also, we have long defined ‘portability’ as the ability to port the data or port the context in which the data is used. That is, use data from one application from within the context of another application.

Is it a perfect name? Probably not.

Is it worth diluting the conversation to stop and rename it? probably not.

Can the community live with it? I would argue they could. So we should probably move on.

OpenID, along with OAuth, microformats, RSS, OPML, RDF, APML and XMPP are all open and non-proprietary technologies — formats and protocols — that grace the DataPortability homepage. How they ended up on the homepage, or what selection criteria is used to pick them, is beyond me (for example, I would have added ATOM to the list). So the best way that I can describe the relationship between any of these technologies and DataPortability is that, at some point, the powers that be within the group decided to throw a logo on their homepage and add it to their “social software stack”.

I’m curious if, besides Atom, there are any other standards that community members would suggest as an addition to the list. Are there any on there that don’t belong there? Having discussed this topic for a long time now, I think that most people agree that each of those technologies listed have a place in the conversation. The final ‘stack’ however will be determined by the Technical Best Practice documents.

Beyond that, it should be noted that OpenID, OAuth, microformats et al have been in development for the last several years, and have been building up momentum and communities all on their own, without and prior to the existence of the DP initiative.

Agreed – this is a fact I constantly repeat to everyone I speak to – particularly in public forums and on podcasts. I don’t think, however, anyone can deny that the DataPortability project has accelerated the momentum and helped to propel the conversation into the mainstream. It is gratifying that many of the participants in each of these standards groups (particularly the groups that don’t have as much visibility as OpenID, Microformats or oAuth) are now participating in the DataPortability project as a way to promote their work to a broader audience.

In fact, the DP project really only got its start last November with an idea presented by Josh Patterson and Josh Lewis called WRFS, or the “Web Relational File System”. At the time, the WRFS was intended to serve as a “reference design” for describing how data portability should work and this was to serve as the foundation of the DP recommendations.

In January, after ongoing discussions, Josh decided that it would be best to spin WRFS off into its own project and started a separate mailing list, leaving DP to focus exclusively on evangelizing existing technologies and communities and, in the oft-repeated words of Chris Saad, to invent nothing new (a mantra inherited from the OAuth and microformats efforts).

This is actually not quite accurate. The DataPortability project was running in parallel to the work on WRFS. We invited the two Josh’s to bring their WRFS work into the DataPortability project and as it matured we spun it out again.

If you accept that DP is primarily a symbol for starting the conversation about transforming social networks from walled gardens into interoperating, seamful web services, then no, not really.

This is certainly where it starts – but I think it’s clear that the group has far more potential than that.

… DP does not speak for the community as a whole, for any specific social network (except, perhaps, MySpace), or for any individuals except those who publicly align themselves with the group.

This is also true – The DataPortability project speaks for itself and for the people who participate. There are thousands of people and vendors both large and small who have publicly supported the group and, by extension, given it some level of authority to consult on and develop best practices for the community.

So if the second risk is that an unrealistic, naive or incomplete model of privacy [coupled with a lack of effective enforcement mechanisms in the case of fraud or abuse] will be promoted by the DP group, the third risk is that groups or communities that are roped into the DP initiative may open themselves up to a latent social backlash should something go wrong with specific implementations of DataPortability best practices. Specifically, if the final privacy model demands certain approaches to user data, and companies or organizations go along with them by adopting the provided “social technology stack” (i.e. libraries offered that implement the DP data model), the technical implementation may be flawless, but if people’s data starts showing up in places where they didn’t expect it to, they may reject the whole notion of “data portability” and seek to retreat back to the days of “safe” walled gardens of today. And it may be that, because of the emphasis on specific technologies in the DP group’s propaganda, that brands like OpenID and OAuth will become associated with negative experiences, like downloadable .exes in email are today. It’s not a foregone conclusion in my mind that this future is inevitable, but it’s one that the individual groups affected should avoid at all costs, if only because of the significant progress we’ve made to date on our own, and it would be a shame if ignorance or lack of clear communication about the proper methods of adoption and implementation of these technologies lead people to blame the technology means instead of particular instances of its application.

Open standards are developed as building blocks. The DataPortability project is building something from them. If some of the standards groups would -for some reason – like their standard to be excluded from our recommendations then we would be happy to oblige.

Also, there are a lot of people from all over the world looking at, refining and experimenting with the best practices being developed. I think most would agree that ‘something could go wrong’ is not enough reason not to try working through the challenges to come up with something worthwhile.

What’s good about DataPortability?

I don’t want to just be a negative creep, so I do think that there is a silver lining to the DP initiative, which I mentioned earlier: it provides a token phrase that we can throw around to tease out some of the more gnarly issues involved in developing future social applications. It is about having a conversation.

While OpenID and OAuth have actual technology and implementations behind them, they also serve as symbols for having conversations about identity and authorization, respectively. Similarly, microformats helps us to think about lightweight semantic markup that we can embed in human-friendly web pages that are also compatible with today’s web browsers, and that additionally make those pages easier for machines to parse. And before these symbols, we had AJAX and Web 2.0, both of which, during their inception, were equally controversial and offensive to the folks who knew the details of the underlying technological innovation behind the terms but who also stood to lose their shamanic positions if simpler language were adopted as the conversations migrated into the mainstream.

Agreed. I have often used the example that DataPortability can and will do for open standards what Web 2.0 and AJAX did for CSS, Javascript and XML.

Now, is there a risk that we might lose some of the nuance and sophistication with which we data junkies and user-centric identity advocates communicate if we adopt a less precise term to describe the present trends towards interoperable social networks? Absolutely. But this also means that, as the phrase “data portability” makes its way into common conversation, people can begin to think about their social networking activities and what they take for granted (”Wait, you mean that I wouldn’t have to sign up for a new account on my friend’s social network just to send them a photo? Really?”), and to realize that the way things are today not only aren’t the way that they have to be, but that there is a better way for social applications to be designed, architected and presented, that give the enthusiasts and customers of these services greater choice and greater latitude to actually pick services that — what else? — serve them best!

So just as Firefox gave rise to a generation of web developers that take web standards much more seriously, and have in turn recognized and capitalized on the power of having a “rectangle” that actually behaves in a way that they expect (meaning that it fully complies with the standards as they’ve been defined), I think the next evolution of the social web is going to be one where we take certain things, like identity, like portable contact lists, like better and more consistent permissioning systems as givens, and as a result, will lead to much more interesting, more compelling, and, perhaps even more lucrative, uses of the open social web.

I obviously agree completely here.

It is clear with Chris’ great post, that the data portability conversation, and the DataPortability project has unearthed a fantastic set of questions and opportunities.

The Data Portability narrative, and the resulting questions that it posses, are precisely the tools that will encourage end users, developers, vendors and media to further investigating popular standards like OpenID and Microfomats, and dig deeper into more nascent standards like RDF, XRDS and APML.

The resulting acceleration in just six months has been phenomenal – I look forward to the next six months.

I’ve written more on this subject in my “Internal note of thanks” post.

In the last couple of weeks there have been a number of very positive steps forward for Data Portability in general and the DataPortability Project specifically.

These include wins by the OpenID Foundation, the IC report, the DataPortability Report and others.

A couple of trends, though, are causing me a little concern and may require a slight course correction before they spin out of control and fragment, rather than standardize, the ecosystem.

1. Tightly coupled OpenID Implementations

On Plaxo right now there is a ‘Sign in with YahooID’ button. This is effectively an OpenID login mechanism, except to remove the user experience complexity of OpenID, Plaxo has worked with Yahoo to make it easier by creating a direct relationship.

This seems antithetical to the promise of OpenID and could ultimately create another mess of tightly coupled vendor relationships that defeat the purpose of a single sign-on identity that any provider can provide and consume.

A more long term solution must be to improve the generic OpenID user experience or devise an education campaign to help users learn the new login process.

2. Google’s Social Graph API

While revealing an enormous usefulness in the existing XFN and FOAF data out on the web, Google’s Social Graph API also reveals a weakness in current XFN and FOAF implementations. Many users are not aware when XFN data is included around URLs they enter, much less when the URLs are marked as rel=me.

For example when Twitter asked me for my homepage, I didn’t understand that I was asserting a semantic link from Twitter to my blog that Google would later document and carve into stone as part of its implicit global social network in the sky.

As it stands, there is a real concern for user backlash as these APIs start being implemented and users find themselves presented with eerily accurate information about themselves magically appearing on websites without their ‘consent’.

Some sort of best practice text and/or iconography is required around fields that will be marked up with XFN – particularly if rel=me will be used to that users can make informed decisions about the type of data they provide and how it might be used. Perhaps even an opt out checkbox is appropriate.

This is probably a job for the Microformat community to dig into and solve. They should probably solve it quickly though.

3. OpenSocial++

As OpenSocial implementations role out, it’s becoming clear that there is no such thing as a pure OpenSocial container. Each container includes proprietary APIs and extensions that widget developers may choose to use.

Presumably these exist to differentiate each network and encourage developers to write enhanced apps for the environment.

The problem, though, is that developers need to write defensively for each custom API leading us to a place similar to browser compatibility hell. App developers will need to write and test their apps across every Container and will either have to hard code support for special APIs or keep their apps generic and ordinary.

Is this sustainable? Is there a better way?

If OpenSocial is going to be the Write Once, Deploy Many model for widgets, then the OpenSocial team at Google need to find a way to address this concern quickly.