Technology – Page 6 – Factory Joe

The OpenID mobile experience

Two days ago, Ma.gnolia launched their mobile version, and it’s pretty awesome (disclosure: Ma.gnolia is a former client and current friend/partner of Citizen Agency).

In the course of development, Larry asked me what he thought he should do about adding OpenID sign-in to the mobile version. He was reluctant to do so because, he reasoned, the experience of logging in sucks, not just because of the OpenID round-trip dance, but because most identity providers don’t actually support a mobile-friendly interface.

Indeed, if you take a look at the flow from the Ma.gnolia mobile UI to my OpenID provider (using the iPhone simulator app), you can see that it does suck.

I strongly encourage Larry to go ahead and add OpenID even if the flow isn’t ideal. As it is, you can sign up to Ma.gnolia with only an OpenID (without a need for creating yet another username and password) and so without offering this login option, the mobile site would be off-limits to folks in this situation.

So there’s clearly an opportunity here, and I’m hoping that out of OpenIDDevCamp today, we can start to develop some best practices and interface guidelines for OpenID providers for the mobile flow (not to mention more generally).

If you’ve seen a good example of an OpenID (or roundtrip authentication flow) for mobile, leave a comment here and let me know. It’s hard to get screenshots of this stuff, so any pointers would be appreciated!

It’s high time we moved to URL-based identifiers

Ugh, I had promised not to read TechMeme anymore, and I’ve actually kept to my promise since then… until today. And as soon as I finish this post, I’m back on the wagon, but for now, it’s useful to point to the ongoing Scoble debacle for context and for backstory.

In a nutshell, Robert Scoble has friends on Facebook. These friends all have contact information and for whatever reason, he wants to dump that data into Outlook, his address book of choice. The problem is that Facebook makes it nearly impossible to do this in an automated fashion because, as a technical barrier, email addresses are provided as opaque images, not as easily-parseable text. So Scoble worked with the heretofore “trustworthy” Plaxo crew (way to blow it guys! Joseph, how could you?!) to write a scraper that would OCR the email addresses out of the images and dump them into his address book. Well, this got him banned from the service.

The controversy seems to over whether Scoble had the right to extract his friends’ email addresses from Facebook. Compounding the matter is the fact that these email addresses were not ones that Robert had contributed himself to Facebook, but that his contacts had provided. Allen Stern summed up the issue pretty well: My Social Network Data Is Not Yours To Steal or Borrow. And as Dare pointed out, Scoble was wrong, Facebook was right.

Okay, that’s all well and fine.

You’ll note that this is the same fundamental design flaw of FOAF, the RDF format for storing contact information that preceded the purposely distinct microformats XFN and hcard:

The bigger issue impeding Plaxo’s public support of FOAF (and presumably the main issue that similar services are also mulling) is privacy: FOAF files make all information public and accessible by all, including the contents of the user’s address book (via foaf:knows).

Now, the concern today and the concern back in 2004 was the exposure of identifiers (email addresses) that can also be used to contact someone! By conflating contact information with unique identifiers, service providers got themselves in the untenable situation of not being able to share the list of identifiers externally or publicly without also revealing a mechanism that could be easily abused or spammed.

I won’t go into the benefits of using email for identifiers, because they do exist, but I do want to put forth a proposal that’s both long time in coming and long overdue, and frankly Kevin Marks and Scott Kveton have said it just as well as I could: URLs are people too. Kevin writes:

The underlying thing that is wrong with an email address is that its affordance is backwards — it enables people who have it to send things to you, but there’s no reliable way to know that a message is from you. Conversely, URLs have the opposite default affordance — people can go look at them and see what you have said about yourself, and computers can go and visit them and discover other ways to interact with what you have published, or ask you permission for more.

This is clearly the design advantage of OpenID. And it’s also clearly the direction that we need to go in for developing out distributed social networking applications. It’s also why OAuth is important to the mix, so that when you arrive at a public URL identifier-slash-OpenID, you can ask for access to certain things (like sending the person a message), and the owner of that identifier can decide whether to grant you that privilege or not. It no longer matters if the Scobles of the world leak my URL-based identifiers: they’re useless without the specific permissions that I grant on a per instance basis.

As well, I can give services permission to share the URL-based identifiers of my friends (on a per-instance basis) without the threat of betraying their confidence since their public URLs don’t reveal their sensitive contact information (unless they choose to publish it themselves or provide access to it). This allows me the dual benefit of being able to show up at any random web service and find my friends while not sharing information they haven’t given me permission to pass on to untrusted third parties.

So screen scrape factoryjoe.com all you want. I even have a starter hcard waiting for you, with all the contact information I care to publicly expose. Anything more than that? Well, you’re going to have to ask more politely to get it. You’ve got my URL, now, tell me, what else do you really need?

The problem with open source design

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.

Call me elitist in this one aspect, but with all due respect to code artistes, it’s quite clear whether a function computes or not; the same quantifiable measures simply do not exist for design and that critical lack of objective review means that design is a form of Art, and its execution should be treated as such.
Continue reading “The problem with open source design”

Kicking off 2008 with a themeword

At Lifecamp on Monday, (incidentally held at Tantek’s Port Zero) we had a session where the small group of us brainstormed what Erica Douglass called “theme words” that might help us focus our goals for 2008.

Erica’s theme word for 2008 is “connect”. Mine is “conduct” (in all its meanings). Alex Hillman’s is “growth”.

Now, this is a pretty simple exercise and a good way to kick off the New Year. What’s most interesting about this, however, is that we were able to extend participation by constructing a hashtag-based meme on Twitter. It started simply enough:

The response that has followed has been pretty incredible, and demonstrates the value of using community-driven hashtags to both generate and follow a meme (using hashtags.org).

Now, you obviously don’t have to use Twitter to participate; you can simply blog your own themeword and tag it with “themeword” or you could just write it down for yourself, and check back in at the end of the year and reflect on whether you stuck to your theme.

Either way, I’m already starting to see how “conduct” is a good word for me in 2008! What’s yours?

Fluid, Prism, Mozpad and site-specific browsers

Matt Gertner of AllPeers wrote a post the other day titled, “Wither Mozpad?” In it he poses a question about the enduring viability of Mozpad, an initiative begat in May to bring together independent Mozilla Platform Application Developers, to fill the vacuum left by Mozilla’s Firefox-centric developer programs.

Now, many months after its founding, the group is still without a compelling raison d’être, and has failed to mobilize or catalyze widespread interest or momentum. Should the fledgling effort be disbanded? Is there not enough sustaining interest in independent, non-Firefox XUL development to warrant a dedicated group?

Perhaps.

There are many things that I’d like to say both about Mozilla and about Mozpad, but what I’m most interesting in discussing presently is the opportunity that sits squarely at the feet of Mozilla and Mozpad and fortuitously extends beyond the world-unto-itself-land of XUL: namely, the opportunity that I believe lies in the development of site-specific browsers, or, to throw out a marketing term: rich internet applications (no doubt I’ll catch flak for suggesting the combination of these terms, but frankly it’s only a matter of time before any distinctions dissolve).

If you’re just tuning in, you may or may not be aware of the creeping rise of SSBs. I’ve personally been working on these glorified rendering engines for some time, primarily inspired first by Mike McCracken’s Webmail.app and then later Ben Willmore’s Gmail Browser, most recently seeing the fruition of this idea culminated in Ruben Bakker’s pay-for Gmail wrapper Mailplane.app. More recently we’ve seen developments like Todd Ditchendorf’s Fluid.app which generates increasingly functional SSBs and prior to that, the stupidly-simple Direct URL.

But that’s just progress on the WebKit side of things.

If you’ve been following the work of Mark Finkle, you’ll be able to both trace the threads of Web Runner’s transformation into the full-fledged Prism project, as well as the germination of Mozpad.

Clearly something is going on here, and when measured against Microsoft’s Silverlight and Adobe’s AIR frameworks, we’re starting to see the emergence of an opportunity that I think will turn out to be rather significant in 2008, especially as an alternative, non-proprietary path for folks wishing to develop richer experiences without the cost, or the heaviness, of actually native apps. Yes, the rise of these hybrid apps that look like desktop-apps, but benefit from the connectedness and always-up-to-date-ness of web apps is what I see as the unrecognized fait accompli of the current class of stand-alone, standards compliant rendering engines. This trend is powerful enough, in my thinking, to render the whole discussion about the future of the W3C uninteresting, if not downright frivolous.

A side effect of the rise of SSBs is the gradual obsolescence of XUL (which already currently only holds value in the meta-UI layer of Mozilla apps). Let’s face it: the delivery mechanism of today’s Firefox extensions is broken (restarting an app to install an extension is so Windows! yuck!), and needs to be replaced by built-in appendages that offer better and more robust integration with external web services (a design that I had intended for Flock) that also provides a web-native approach to extensibility. As far as I’m concerned, XUL development is all but dead and will eventually be relegated to the same hobby-sport nichefication of VRML scripting. (And if you happen to disagree with me here, I’m surprised that you haven’t gotten more involved in the doings of Mozpad).

But all this is frankly good for Mozilla, for WebKit (and Apple), for Google, for web standards, for open source, for microformats, for OpenID and OAuth and all my favorite open and non-proprietary technologies.

The more the future is built on — and benefits from — the open architecture of the web, the greater the likelihood that we will continue to shut down and defeat the efforts that attempt to close it up, to create property out of it, to segregate and discriminate against its users, and to otherwise attack the very natural and inclusive design of internet.

Site specific browsers (or rich internet applications or whatever they might end up being called — hell, probably just “Applications” for most people) are important because, for a change, they simply side-step the standards issues and let web developers and designers focus on functionality and design directly, without necessarily worrying about the idiosyncrasies (or non-compliance) of different browsers (Jon Crosby offers an example of this approach). With real competition and exciting additions being made regularly to each rendering engine, there’s also benefit in picking a side, while things are still fairly fluid, and joining up where you feel better supported, with the means to do cooler things and where generally less effort will enable you to kick more ass.

But all this is a way of saying that Mozpad is still a valid idea, even if the form or the original focus (XUL development) was off. In fact, what I think would be more useful is a cross-platform inquiry into what the future of Site Specific Browsers might (or should) look like… regardless of rendering engine. With that in mind, sometime this spring (sooner than later I hope), I’ll put together a meetup with folks like Todd, Jon, Phil “Journler” Dow and anyone else interested in this realm, just to bat around some ideas and get the conversation started. Hell, it’s going on already, but it seems time that we got together face to face to start looking at, seriously, what kind of opportunity we’re sitting on here.

Making the most of hashtags

A couple of days ago a new site called Hashtags.org was launched by Cody Marx Bailey and Aaron Farnham, two ambitious ~~college students~~ folks from Bryan & College Station, Texas.

I wanted to take a moment to comment on its arrival and also suggest a slight modification to the purpose and use of hashtags, now that we have a service for making visible this kind of metadata.

First of all, if you’re unfamiliar with hashtags or why people might be prepending words in their tweets with hash symbols (#), read Groups for Twitter; or A Proposal for Twitter Tag Channels to get caught up on where this idea came from.

You should note two things: first, when I made my initial proposal, Twitter didn’t have the track feature; second, I was looking to solve some pretty specific problems, largely related to groupings and to filtering and to amplifying intent (i.e. when making generic statements, appending an additional tag or two might help others better understand your intent). For consistency, my initial proposal required that all important terms be prefixed with the hash, despite how ugly this makes individual updates look. The idea was that, I’d try it out, see how it worked, and if someone built something off of it, or other people adopted the convention, I could decide if the hassle and ugliness were ultimately worth it. A short time after I published my proposal, the track feature launched and obviated parts of my proposal.

Though the track feature provided a means for following explicit information, there was still no official means to add additional information, whether for later recall purposes or to help provide more context for a specific update. And since Twitter currently reformats long links as meaningless TinyURLs, it’s nice to be able to provide folks with a hint about the content at the end of the link. On top of those benefits, hashtags provide a mechanism for leveraging Twitter’s tracking functionality even if your update doesn’t include a specific keyword by itself.

Now, I’ll grant you that a lot of this is esoteric. Especially given that Twitter is predicated on answering the base question “what are you doing?” I mean, a lot of this hashtag stuff is gravy, but for those who use it, it could provide a great deal of value, just like the community-driven @reply convention.

Moreover, we’ve already seen some really compelling and unanticipated uses of hashtags on Twitter — in particular the use of the #sandiegofire hashtag as a common means for identifying information related to the San Diego fires.

And that’s really just the beginning. With a service like Tweeterboard providing even more interesting and contextual social statistics, it won’t be long before you’ll be able to discover people who talk about similar topics or ideas that you might enjoy following. And now, with Hashtags.org, trends in the frequency of certain topics will become all the more visible and quantifiable.

BUT, there is a limit here, and just because we can add all this fancy value on top of the blogosphere’s central intelligence system doesn’t mean that our first attempt at doing so is the best way to do it, or that we should definitely do it at all, especially if it comes at a high cost (perceived or real) to other users of the system.

Already it’s been made clear to me that the use of hashtags can be annoying, adding more noise than value. Some people just don’t like how they look. Still others feel that they encumber a simple communication system that should do one thing and one thing well, secondary uses be damned if they don’t blend with the how the system is generally used. This isn’t del.icio.us or Ma.gnolia after all.

And these points are all valid and well taken, but I think there’s some middle ground here. Used sparingly, respectfully and in appropriate measure, I think that the value generated from the use of hashtags is substantial enough to warrant their continued use, and it isn’t just hashtags.org that suggests this to me. In fact, I think hashtags.org, in the short term, might do more damage than good, if only because it means people will have to compose messages in unnatural ways to take advantage of the service, and this is never the way to design good software (sorry guys, but I think there’s room to improve the basic track feature yet).

In fact, with the release of the track feature, it became clear that every word used in a post is important and holds value (something that both Jack and Blaine noted in our early discussions). But it’s also true that without certain keywords present in a post, the track feature is useless. In this case in particular, where they provide additional context, I think hashtags serve a purpose. Consider this:

“Tara really rocked that presentation!”

versus:

“Tara really rocked that presentation! #barcampblock”

In the latter example, the presence of the hashtag provides two explicit benefits: first, anyone tracking “barcampblock” will get the update, and second, those who don’t know where Tara is presenting will be clued into the context of the post.

In another example:

“300,000 people evacuated in San Diego county now.”

versus

“#sandiegofire: 300,000 people evacuated in San Diego county now.”

Again, the two benefits are present here, demonstrating the value of concatenated hashtags where using the space-separated phrase “San Diego” would not have been caught by the track feature.

What I don’t think is as useful as when I first made my proposal (pre-tracking) is calling out specific words in a post for emphasis (unless you’re referring to a place or airport, but that’s mostly personal preference). For example, revising my previous proposal, I think that this approach is now gratuitous:

“Eating #popcorn at #Batman in #IMAX.”

Removing the hashes doesn’t actually reduce the meaning of this post, nor does it affect the tracking feature. And, leaving them out makes the whole update look much better:

“Eating popcorn at Batman in IMAX.”

If you wanted to give your friends some idea of where you are, it might be okay to use:

“Eating popcorn at Batman in IMAX at #Leows.”

…but even still, the hash is not wholly necessary, if only to help denote some specialness to the term “Leows”.

So, with that, I’m thrilled to see hashtags.org get off the ground, but it’s use should not interfere with the conventional use of Twitter. As well, they provide additional value when used conservatively, at least until there is a better way to insert metadata into a post.

As with most technology development, it’s best to iterate quickly, try a bunch of things (rather than just talk about them) and see what actually sticks. In the case of hashtags, I think we’re gradually getting to a pretty clear and useful application of the idea, if not the perfect implementation so far. Anyway, this kind of “conversational development” that allows the best approach to emerge over time while smoothing out the rough edges of an original idea seems to be a pretty effective way to go about making change, and it’s promising to see efforts like hashtags.org take a simple — if not controversial — proposal, and push it forward yet another step.

Public nuisance #1: Importing your contacts

I’ve talked about this before (as one of the secondary motivators behind OAuth) but I felt it deserved a special call out.

Recently, Simon Willison presented on OpenID and called the practice that Dopplr (and many many others) uses to import your contacts from Gmail absolute horrifying. I would concur, but point out that Dopplr is probably the least offender as they also provide safe and effective hcard importing from Twitter or any URL, just as Get Satisfaction does.

Unfortunately this latter approach is both less widely implemented and also unfamiliar to many regular folks who really just want to find their friends or invite them to try out a new service.

The tragedy here is that these same folks are being trained to hand out their email address and passwords (which also unlock payment services like Google Checkout) regularly just to use a feature that has become more or less commonplace across all social network sites. In fact, it’s so common that Plaxo even has a free widget that sites can use to automate this process, as does Gigya. Unfortunately, the code for these projects is not really open source, whereas Dopplr’s is, providing little assurance or oversight into how the import is done.

What’s most frustrating about this is that we have the technology to solve this problem once and for all (a mix of OpenID, microformats, OAuth, maybe some Jabber), and actually make this situation better and more secure for folks. Why this hasn’t happened yet, well, I’m sure it has something to do with politics and resources and who knows what else. Anyway, I’m eager to see a open and free solution to this problem and I think it’s the first thing we need to solve after January 1.

Blogger adopts OpenID site-wide

Clarification: The title of this post is a little misleading, as Oxa pointed out. Blogger has only enabled OpenID commenting site-wide. The author regrets any impression otherwise.

In what has to be a positive sign of things to come, Blogger has taken the OpenID commenting feature from beta to live in a matter of two weeks.

This is huge.

With great progress coming on OAuth Discovery, we’re rapidly approaching the plumbing needed to really start to innovate on citizen-centric web services… and social network portability.

Ruminating on DiSo and the public domain

There’s been some great pickup of the DiSo Project since Anne blogged about it on GigaOM.

I’m not really a fan of early over-hype, but fortunately the reaction so far has been polarized, which is a good thing. It tells me that people care about this idea enough to sign up, and it also means that people are threatened enough by it to defensively write it off without giving it a shot. That’s pretty much exactly where I’d hope to be.

There are also a number of folks pointing out that this idea has been done before, or is already being worked on, which, if you’re familiar with the microformats process, understand the wisdom in paving well-worn cow paths. In fact, in most cases, as Tom Conrad from Pandora has said, it’s not about giving his listeners 100% of what they want (that’s ridiculous), it’s about moving from the number of good songs from six to seven out of a set of eight. In other words, most people really don’t need a revolution, they just want a little more of what they already have, but with slight, yet appreciable, improvements.

Anyway, that’s all neither here nor there. I have a bunch of thoughts and not much time to put them down.

. . .

I’ve been thinking about mortality a lot lately, stemming from Marc Orchant’s recent tragic death and Dave Winer’s follow up post, capped off with thinking about open data formats, permanence and general digital longevity (when I die, what happens to my digital legacy? my OpenID?, etc).

Meanwhile, and on a happier note, I had the fortunate occasion to partake in the arrival of new life, something that, as an uncle of ~17 various nieces and nephews, I have some experience with.

In any case, these two dichotomies have been pinging around my brain like marbles in a jar for the past couple days, perhaps bringing some things into perspective.

. . .

Meanwhile, back in the Bubble, I’ve been watching “open” become the new bastard child of industry, its meaning stripped, its bite muzzled. The old corporate allergy to all things open has found a vaccine. And it’s frustrating.

Muddled up in between these thoughts on openness, permanence, and on putting my life to some good use, I started thinking about the work that I do, and the work that we, as technologists do. And I think that term shallow now, especially in indicating my humanist tendencies. I don’t want to just be someone who is technologically literate and whose job it is to advise people about how to be more successful in applying its appropriate use. I want to create culture; I want to build civilization!

And so, to that end, I’ve been mulling over imposing a mandate on the DiSo Project that forces all contributions to be released into the public domain.

Now, there are two possible routes to this end. The first is to use a license compatible with Andrius Kulikauskas‘ Ethical Public Domain project. The second is to follow the microformats approach, and use the Creative Commons Public Domain Dedication.

While I need to do more research into this topic, I’ve so far been told (by one source) that the public domain exists in murky legal territory and that perhaps using the Apache license might make more sense. But I’m not sure.

In pursuing clarity on this matter, my goals are fairly simple, and somewhat defiant.

For one thing, and speaking from experience, I think that the IPR process for both OpenID and for OAuth were wasteful efforts and demeaning to those involved. Admittedly, the IPR process is a practical reality that can’t be avoided, given the litigious way business is conducted today. Nor do I disparage those who were involved in the process, who were on the whole reasonable and quite rational; I only lament that we had to take valuable time to work out these agreements at all (I’m still waiting on Yahoo to sign the IPR agreement for OAuth, by the way). As such, by denying the creation of any potential IP that could be attached to the DiSo Project, I am effectively avoiding the need to later make promises that assert that no one will sue anyone else for actually using the technology that we co-create.

So that’s one.

Second, Facebook’s “open” platform and Google’s “open” OpenSocial systems diminish the usefulness of calling something “open”.

As far as I’m concerned, this calls for the nuclear option: from this point forward, I can’t see how anyone can call something truly open without resorting to placing the work firmly in the public domain. Otherwise, you can’t be sure and you can’t trust it to be without subsequent encumbrances.

I’m hopeful about projects like Shindig that call themselves “open source” and are able to be sponsored by stringent organizations like the Apache foundation. But these projects are few and far between, and, should they grow to any size or achieve material success, inevitably they end up having to centralize, and the “System” (yes, the one with the big es) ends up channeling them down a path of crystallization, typically leading to the establishment of archaic legal institutions or foundations, predicated on being “host” for the project’s auto-created intellectual property, like trademarks or copyrights.

In my naive view of the public domain, it seems to me that this situation can be avoided.

We did it (and continue to prove out the model) with BarCamp — even if the Community Mark designation still seems onerous to me.

And beyond the legal context of this project, I simply don’t want to have to answer to anyone questioning why I or anyone else might be involved in this project.

Certainly there’s money to be had here and there, and it’s unavoidable and not altogether a bad thing; there’s also more than enough of it to go around in the world (it’s the lack of re-circulation that should be the concern, not what people are working on or why). In terms of my interests, I never start a project with aspirations for control or domination; instead I want to work with intelligent and passionate people — and, insomuch as I am able, enable other people to pursue their passions, demonstrating, perhaps, what Craig Newmark calls nerd values. So if no one (and everyone) can own the work that we’re creating, then the only reason to be involved in this particular instance of the project is because of the experience, and because of the people involved, and because there’s something rewarding or interesting about the problems being tackled, and that their resolution holds some meaning or secondary value for the participants involved.

I can’t say that this work (or anything else that I do) will have any widespread consequences or effects. That’s hardly the point. Instead, I want to devote myself to working with good people, who care about what they do, who hold out some hope and see validity in the existence of their peers, who crave challenge, and who feel accomplished when others share in the glory of achievement.

I guess when you get older and join the “adult world” you have to justify a lot more to yourself and to others. It’s a lot harder to peel off the posture of defensiveness and disbelief that come with age than to allow yourself to respond with excitement, with hope, with incredulity and wonder. But I guess I’m not so much interested in that kind of “adult world” and I guess, too, that I’d rather give all my work away than risk getting caught up in the pettiness that pervades so much of the good that is being done, and that still needs to be done, in all the many myriad opportunities that surround us.

The inside-out social network

Anne Zelenka of Web Worker Daily and GigaOM fame wrote me to ask what I meant by “building a social network with its skin inside out” when I was describing DiSo, the project that Steve Ivy and I (and now Will Norris) are working on.

Since understanding this change that I envision is crucial to the potential wider success of DiSo, I thought I’d take a moment and quote my reply about what I see are the benefits of social network built inside-out:

The analogy might sound a little gruesome I suppose, but I’m basically making the case for more open systems in an ecosystem, rather than investing or producing more closed off or siloed systems.

There are a number of reasons for this, many of which I’ve been blogging about lately.

For starters, “citizen centric web services” will arguably be better for people over the long term. We’re in the toddler days of that situation now, but think about passports and credit cards:

your passport provides proof of provenance and allows you to leave home without permanently give up your port of origin (equivalent: logging in to Facebook with your MySpace account to “poke” a friend — why do you need a full Facebook account for that if you’re only “visiting”?);

your credit/ATM cards are stored value instruments, making it possible for you to make transactions without cash, and with great convenience. In addition, while you should choose your bank wisely, you’re always able to withdraw your funds and move to a new bank if you want. This portability creates choice and competition in the marketplace and benefits consumers.

It’s my contention that, over a long enough time horizon, a similar situation in social networks will be better for the users of those networks, and that as reputation becomes portable and discoverable, who you choose to be your identity provider will matter. This is a significant change from the kind of temporariness ascribed by some social network users to their accounts today (see danah boyd).

Anyway, I’m starting with WordPress because it already has some of the building blocks in place. I also recognize that, as a white male with privilege, I can be less concerned about my privacy in the short term to prove out this model, and then, if it works, build in strong cross-silo privacy controls later on. (Why do I make this point? Well, because the network that might work for me isn’t one that will necessarily work for everyone, and so identifying this fact right now will hopefully help to reveal and prevent embedding any assumptions being built into the privacy and relationships model early on.)

Again, we’re in the beginning of all this now and there’ll be plenty of ill-informed people crying wolf about not wanting to join their accounts, or have unified reputation and so on, but that’s normal during the course of an inversion of norms. For some time to come, it’ll be optional whether you want to play along of course, but once people witness and come to realize the benefits and power of portable social capital, their tune might change.

But, as Tara pointed out to me today, the arguments for data portability thus far seem predicated on the wrong value statement. Data portability in and of itself is simply not interesting; keeping track of stuff in one place is hard enough as it is, let alone trying to pass it between services or manage it all ourselves, on our own meager hard drives. We need instead to frame the discussion in terms of real-world benefits for regular people over the situation that we have today and in terms of economics that people in companies who might invest in these technologies can understand, and can translate into benefits for both their customers and for their bottom lines.

I hate to put it in such bleak terms, but I’ve learned a bit since I embarked on a larger personal campaign to build technology that is firmly in the service of people (it’s a long process, believe me). What developers and technologists seem to want at this point in time is the ability to own and extract their data from web services to the end of achieving ultimate libertarian nirvana. While I am sympathetic to these goals and see them as the way to arriving at a better future, I also think that we must account for those folks for whom Facebook represents a clean and orderly experience worth the exchange of their personal data for an experience that isn’t confounding or alienating and gives them (at least the perception) of strong privacy controls. And so whatever solutions we develop, I think the objective should not be to obviate Facebook or MySpace, but to build systems and to craft technologies that will benefit and make such sites more sustainable and profitable, but only if they adopt the best practices and ideals of openness, individual choice and freedom of mobility.

As we architect this technology — keeping in mind that we are writing in code what believe should be the rights of autonomous citizens of the web — we must also keep in mind the wide diversity of the constituents of the web, that much of this has been debated and discussed by generations before us, and that our opportunity and ability to impose our desires and aspirations on the future only grows with our successes in freeing from the restraints that bind them, the current generation of wayward web citizens who have yet to be convinced that the vision we share will actually be an improvement over the way they experience “social networking” today.