Citizen-centric Web – Page 5

Portable contact lists and the case against XFN

XFN I suppose it might come as a surprise that I’ve decided to question, if not reject, XFN as the format for expressing portable friends or contact lists. I’m not throwing out the baby in the bathwater here, but rather focusing on the problem that needs to be solved and choosing to redouble my efforts on an elegant solution that builds on existing work and implementations.

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.

An update to my my OpenID Shitlist, Hitlist and Wishlist

Back in December, I posted my OpenID Shitlist, Hitlist and Wishlist. I listed 7 companies on my shitlist, 14 on hitlist and 12 on my wishlist. Given that it’s been all of two months but we’ve made some solid progress, I thought I’d go ahead and give a quick update on recent developments.

First, the biggest news is probably that Yahoo has come online as an OpenID 2.0 identity provider. This is old news for anyone who’s been watching the space, but given that I called them out on my wishlist (and that their coming online tripled the number of OpenIDs) they get serious props, especially since Flickr profile URLs can now be used as identity URLs. MyBlogLog (called out on my shitlist) gets a pass here since they’re owned by Yahoo, but I’d still like to see them specifically support OpenID consumption

Second biggest news is the fact that, via Blogger, Google has become both an OpenID provider (with delegation) and consumer. Separately, Brad Fitzpatrick released the Social Graph API and declared that URLs are People Too.

Next, I’ll give big ups to PBWiki for today releasing support for OpenID consumption. This is a big win considering they were also on my shitlist and I’d previously received assurances that OpenID for PBWiki would be coming. Well, today they delivered, and while there are opportunities to improve their specific implementation, I’d say that Joel Franusic did a great job.

And, in other good news, Drupal 6.0 came out this week, with support for OpenID in core (thanks to Walkah!), so there’s another one to take off my hitlist.

I’d really like to take Satisfaction off my list, since they’ve released their API with support for OAuth, but they’ve still not added support for OpenID, so they’re not out of the woods just yet… even though their implementation of OAuth makes me considerably happy.

So, that’s about it for now. I hear rumblings from Digg that they want to support OpenID, but I’ve got no hard dates from them yet, which is fine. There’re plenty more folks who still need to adopt OpenID, and given the support the foundation has recently received from big guys like Microsoft, Google, Yahoo, Verisign and IBM, my job advocating for this stuff is only getting easier.

The Existential DiSo Interview

The Existential DiSo Interview from Chris Messina on Vimeo.

Here’s what I asked myself:

how are you?

we’re going to talk about diso today? is that right?

what is diso?

you say it’s a social network, so how would it work with wordpress?

how is this different from myspace or facebook?

so who’s involved in this project?

so what comes next?

how is this different than opensocial?

what’s going to be the big win for diso?

so do you see this model applying in any other domain on the web?

what kind of support do you need?

are you talking to any of the bigger social networks? like facebook or myspace?

so who cares?

how will you draw customers away from myspace or facebook?

any last thoughts?

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?

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.

My OpenID Shitlist, Hitlist and Wishlist for 2008

Update: I’ve posted an update to these lists, giving props to Yahoo, Google, PBWiki and Drupal for embracing OpenID.

I believe in the power of community to drive change, and I believe that peer pressure can be a great motivator. I also believe that shaming can be an equally powerful motivator, if used lovingly and when an “out” is provided.

In this case, that “out” is adding support for consuming OpenIDs, not just being an identity provider.

With that in mind, I thought I’d throw out my OpenID Shitlist, Hitlist and Wishlist with the hope that a little sunlight might cause the previously planted seeds to finally sprout. Since OpenID 2.0 is now out, these folks really have very little excuse not to get on board and make this happen (limited developer resources notwithstanding).

So, without further ado:

My Shitlist

Last February, at the Future of Web Apps in London, there was an orgy of OpenID announcements.

The point of my Shitlist is to publicly shame folks who have previously promised (or strongly indicated an intent) to adopt and add support for OpenID but who have failed, thus far, to do so. I invite them to redeem themselves by making good on their promises. I won’t hold it against them, but hey, it’s their word on the line.

Digg.com. I’d consider myself personal friends with the Digg folks. I like Daniel, Kevin and Owen. I think they do great work and that Digg is one of the most influential synaptic centers of the net. But Digg tops my shitlist because of a very important 10 seconds of speech that Kevin offered on stage, and which was covered by Om and TechCrunch. He said, and I quote: And then we also want to announce today, uh, support for OpenID. So we will be, uh, rolling out OpenID here in the next few months. That’s gunna be cool. Listen to it yourself. Did this ever happen? Nu uh. Still waiting. Hmmph!
NetVibes. NetVibes remains one of the more innovative, more “open source like” rich internet desktops out there. Tariq‘s a friend. But, like Digg, when you make promises (scroll down to Tariq Krim) to do something and months and months later you haven’t made good on your word, well, you end up in my shitlist.
Last.fm. Now, I’m going out on a limb here. I have a strong recollection that Last.fm was the third company to promise OpenID support at FOWA, but for the life of me, I can hardly find a reference (besides this: “So what was the buzz at this years FOWA London? Two things resonated to me more than anything in the conference. OpenID and attention data. All of the key players from digg to Netvibes, Last.FM to Arrington touched on, commented or made announcements in these arenas.” — hat tip to JP), and in the recording of their session, they make nary a mention. Now, I’m pretty sure they said something about it, but I don’t have proof. Last.fm needs OpenID regardless, so if someone can backup or discredit my memory, I’m happy to move them to a more appropriate list.
PBWiki. I’m a fan of PBWiki, the hosted wiki service. They’re a good friend to the BarCamp and Twitter communities and are my first choice when I need a wiki and don’t want the hassle of setting up and maintaining my own. The oldest email I could find when I first approached David, Nathan and Ramit with a request to support OpenID was July 30, 2006. I’ve badgered them consistently since then, receiving various assurances that they’d work on it. And without directly calling bullshit, I do wonder why their own Auth API hasn’t been made to be OpenID compliant when there have been so many other significant improvements made. I know that nerds aren’t their top priority (nor their biggest money-makers by a long shot) but maybe we can hack it in at the next SHDH?
MyBlogLog. I suppose things change when you get absorbed by a massive corporation that requires a consistent terms of service. Or else it seems plausible that the early indications of support for OpenID might have blossomed into full fledged support. Alas, it was not to be.
Technorati. In October of 2006, Technorati announced support for blog claiming with OpenID. They also became an OpenID provider. So technically, they don’t deserve a full shaming. However, it’s lame that they allow you to claim your blog if it’s an OpenID, but for reasons that confound me, don’t let you actually sign in to Technorati using the same OpenID. This seems ludicrous to me and frankly, I expect more from Technorati. (And can I point out that it’s a bad sign that when I search your blog for OpenID using your search engine, nothing comes up? Huzzah!)
Wikipedia. Well, everyone loves Wikipedia right (that’s an uncorroborated generalization)? Well, they still belong on my shitlist. Wikipedia said they’d support it in a Google Video as early as June of 2006. They might be able to define the protocol, but they certainly don’t support it. (Reprieve: open source to the rescue! Evan Prodromou wrote the OpenID extension for Mediawiki. Now Wikipedia simply needs to adopt it!)

Hitlist

With the shitlist out of the way, I can get on to those folks who haven’t necessary made promises before, but are ripe candidates to be lobbied to add support for OpenID.

Satisfaction. Satisfaction has long since planned on offering OpenID (and more recently OAuth) and they tell me that it’s coming soon. With co-founders (and my friends!) Thor and Amy recently getting into a new startup they’ve named Tesla Jane, I think I can be patient for a while longer. 😉
Twitter. If you’re aware of the backstory of OAuth, you’ll know that it was my advocacy of OpenID for Twitter that revealed the need for a delegated authentication protocol that was compatible with OpenID. And, now that OAuth has gone 1.0 (and while we’re waiting for Twitter to roll out support for the final spec) it’d be great to also see movement on the OpenID front. I know you’ll get right on that. Heh.
Drupal. Bonus points go to Drupal and James Walker for rolling in support for OpenID into core for Drupal 6.0, and maybe we have to wait for the upgrade, but it’s too bad that there isn’t support on the drupal.org website. Should be an easy fix, and with the brilliant way the community devoured my recent feedback, I hope that this request is met with equal enthusiasm!
Plazes. Well, I’m with Tara and am pretty disappointed with where Plazes is today. Felix and Stefan are great, but the new Plazer sucks. It’s like they took a bunch of VC and lost focus. Then again, maybe I’m projecting. Anyway, it’d mean something to me if they went ahead and added support for OpenID. Better late than never.
Pownce. Pownce has been rocking the portable social network stuff, along with sister-site Digg (yes, the same Digg on my shitlist). The logical next step is for them to provide OpenID consumption to make the circle of portability complete!
Ning. Well, they already have NingID, but I really question the wisdom of proprietary authentication schemes at this point. I mean, if they’re all about niche-social-networks, wouldn’t consuming OpenIDs make so much sense to further reduce barriers to outsides coming in to play?
LinkedIN. These guys have been doing some great work widely adopting microformats and becoming more social-network-like. People seem to use LinkedIN as an identity aggregation point; shouldn’t they also be able to prove that they own a certain LinkedIN profile elsewhere and then verify their accounts elsewhere by logging in to LinkedIN with their other OpenIDs?
Slideshare. Given that Slideshare probably has the greatest collection of OpenID related presentations on the net, it’s kind of a shame that you can’t login to the site using the protocol. I know Rashmi and Jon have their hands full, but it’d be sweet to see them add support.
TripIt. TripIt’s awesome. Tara and I did a day of consulting with them and have been constant users ever since. What’d be great is if you could use your OpenID to login between Dopplr and TripIt — it might sound insane to them — but they really are complementary services. Tying my identity between them would save me such a hassle of having to go back and forth between them — and they’d both win!
Blip, Viddler, YouTube et al. This might be a pipe dream, but I do think that we could win over Blip and Viddler. YouTube, not so much. But if we lobbied each independent and got one to go, the others might follow…
WordPress.com. So WordPress is a funny one. They serve as an OpenID provider but don’t currently consume. If you want to enable OpenID consumption, you have to run your own blog (as I do) and use Will Norris‘ excellent plugin. This isn’t necessarily a problem, but with Drupal 6.0 getting support and Blogger offering limited consumption of OpenIDs, I would have hoped that WordPress would have made the move first.
Pandora. Finally, and this one might just be a vanity request, but I think it’d be cool if Pandora supported OpenID, if only because it would make OpenID seem cooler.

Wishlist

So, with the more likely candidates out of the way, I’d like to turn my attention to what would be big wins for OpenID, but that are an order of magnitude harder to win over, not so much because of technology issues but because of the complexities of terms of service and other business-level issues. In any case, if we see support from these folks for OpenID in 2008, we know we’re making serious ground.

Facebook. I asked the question on Twitter whether people would use Facebook as their OpenID provider if they could. The overwhelming response was no. Still, of anyone, Facebook could, if they actually rebuilt people’s trust and extended the reach of their strong privacy controls with best practice OpenID support, I think it’d be a net positive thing to see Facebook official adopt OpenID. There are already two Facebook apps that enable it, so clearly someone’s interested!
Yahoo and its various properties: Flickr, Delicious, Upcoming. I know they’re interested, but it will take more than interest and developer intentions to make this one happen. If Yahoo gets on board, game over man, cat’s in the bag.
Google. With their enthusiasm for OAuth and the recognition of the problem of widespread password scraping, I think Google is realizing that their avoidance of OpenID is not paying off. With Blogger toying with support for OpenID, I think (hope!) that’s it’s only a matter of time.
Microsoft. Well, Bill already promised. And they’ve even shipped code, even if it’s kind of a weird approach. Like most brushes with the embrace of openness, Microsoft is probably at war with itself once again, on the one hand having elements within that want to do the right thing and on the other, for some reason, being heavily influence by holdouts from the evil empire. We’ll see what comes of this, but I’m not holding my breath, even if InfoCard is the right interface metaphor for OpenID.
Mozilla. I don’t know if you noticed, but Mozilla has quite a few properties strewn about. Practically every week there’s a new property launched to promote some new campaign, not to mention all the myriad community sites that crop up (i.e. UserStyles.org, thankfully an OpenID consumer!). In leiu of a top-down single sign-on solution, why not just support OpenID and get it over with and enable portable reputation within the Mozilla universe? And — once you do that — maybe start looking at integrating support into Firefox, as I asked earlier this year?
Trac/SVN. With OAuth, support for OpenID on the command line becomes much more feasible, even if there’s little support today. Imagine being able to use your OpenID credentials to login to any SVN repository. Being able to federate whitelists of identifiers would make cross-collaboration much more facile and I think would be a boon to independent open source development.
MySpace, Hi-5, Bebo, Orkut et al. I mean, we now know that OpenSocial is basically an overhyped widget distribution platform, but that doesn’t mean that it won’t turn into something more. Eventually the limits of siloed identities are going to run up against the cross-pollinating design of OpenSocial and logging in to Bebo with your MySpace account is not only going to make sense, but will be expected, just like I can send email from my Gmail account to Hotmail and Yahoo email users. OpenID 2.0, with directed identity, is perfectly suited to handle this particular use case and I’d love to see the early OpenSocial partners get on board sooner than later.
Adobe. Not even sure why this one’s in the list, but so long as I’m thinking big, it’d be sweet to see support not only on Adobe’s site for OpenID, but also in Flash apps (which I think would possibly require OAuth). Adobe has Adobe IDs already, and, as I suggested before, proprietary protocols for identity on the web make less and less sense.
TechCrunch. This one’s for fun. I know Mike’s a fan of big ideas and making things better, so it seems strange that, given his use of WordPress, he hasn’t demanded support for OpenID commenting yet. Perhaps we can dream.

Now that I’ve got those lists out of the way, I wanted to give summary props to folks who have already gone ahead and implemented OpenID (this is not an exhaustive list; check out the OpenID Directory for more):

Ma.gnolia (1)
ClaimID (1)
iusethis (1)
Basecamp (1, 2)
Dopplr (1)
AOL (1)
Six Apart (1)
JanRain/Pibb
Iconbuffet (1)
Shopify (1)
Plaxo (1)
Blinksale (1)
SmugMug (1, 2)
Wikitravel (1)

Make sure to stop by these folks’ sites and try out their support for OpenID. Heck, they’ve pioneered the way forward, might as well both give them some patronage and see what user experience lessons can be had from their implementations.

And, this is by no means a finished list. It’s just a start. If you’ve got your own Shitlist, Hotlist and Wishlists, please do share them. Not only have I probably missed some folks (Amazon anyone?), but there are probably services and sites more dear to your hearts that should be embracing citizen-centric web protocols that I don’t even know about yet.

So, let me know what you think and if you want to start doing some lobbying, the best place to start is with the OpenID site itself.