Since it’s apparently all the rage to design your own features for Twitter now, I figured I’d build on my success with the hashtag and crank out a few more.

All of these are simple conventions for adding more standard metadata to a post in a specific, uniform way.

The Slasher

First, I’ve decided to migrate from encapsulating my metadata in parentheses to using a slash delimiter (“/”), which, for shits and giggles, we’ll call “the slasher”. This saves you ONE character, but hey, those singletons add up!

Now, the pointers. “Pointers” are short words with different intentions. A group of pointers should typically be prefixed by ONE slasher character. You can daisy-chain multiple pointer phrases together, padded on both sides with one whitespace character. There should be NO space following the slasher. Hashtags should be appended to the very end of a tweet, except when they are part of the content of the message itself and indicate some proper name or abbreviation. Normal words that would be part of the content of a tweet anyway SHOULD NOT be hashed.

If this doesn’t make sense yet, don’t worry, just read on.

Via

Let’s start with via, the first “pointer”.

The concept is simple and already widely used: sometimes you want to give credit to someone (as part of the pay-it-forward link economy) for something they said or linked to, without quoting them verbatim (which is what RT or “retweeting” is for, in my estimation and use). Now, a lot of people already use the “via” keyword — in fact, it’s a setting in Tweetie, and looks like this in practice:

My proposal is simple, but would look like this instead (note that there’s still no colon):

Saves you one character when used with the slasher delimiter and doesn’t look half bad.

CC

Next is cc — or “carbon copy” — not Creative Commons! Of course, if you ever used email this one should be obvious. The job of the CC is to indicate someone you want to direct a tweet at.

I follow 1600 people — and it’s highly unlikely I’m going to see everyone’s tweets — and I don’t really make an effort to do so. In the off-chance someone specifically wants to get my attention, they can just CC me, like I CC’d my friend Lauren in this tweet:

You’ll notice how, using the slash notation, you’re able to serially string together several pointer phrases: i.e. “/via @cshirky cc @laurendarby“.

By

The last one I’ll mention is by. As you can imagine, the “by” syntax is similar to “via” and “RT”, but not quite the same. It’s more like the cite or blockquote HTML tags in that they provide a simple way to attribute authorship for a longer-form piece — i.e. not from a status update or spoken utterance (that’s what RT and OH are for respectively).

Here, I’m quoting a passage by Dominiek ter Heide (@dominiek) that I took from a blog post that he wrote:

So, why bother writing these up? Well, I never expect that anyone will follow my lead, but if they do, I’d like to spell out what I’m doing so they can more or less get it right. It seemed to work with hashtags, and these ideas proposed here are even simpler. Now, you might not expect that, one, two, or three characters in tweets would make that much difference, but when you’re taking about a payload that maxes out at 140, each scintilla must carry its own significance. As such, there is value in coordinating our language, and providing some basic guidelines that emerge based on behavior — so that we can encode more meaning into these little blips of communication.

I’ve started tweeting using these patterns and invite you to do so as well when it makes sense. If you have your own ideas for microsyntax, Stowe Boyd started a wiki a while back to document them, so feel free to contribute your own or improve or use the ones already proposed!

I’ve probably said it before, and will say it again, and I’m also sure that I’m not the first, or the last to make this point, but I have yet to see an example of an open source design process that has worked.

Indeed, I’d go so far as to wager that “open source design” is an oxymoron. Design is far too personal, and too subjective, to be given over to the whims and outrageous fancies of anyone with eyeballs in their head.

Lately, I’m feeling the acute reality of this sentiment.

In 2005, I wrote about how I wanted to take an “open source” approach to the design of Flock by posting my mockups to Flickr and soliciting feedback. But that’s more about transparency than “open source”. And I think there’s a big difference between the two that’s often missed, forgotten or ignored altogether: one refers to process, the other refers to governance.

Design can be executed using secretive or transparent processes; it really can’t be “open” because it can’t be evaluated in same way “open source” projects evaluate contributions, where solutions compete on the basis of meritocratic and objective measures. Design is sublime, primal, and intuitive and needs consistency to succeed. Open source code, in contrast, can have many authors and be improved incrementally. Design — visual, interactive or conceptual — requires unity; piecemeal solutions feel disjointed, uncomfortable and obvious when end up in shipping product.

Luke Wroblewski is an interaction designer. He recently made an observation about “openness” that really resonated with me:

I read this quote last week and realized it is symptomatic of a common assertion that in technology (and especially the Web) “completely open” is better than “controlled”.

“But we’ll all know exactly where Apple stands – jealously guarding control of their users [...] And that’s not what Apple should be about.” -TechCrunch

Sorry but Apple makes their entire living by tightly controlling the experience of their customers. It’s why everyone praises their designs. From top to bottom, hardware to software -you get an integrated experience. Without this control, Apple could not be what it is today.

He followed up with a post on Facebook’s design process today that I also found exceedingly compelling.

I worry about Mozilla in this respect — and all open source projects that cater to the visible and vocal, ignoring the silent or unengaged majority.

I worry about OpenID similarly — an initiative that will be essential for the future of the social web and yet is hampered by user experience issues because of an attachment to fleeting principles like “freedom” and “individual choice”. Sigh.

I’m not alone in these concerns.

When it comes to open source and design, design — and human factors, more generally — cannot play second fiddle to engineering. But far too often it seems that that’s the case.

And it shouldn’t be.

More often there should be a design dictator that enters into a situation, takes stock of the set of problems that people (read: end users) are facing, and then addresses them through observation, skill, intuition, and drive. You can evaluate their output with surveys, heuristics, and user studies, but without their vision, execution, and insane devotion to see through making it happen, you’ll never see shit get done right.

As Luke says, Most people out there prefer a great experience over complete openness.

I concur. And I think it’s critical that “open source” advocates (myself included) keep that at top of mind.

. . .

I will say this: I’m an advocate for open source and open standards because I believe that open ecosystems — i.e. those with low barriers to entry (low startup costs; low friction to launch; public infrastructure for sustaining productivity) — are essential for competition at the level of user experience.

It may seem paradoxical, but open systems in which secretive design processes are used can result in better solutions, overall.

Thus when I talk about openness, I really mean openness from an economic/competitive perspective.

. . .

Early today I needed access to a client’s internal wiki. Having gone without access for a week, I decided to toss up a project on Basecamp to get things started.

When I presented my solution to the team, I was told that we needed to use something open source that could be hosted on their servers. Somewhat taken aback, I suggested Basecamp was the best tool for the job given our approaching deadline..

“No, no, that won’t do,” was the message I got. “Has to be open source. Self-hosted.”

I asked them for alternatives. “PHProjekt“. Double Choco Latte. I proposed Open Atrium.

Once again, as seems all too common lately, more time was devoted to picking a tool rather than producing solutions. More meta than meat. Worst of all, religion was in the driver’s seat, rather than reality. Where was that open source pragmatism I’d heard so much about?

Anyway, not how I want to begin a design process.

Ultimately, I got the access I needed — to MediaWiki. So, warts and all, we’ll be using that to collaborate. On a closed intranet.

In the back of my head, I can’t help but fear that the tools used for design collaboration bleed into the output. To my eyes, MediaWiki isn’t a flavor that I want stirred into the pot. And it begs the question once and for all: what good can “open source” bring to design if the only result is the product of committee dictate?

If you’re not familiar with Jelly, you should be. I call it the “gateway drug to coworking” — but it really has its own culture and identity independent of coworking, though both movements are rather complementary. Amit Gupta got Jelly started at House 2.0 in New York City back in 2006 (about two months after I initially expressed my desire to create a coworking space in San Francisco). Since then, like coworking, it’s grown into a self-sustaining movement.

Jelly! Talks is an interesting expansion on the concept — where Jellies distributed throughout the world can tune in to hear interesting and relevant talks and interact with speakers, similar to what the 37 Signals guys do with their “Live” show.

This first show I’ll be talking with Dave Morin about the relationship between OpenID and Facebook Connect — and where the two technologies are headed. This should be a pretty interesting conversation, since I’ve long tried to convince the folks at Facebook to adopt OpenID and other elements of the Open Stack (hey, they’ve got hcard already!).

Apparently the event is physically booked up, but you’ll still be to tune in remotely this Friday at 11am PST.

(Tip: The next Jelly! Talk will feature Guy Kawasaki).

For example, OAuth is a core aspect of DiSo because it enables site-to-site permissioning and safer data access. It’s not because of the DiSo Project that OAuth exists, but my involvement in the protocol certainly stems from the goals that I have with DiSo. Similarly, Portable Contacts emerged (among other things) as a response to Microsoft’s “beautiful fucking snowflake” contacts API, but it will be a core component of our efforts to distribute and decentralize social networking. And meanwhile, OpenID has had momentum and a following all its own, and yet it too fits into the DiSo model in my head, as a cornerstone technology on which much of the rest relies.

Tonight I gave a talk specifically about activity streams. I’ve talked about them before, and I’ve written about them as well. But I think things started to click tonight for people for some reason. Maybe it was the introduction of the mocked up interface above (thanks Jyri!) that shows how you could consume activities based on human-readable content types, rather than by the service name on which they were produced. Maybe it was providing a narrative that illustrated how these various discreet and abstract technologies can add up to something rather sensible and desirable (and looks familiar, thanks to Facebook Connect).

In any case, I won’t overstate my point, but I think the work that we’ve been doing is going to start accelerating in 2009, and that the activity streams project, like OAuth before, will begin to grow legs.

And if I haven’t made it clear what I’m talking about, well, we’re starting with an assumption that activities (like the ones in Facebook’s newsfeed and that make up the bulk of FriendFeed’s content) are kind of like the synaptic electrical impulses that make social networking work. Consider that people probably read more Twitter content these days than they do conventional blog posts — if only because, with so much more content out there, we need more smaller bite-sized chunks of information in order to cope.

So starting there, we need to look at what it would take to recreate efficient and compelling interfaces for activity streams like we’re used to on FriendFeed and Facebook, but without the benefit of having ever seen any of the services before. I call this the “zero knowledge test”. Let me elaborate.

When I say “without the benefit of having ever seen”, I primarily mean from a programmatic standpoint. In other words, what would it take to be able to deliver an equivalent experience to FriendFeed without hardcoding support for only a few of the more popular services (FriendFeed currently supports 59 out of the thousands of candidate sites out there)? What would we need in a format to be able to join, group, de-dupe, and coalesce individual activities and otherwise make the resulting output look human readable?

Our approach so far has been to research and document what’s already out there (taking a hint from the microformats process). We’ve then begun to specify different approaches to solving this problem, from machine tags to microformats to extending ATOM (or perhaps RSS?).

Of course, we really just need to start writing some code. But fortunately with products like Motion in the wild and plugins like Action Stream, we at least have something to start with. Now it’s just a matter of rinse, wash and repeat.

I am honored to be a recipient of this year’s Google O’Reilly Open Source Award for being the “best community amplifier” for my work with the microformats, Spread Firefox and BarCamp communities! (See the original call for nominations).

Inexplicably I was absent when they handed out the award, hanging out with folks at a Python/Django/jQuery drinkup down the street, but I’m humbled all the same… especially since I work on a day to day basis with such high caliber and incredible people without whom none of these projects would exist, would not have found success, and most importantly, would never have ever mattered in the first place.

Also thanks to @bmevans, @TheRazorBlade, @kveton, @anandiyer, @donpdonp, @dylanjfield, @bytebot, @mtrichardson, @galoppini for your tweets of congratulations!

And our work continues. So lucky we are, to have such good work, and such good people to work with.

My buddies John McCrea, Joseph Smarr have started up a show called The Social Web and have released the pilot episode, featuring David Recordon on the hubbub between Google and Facebook following last week’s Supernova Conference.

As they point out, things are changing and happening so fast in the industry that a show like this, that cuts through the FUD and marketing hype is really necessary. I hope to participate in future episodes — and would love to hear suggestions or recommendations for topics or guests for upcoming episodes.

Here’s the FriendFeed room Dave mentioned.

What us kids didn’t know at the time was that we were suffering from a platform war, that manifested, more or less, in the form of a standards war for the domination of the post-Atari video game market. We certainly didn’t get why Nintendo games didn’t work on Sega systems, they just didn’t, and so we coped, mostly by not going over to the kid’s house who had Sega. No doubt, friendships were made — and destroyed — on the basis of which console you had, and on how many games you had for the preferred platform. Indeed, the kids with the richest parents got a pass, since they simply had every known system and could play anyone’s games, making them by default, super popular (in other words, it was good to be able to afford to ignore the standards war altogether).

Fast-forward 10 years and we’re on the cusp of a new standards war, where the players and stakes have changed considerably but the nature of warfare has remained much the same as Hal R. Varian and Carl Shapiro described in Information Rules in 1999. But the casualties, as before, will likely be the consumers, customers and patrons of the technologies in question. So, while we can learn much from history about how to fight the war, I think that, for the sake of the web and for web citizens generally, this coming war can be avoided, and that, perhaps, it should be.

What I’m talking about, of course, is the seemingly inevitable duopoly between Google’s OpenSocial and Facebook’s F8 platforms. Patrick Chanezon, Google’s API evangelist, even went so far to claim that Google is following Chapter 8 and Facebook is following Chapter 9 of Information Rules, suggesting that Google is taking a “Cooperation and Compatibility” approach, while Facebook is seeking to incite a full-fledged standards war:

…having read these two chapters now, I’m not sure things are so cut and dry, and it’s worth taking the time to consider how the rhetoric on both sides maps to the various tactics and strategies outlined in the book (co-authored, mind you, by Google’s Chief Economist).

But look, I’m not going to bore you with all the details. I am, however, going try to put this current situation into some perspective, and suggest a way of moving forward.

Of the browser wars of 1996, Business Week wrote (talking about Bill Clinton):

That the contest caught even the President’s eye underscores just how seminal it is: This battle is for nothing less than the soul of the Internet.

Thus if the spoils of desktop browser wars was the soul of the Internet, then the coming war will be for the soft, pliant heart of the social web; it all comes down to distribution and sticky eyeballs synapsed to clicky-clicky fingers over which advertisers and their kin salivate and jerk off. No kidding.

Back in ’96 (when I was 15), you “provided” distribution by selling certain default real estate in your browser (how do you think Flock keeps managing to raise more money?). This is one reason why the Netscape vs. Internet Explorer war mattered so much — and why the Justice Department intervention decoupling IE from the operating system was so critical. It’s also why Mozilla has been able to amass a warchest (on the order of $50M) by keeping Google in the search “pole position” (and it’s also one compelling reason why Yahoo! might acquire an app like Inquisitor). Regardless, back in Web 1.0, browser distribution models were where it was at. But now that we’ve achieved cross-platform web standards support, generic feature parity (i.e. tabs, popup blocking), have reduced switching costs to nil, and, most importantly, brought about a generation of web surfers that connect to the web through all kinds of systems other than their own, the browser has been summarily reduced to a means to an end — an end which is commonly and increasingly some kind of social network.

Therefore, the endgame here is in setting the priorities that will be represented, through architecture and application design, and running code, in the social platform(s) of the [near] future, and in who can sell the most convincing version of the story that their platform will provide the greatest ROI for the least investment, given current sunk costs, and access to the widest number of [qualified] individuals, networks and relationships.

Look at how Kevin Marks (a good friend of mine) describes the opportunity for Friend Connect:

For OpenSocial application developers, this gives you a whole new audience for your apps, beyond the hundreds of millions of users on existing social networks that support OpenSocial.

Then consider what Patrick Chanezon (whom I recently met) said, when interviewed by none-other-than Inside Facebook (emphasis indicates interviewer question):

Patrick, what new trends stand out to you at this juncture for OpenSocial?

We’re still very early. Now that OpenSocial is reaching 200 million users, we’re starting to see a lot more people ask how they can be involved.

Meanwhile, Facebook promises much the same:

Yet, unlike Google, which has focused on an almost exclusively developer-centric message to buffer their lack of clarity around user privacy, Facebook has revealed its conflicts of intention between serving its advertisers while awkwardly protecting the interests of its users, regularly alternating press releases about advertiser benefits followed by improved privacy protections. Not that Facebook should have it all figured out, but this waffling only reveals what’s at stake here, and what’s driving the priorities of both platforms — Google has merely drowned out their plans to monetize the OpenSocial platform with developer-friendly messages.

Taking pages literally from Information Rules, both parties are employing preemption and expectation management strategies:

The logic of preemption is straightforward: build an early lead, so positive feedback works for you and against your rival. The same principle applies in markets with strong learning-by-doing: the first firm to gain significant experience will have lower costs and can pull even farther ahead. Either way, the trick is to exploit positive feedback. …

One way to preempt is simply to be first to market. Product development and design skills can be critical to gaining a first-mover advantage. But watch out: early introduction can also entail compromises in quality and a greater risk of bugs, either of which can doom your product.

Remind you of the notoriously capricious (but first-to-market) Facebook platform?

Meanwhile, on expectations management:

…Vaporware is a classic tactic aimed at influencing expectations: announce an upcoming product so as to freeze your rival’s sales. …

The most direct way to manage expectations is by assembling allies and making grand claims about your product’s current or future popularity. Sun has been highly visible in gathering allies in support of Java, including taking out full-page advertisements listing the companies in the Java coalition, showing how important expectations management is in markets with strong network externalities…

Take a look at Google’s OpenSocial presentations: fraught with logos and partner names (see slide 1 and slides 15-16 for recent examples of this kind of posturing). Classic expectations management.

And so we can see where this is going: companies, groups and individuals wanting to build social applications (and not invest in their own social graph) are essentially beholden to the platform decisions of Google and Facebook. If the two parties can’t figure out how to pick up the phone and talk, we’re going to have two competing platforms, both jockeying for developer attention, and forcing competition for the market, rather than competing within it. With everything that I know and have seen on the web (and while competition is typically good) this kind of fragmentation, generally, seems bad to me, primarily for the customers of these networks, who really don’t (and shouldnt have to) care which standard wins out in the end.

Unfortunately, it comes down to ego. In fact, Information Rules addresses with this kind of situation directly, advising against fragmentation in favor of increasing the size of the overall market:

Before you engage in a standards battle, try to negotiate a truce and form an alliance with your would-be rival. An agreed-upon standard may lead to a far bigger overall market, making for a larger pie that you can split with your partners. Don’t be proud; be prepared to cut a deal even with your most bitter enemy.

Can Google and Facebook come to grips on this? Well, I think they’d better, before Microsoft scoops up Yahoo (which already pledged to support OpenSocial) and makes moves on Facebook. Let’s face it, while it looks like Microsoft is just playing with itself with its Mesh platform, it needs a little soylent juju to get traction and marketshare to advance its ad system (which, by the way, is what powers Facebook ads). If Facebook and Yahoo both support OpenSocial, regardless of what the spec looks like, that’s bad news for lock-in bent Microsoft, and good news for the web.

So call me whacked, but here’s what I think should happen in my next-three-months pipe dream:

1. Google should reach out to Facebook. And vice-versa. Preferably simultaneously to reduce any unseemly appearance of capitulation. Facebook should realize that fighting a standards war with Google isn’t really going to benefit them long term. Meanwhile, Google should recognize the value that Facebook’s interaction patterns would bring to OpenSocial, along with the value of reducing developer headaches in having to pick between one or other if resources aren’t available to build for both.
2. Facebook should contribute a specification for handling “dynamic privacy” that promotes the interests of its members (and which should work for individual web citizens at large), beyond the flimsy, misleading and unclear privacy model currently being promoted under the aegis of Friend Connect. Presuming it’s good, adopting Facebook’s “dynamic privacy” spec should be Facebook’s top requirement for agreeing to adopt OpenSocial. (And heck, Facebook ends up looking like a good guy for agreeing to play along while not selling out the interests of its members.)
3. OpenSocial and the Facebook platform specs and (related IPR) should be assigned to an independent third party foundation, probably other than the OpenSocial Foundation (given its proximity to Google), whose sole obligation would be to steward specifications of the open [social] web.
4. Develop interoperable standards, formats and protocols so that 1) applications could be run within Facebook, OpenSocial containers, and on any independent website and that 2) data would be accessible from any of these network providers, using a secure model where the owner of said data determines how their data may be used, who may see it and for how long.

It’s not that we’re far off from this reality, but it will require the concerted effort of a few choice and able individuals within these organizations to make this happen. I believe that, with proper perspective, those agents of change who are already active in building out the future platforms of the social web can grasp the seriousness of the situation and, again, informed by history, will ultimately do the right thing, given the possible alternatives. We’ve made too much progress in the past year to let this opportunity slip out of reach owing to the egos or perceived short term economic benefits to be had by competing for dominance of the social web. It is much better for the health of the overall environment and ecosystem for standards to be set web-wide, and for competition to occur within the marketplace.

Moreover, competing for market domination (where there can only be one) like we saw with Sega and Nintendo will primarily harm the customers of social web services. It is therefore my contention (and wish) that competition be focused on providing higher caliber services and products rather than on the length of the tether used to keep people tied to one network. Condensing and combining the OpenSocial and Facebook platform specifications will take work, vision and compromise, but is ultimately the only way we can avoid what would amount to a costly, unnecessary and unfortunate 10 year standards war where no winner would likely ever emerge.

Over the last several days I’ve started and abandoned four drafts of this post. Usually it doesn’t take me this long to write out my thoughts, or to go through so many different approaches, but I wanted to express myself as clearly as I could given the amount and overlapping texture of what I wanted to say. I ended up gutting a lot, and tried to focus on some basics, making as few assumptions about the reader (you) as possible.

The reality is that I’m eyeballs-deep in this stuff, and realized that in earlier drafts, I had included a lot of subtext that just wasn’t helping me get my message across and that really only made sense to other folks similarly in the thick of it.

So I got rid of the subterfuge and divided this up into four sections, inspired by a conversation I had with Brynn.

I encourage and invite feedback, but I would prefer to discuss the substance of what I’m arguing, rather than focusing on tit-for-tat squabbly disagreements.

1. What is data portability?
2. How does DataPortability (DP) relate to OpenID?
3. Are there risks associated with DataPortability?
4. What’s good about DataPortability?

What is data portability?

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.

Let me draw an analogy here to illustrate the problem with this model.

Take an iPod. With an iPod, you literally copy files from one device to another — for example, from your laptop to your iPod. This is, on the one hand, a limitation imposed by a lack of connectivity and restrictions in copyright law, but on the other, is actually by design. This scenario is not altogether unmanageable unless you have dozens of iPods that you want to sync up with your music, especially if you don’t typically think to connect your iPod every time you add new music, create new playlists or otherwise change your music library.

Now take an always-connected player, like Pandora Mobile, where the model works by federating continuous access from a central source — to consuming devices that play back music. Ignoring the DMCA restrictions that make it impossible for Pandora to let you listen to what you want on demand, the point is that, rather than making numerous copies across many unaffiliated and disconnected devices, Pandora affords a consistent experience and uniform access by streaming live data to any device that is authorized (and is online).

The former model (the iPod) is what you might call the “desktop model of data portability”. Certainly you can copy your data and take it with you, but it doesn’t reflect a model where always-on connectivity is assumed, which is the situation with online social networks. The offline model works well for physical devices that don’t require an internet connection to function — but it is a model that fails for services like Pandora, that requires connectivity, and whose value derives from ready access to up-to-date and current information, streamed and accessible from anywhere (well, except in Canada).

It’s nuance, but it’s critical to conceptualizing the value and import of this shift, and it’s nuance which I think is often left out of the explanation of “DataPortability” (whose official definition is the option to share or move your personal data between trusted applications and vendors (emphasis added)). In my mind, when the arena of application is the open, always-on, hyper-connected web, constructing best practices using an offline model of data is fraught with fundamental problems and distractions and is ultimately destined to fail, since the phrase is immediately obsolete, unable to capture in its essence contemporary developments in the cloud concept of computing (which consists of follow-your-nose URIs and URLs rather than discreet harddrives), and in the move towards push-based subscription models that are real-time and addressable.

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.

How does DataPortability (DP) relate to OpenID?

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”.

To reiterate (and I won’t speak for the OpenID Foundation since I’m unfamiliar with any conversations that they might have had with DP), no one necessarily asked if it would be okay to put the OAuth or microformats logos on the homepage of DP, or to include those technologies in the DP stack. They just did it. It wasn’t like DP had been around for awhile with a mandate to develop best practices for the future of social networks, and groups like the microformats community petitioned or was nominated to be included. They simply were. There was no process, as far as I’m aware, as to what was included, and what was not.

So while OpenID and the other technologies may be part of the technologies recommended by DP, it should be known that there really is no official relationship between these efforts and DP (though it is true that many members of each group coordinate, meet and discuss related topics, for example, at tomorrow’s Internet Identity Workshop, and at events like the Data Sharing Summit).

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. 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).

Are there risks associated with DataPortability?

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. If you believe or buy into the hype, or blindly follow the forthcoming “technical specifications“, I see significant risks that need to addressed.

First, 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. On too many occasions to feel comfortable about, I’ve seen or read members of the DP project claim authority far beyond any reasonable mandate, which to me have read like attempts to seize control and influence that not only isn’t justified, but that shouldn’t be ascribed to any individual or organization. I worry that this hubris (conceivably a result of proximity to certain A-Listers) is leading them to take more credit than they’re due, and in consequence, folks interested but previously uninitiated with any of the core technologies will be lead to believe that the DataPortability group is responsible and in control of those technologies. Furthermore, if it is the case that people are mislead, I have little faith that folks from the DP project will prevent themselves from speaking on behalf of (or pseudo-knowledgeably about) those technologies, leading to confusion and potential damage.

Second, I have a great deal of concern about the experiences and priorities that are playing into the group’s approach to privacy, security, publicity and disclosure. These are concerns that I would have with any effort that aims to bridge different social or commercial contexts where norms and expectations have already been established, and where there exists few examples (apart from Beacon) of how people actually respond to semi-automatic social network cross-fertilization. Not that privacy isn’t a hot topic on the DP mailing lists, it’s just that statements like this one reflects fishtailing in the definition and approach to privacy from a leader of the group, and that I worry could skid wildly out of control if clarity on how to achieve these dictims isn’t developed very soon:

The thing is that while Privacy is certainly important, in the end these are *social* platforms. By definition they are about sharing. The problem with Facebook Beacon was not that it was sharing, but rather it was sharing the WRONG information in the WRONG way.

Also again, don’t forget, just because data is portable or accessible does NOT mean it is public or ‘open’. This is why I stayed away from the ‘Open Data’ terminology when thinking up DataPortability. Just like a Hard Drive and a PC that runs certain applications, ultimately the applications that USE the data that need to ensure they treat the data with respect – or users will simply stop using them.

[. . .]

You are right that DP should NOT be positioned that Privacy is not important – that is certainly not my intention with my answers. But being important and being a major sticking point is two different things.

Again I tend to think of this as one big Hard Disk. While you provide read/write permissions to folders on a network (for privacy) it is ultimately up to the people and applications you trust to respect your privacy and not just start emailing your word docs to your friends.

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.

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.

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’ve noticed a few interesting responses to my post on simplifying XFN. While my intended audiences were primarily fellow microformat enthusiasts and “lower case semantic web” types, there seems to be a larger conversation underway that I’d missed — one that both Adam “Everyware” Greenfield and Tim Berners-Lee have commented on.

In a treatise against XFN (and similarly reductive expressions of human relationships) from December of last year, Greenfield said a number of profound things:

• …one of my primary concerns has always been that we not accede to the heedless restructuring of everyday human relations on inappropriate and clumsy models derived from technical systems – and yet, that’s a precise definition of social networking as currently instantiated.
• All social-networking systems constrain, by design and intention, any expression of the full band of human relationship types to a very few crude options — and those static!
• …it’s impossible to use XFN to model anything that even remotely resembles an organic human community. I passionately believe that this reductive stance is not merely wrong, but profoundly wrong, in that it deliberately aims to bleed away all the nuance, complication and complexity that makes any real relationship what it is.
• I believe that technically-mediated social networking at any level beyond very simple, local applications is fundamentally, and probably persistently, a bad idea. From where I stand, the only sane response is to keep our conceptions of friendship and affinity from being polluted by technical metaphors and constraints to begin with.

Whew! Strong stuff, but useful, challenging and insightful.

Meanwhile, TBL defended a semi-autistic perspective in describing the future of the Semantic Web (yes, the uppercase version):

At the moment, people are very excited about all these connections being made between people — for obvious reasons, because people are important — but I think after a while people will realise that there are many other things you can connect to via the web.

While my sympathies actually lie with Greenfield (especially after a weekend getting my mom setup on Facebook so she could send me photos without clogging my inbox with 80MB emails… a deficiency in the design of the technology, not my mother mind you!), I also see the promise of a more self-aware, self-descriptive web. But, realistically, that web is a long way off, and more likely, that web is still going to need human intervention to make it work — at least for humans to benefit from it (oh sure, just get rid of the humans and the network will be just perfect — like planes without passengers, right?).

But in the meantime, there is a social web that needs to be improved, and that can be improved, in fairly simple and straight-forward ways, that will make it easier for regular folks who don’t (and shouldn’t have to) care about “data portability” and “password anti-patterns” and “portable contact lists” to benefit from the fact that the family and friends they care about are increasingly accessible online, and actually want to hear from them!

Even though Justin Smith takes another reductive look at the features Facebook is implementing, claiming that it wants to “own communications with your friends“, the reality is, people actually want to communicate with each other online! Therefore it follows that, if you’re a place where people connect and re-connect with one another, it’s not all that surprising that a site like Facebook would invest in and make improvements to facilitate interaction and communication between their members!

But let’s back up a minute.

If we take for granted that people do want to connect and to communicate on social networks (they seem to do it a lot, so much to that one might could even argue that people enjoy doing it!), what role should so-called “portable contact lists” play in this situation? I buy Greenfield’s assertion that attempts by technologists to reduce human relationships to a predefined schema (based on prior behavior or not) is a failing proposition, but that seems to ignore the opportunity presented by the fact that people are having to maintain many several lists of their friends in many different places, for no other reason than an omission from the design of the social internetwork.

Put another way, it’s not good enough to simply dismiss the trend of social networking because our primitive technological expressions don’t reflect the complexity of real human relationships, or because humans are just one of kind of “object” to be “semantified” in TBL’s “Giant Global Graph“… instead, people are connecting today, and they’re wanting to connect to people outside of their chosen “home” network and frankly the experience sucks and it’s confusing. It’s not good enough to get all prissy about it; the reality is that there are solutions out there today, and there are people working on these things, and we need smart people like Greenfield and Berners-Lee to see that solutions that enable the humanist web (however semantic it needs to be) are being prioritized and built… and that we [need] not accede to the heedless restructuring of everyday human relations on inappropriate and clumsy models derived from technical systems.

I can say that, from what I’ve observed so far, these are things that computers can do for us, to make the social computing experience more humane, should we establish simple and straightforward means to express a basic list of contacts between contexts:

• help us find and connect to people that we’ve already indicated that we know
• introduce us to people who we might know, or based on social proximity, should know (with no obligation to make friends, of course!)
• help us from accidently bumping into people we’d rather not interact with (see block-list portability)
• helping us to segment our friendships in ways that make sense to us (rather than the semi-arbitrary ways that social networks define)
• helping us to confidently share things with just the people with whom we intend to share

There may be others here, but off the top of my head, I think satisfying these basic tasks is a good start for any social network that thinks allowing you to connect and interact with people who you might know, but who may not have already signed up for the service, is useful.

I should make one last point: when thinking about importing contacts from one context to another, I do not think that it should be an unthinking act. That is, just because it’s merely data being copied between servers, the reality is that those bits represent things much more sacred and complicated than any computer might ever be programmed to imagine. Therefore, just because we can facilitate and lower the friction of “bringing your friends with you” from one place to another doesn’t mean that it should be an automatic process and that all your friends in one place should be made to be your friends in the new place.

And regardless of how often good ol’ Mark Zuckerberg claims that the end game is to make communications more efficient, when it comes to relationships, every connection transposed from one context to another should have to be reconsidered (hmm, a great argument for tagging of contacts…)! We can and should not make assumptions about the nature of people’s relationships, no matter what kind of semantics they’ve used to describe them in a given context. Human relationships are simply far too complicated to be left up to assumptions and inferences made by technologists whose affinity oftentimes lies closer to the data than to the makers of the data.

My thinking on this crystalized yesterday during the Building Portable Social Networks panel that I shared with Jeremy Keith, Leslie Chicoine, Joseph Smarr and David Recordon. I further defined my realization last night on Twitter and when Anders Conbere pinged me about a post he’d written more or less on the subject, I knew that I was on to something.

The idea itself is pretty simple, but insomuch as it reduces both complexity and helps narrow the scope of evangelism work needed to push for further adoption, I think the change is a necessary one.

→ Quite simply, contact list portability can be achieved with only rel-contact and rel-me. All the rest is gravy.

Here’s the deal: as it is, we have a pretty nasty anti-pattern that a number of us have been railing against for some time (and, as it turns out, with good friggin’ reason). As I pointed out on the panel yesterday, people shouldn’t be penalized for the fact that the technology allows them to be promiscuous with their account credentials; after all, their desire to connect with people that they know is a valid one and has been shown to increase engagement on social sites. The problem is that, heretofore, importing your list of contacts from various webmail address books required you to provide your account credentials to an untrusted third party. On top of that, your contact list is delivered as email addresses, which I call “resource deficient” (what else can you do with an email address but send messages to it or use it as a key to identify someone? URLs are much richer).

The whole mechanism for bringing with your friends to new social sites is broken.

Enter microformats and XFN

The solution we’ve been harping on for the last couple years is a web-friendly solution for marking up existing and (predominantly) public lists of friends, using 18 pre-defined rel values. WordPress supports XFN natively and is one of the primary reasons we started with WordPress as the foundation of the DiSo Project:

Reading up on the background of XFN, you realize that one of the primary goals of XFN was simplicity. Simplicity is relative however, and you have to remember that XFN’s simplicity was in contrast to FOAF, a much denser and complex format based on RDF.

Given all the values (that is, the existing XFN terms) and the generally semantic specificity of XFN, I decided to contrast the adoption of XFN by publishers and by consumers with the competing (and more ubiquitous) solution for contact list portability (i.e. email address import).

If you use Google’s new Social Graph API and actually go looking for XFN data (for example, on Twitter or Flickr or others), you’ll find that, by and large, the majority of XFN links on the web are using either rel-contact or rel-me.

If you’re lucky, you might find some rel-friends in there, but after rel-me and rel-contact, the use of the other 16 terms falls off considerably. Compound that fact with the minor semantic distinction between “contacts” and “friends” on different sites (sites like Dopplr dispense altogether with these terms, opting for “fellow travelers”) and you quickly begin to wonder if the “semantic richness” of XFN is really just “semantic deadweight”.

And, in terms of evangelism and potential adoption, this is critical. If 16 of the 18 XFN terms are just cruft, how can we maintain our credibility, especially when arguing against the email import approach, in which there are little to no semantic descriptors at the time of import (instead, you basically get a dumb list of email addresses — with no clues whatsoever as to which addresses are “sweethearts”, “crushes”, “kin” or the like). It’s not that XFN in and of itself is bad, it’s that, when compared with the reigning tactic of email import, we look as complicated and convoluted as FOAF did. The reality is, even if it’s “heinous” to data purists or pragmatists, email import works today, and what works, wins.

Defining Contact List Portability

The more I talk to Leslie (of Satisfaction), the more sensitive I become to the language that we use when we talk about the technologies that we work on. I mean, what the fuck is an “XFN”? Even “social network portability” probably causes rational people to break out in hives when they hear the phrase (not like we’ve hit mainstream or anything). I mean, from a usability perspective, the words we use to describe this stuff is about as usable as Drupal was five years ago (zing!). I can only imagine that when we technologists open our mouths, this is what goes through most people’s heads:

SO, I’m not advocating ditching XFN altogether; on the contrary, compared with FOAF, I think we’ve achieved a great deal of mindshare, at least in gaining the support of technologists who work on fairly large social sites (though that’s apparently being disputed). The next stage of the process should be to simplify, and to focus on what people are already doing and on what’s working. If we simply want to defeat the email import approach (which I think is a good idea, albeit with the caveat that we still need a notification mechanism — perhaps something easily ignorable like Facebook-app invites?), then I think we need to consolidate our efforts on rel-contact and rel-me and let people discover (and optionally implement) the remaining 16 values if they’re bored. Or have free time. As far as I’m concerned, they offer little to no actual utility when it comes to contact list portability.

So to the definition of contact list portability, I would suggest that it’s the ability to take a list of identifiers (read: URLs, formerly email addresses) that represent people that you know and connect with them in a new context (bonus points if by “taking” you read that as “subscribing” (but not “syncing”)).

This is consistent with Joseph’s Practical Vision for Friends-List Portability. It also importantly ignores the non-overlapping problems of groupings/relationship semantics and permissioning (things which should not be conflated!).

What’s next

Kveton agrees with me; Recordon dissents, wanting more extensibility.

I get Dave’s point, but before we worry about extensibility, we have to look at what minimal bits of XFN are being picked up. By only specifying that an outgoing link is either a “contact” or “another link of mine”, we greatly reduce the cognitive tax of grokking the problem that XFN set out to solve and minimize the implementation tax of rolling out the necessary logic and template changes. Ultimately, it also simplifies the dataset, and pushes the semantics of relationships deeper into applications where I’d argue they belong (again, looking at the Dopplr model as well as Pownce (friends, fans, fan of) and Twitter (following, followers). While the other 16 XFN values are certainly not off limits, their marginal value is negligible compared with the cost of explaining why anyone should care of about them (let along understand them — i.e. “muse”??). And, compared with emails for identifiers, URLs are definitely the future.

So, with that, I’m no longer going to both with advocating for the complete adoption of XFN. Instead, I’m going to advocate for supporting Contact List Portability by implementing rel-me and rel-contact (a “subset” of XFN). And that’s it.

This won’t solve the problems that Anders is talking about, but I think it’s radical simplification that’s been long overdue in the effort towards social network portability.