On Friday, David Recordon, one of the original authors of OpenID, released a single-page specification for OpenID Connect, a concept that I outlined on this blog in January before I joined Google.

I’m particularly excited about this early proposal because it builds on all the great progress that the community has made recently on a litany of technologies, including OAuth 2.0 and the link-based resource descriptor format (LRDD) and its emerging JSON-based variant (JRD).

But I’m most excited about OpenID Connect because it forces the OpenID community to evaluate the progress we’ve made over the last three years (OpenID 2.0 was introduced in 2007) and to think critically about where we go next, and how we get there, given what the market has indicated it wants.

Rearticulating the problem

When Brad Fitzpatrick first created OpenID, he was looking to solve a fairly mundane problem: develop a protocol that made it possible for a commenter to claim her comments on someone else’s blog. For the commenter, she had a way to vouch for her words; for the blog owner, he had a way to establish the authenticity of the comments left by his readers. Given this context, all that was required in the early days of OpenID was a stable way to uniquely identify people — gathering additional profile information wasn’t as necessary because blog commenting forms already asked for — and often required — that commenters supply their name and email address.

Thus the basic architecture of OpenID concerned itself with establishing identity across contexts (i.e. “Bob” from Context A is the same “Bob” found in Context B), rather than with profile portability. This focus lent itself to privacy-preserving anonymous and pseudonymous transactions where identity could be established without the need to divulge personally-identifying information, or without forcing you to collapse the boundaries of separate social contexts.

This feature of OpenID (called directed identity) enabled you to hold a single account at, say, yahoo.com, but sign in to third party sites using “non-correlatable identifiers”. That is, this feature made it possible to maintain discreet profiles for logging in to other sites across the web without needing a different password to manage each.

The ability to “select [the] OpenID identifier” that I want to share with stackoverflow.com is how this feature manifests on yahoo.com:

The economics of user-centric identity

Features like directed identity, however, present several challenges for users and OpenID relying parties.

For users, these features complicate the sign in flow by introducing new interface surfaces (as seen above) and management tasks. They also increase the cognitive burden of registration by requiring a user to pick a profile (or create a new one) to use in a given context. Additionally, the ability to refrain from disclosing profile information when registering for a new service may seem economically advantageous to the user at the outset (“Aha! I refuse to tell you my name or email address!”) but results in unintended disadvantages over time.

That is, because OpenID users share less information with third parties, they are perceived as being “less valuable” than email-based registrants or users that connect to their Facebook or Twitter accounts.

Why? Simply put: OpenID, by design, favors the user rather than the relying party. In contrast, technologies like Facebook and Twitter Connect emphasize the benefits to relying parties. So while it might seem like an inconvenience to custom-tailor your personal privacy settings on Facebook, the liberal defaults are meant to make Facebook users’ accounts more valuable to relying parties than other, more privacy-preserving account configurations.

So, as Twitter and Facebook have grown in popularity and the number of sites willing to outsource their account management to them have increased, both OpenID users and providers find themselves in a predicament: if they continue to restrict the flow of data, the number of OpenID relying parties will diminish in favor of Facebook- and Twitter-Connected sites. If instead OpenID users become more liberal with the data that they are willing (and able) to share with third parties, they will still need to rally support from relying parties to be recognized as valuable users. Thus making more data available from OpenID users is the first essential step that we must take to regain our footing in the marketplace.

But it won’t be enough.

To overcome both the real and perceived economic disadvantage of supporting OpenID, we need to make adopting OpenID exceedingly simple, straight-forward, and economically advantageous — in real terms.

Why harmonizing “Connect” is important

I wrote my overview for OpenID Connect convinced that the “connect” verb (inherited from the Twitter and Facebook platforms) would help users distinguish between merely registering for a site and signing up for and sharing some data about themselves. Even though Facebook abandoned the “connect” brand at F8 this year, I’m still of the mind that the “connect” verb suits our purposes, even if it’s going to take several years to catch on in common usage.

In any case, if OpenID solves the problem of providing a stable and unique way to identify someone, then the “Connect” in OpenID Connect layers in the ability to access data on someone’s behalf (via conventional APIs like Portable Contacts or ActivityStreams).

It’s this assemblage of authentication and authorization technologies that the industry is calling out for — as evidenced by the success of Facebook and Twitter Connect and more recently, Messenger Connect from Microsoft and upstart efforts like Diaspora that cite OpenID among the technologies they intend to leverage. Without a common standard, each of these efforts is inventing its own custom-tailored solution, retarding industry-wide progress and delaying the development of next generation social applications.

Thus, by leveraging OAuth as the core of OpenID Connect, we can build on the consensus and momentum that has been achieved in the marketplace, and by weaving in a standard and much-simpler discovery mechanism, we can preserve the decentralized design of OpenID. Presuming that Facebook, Twitter, Google, and others all become OpenID Connect providers, that means that site operators can implement one connect API and interoperate with potentially dozens of providers with a single, well-understood open source stack of technologies.

Such an outcome would be good for relying parties (or “clients” in the parlance of Recordon’s proposal) as well as citizens of the web, who deserve a choice when it comes to entrusting a provider with their digital identity but are increasingly marginalized by “privacy-preserving technologies” that are not economically viable.

“Connect” also provides a convenient answer to the question of what kind of interface to present to the users who want to use their OpenID:

(Note that I also used the “connect” verb very intentionally in my social agent mockups for designing identity into the browser.)

If every site that supports third party authentication today added a “connect” button in place of their conventional “sign up” or “register” buttons and deployed a consistent user experience around picking a provider (some combination of NASCAR buttons and a type-anything email/URL field) that executed the OpenID Connect protocol, we’d be well along the path of decentralizing the social web, and restoring balance to the ecosystem.

What does OpenID stand for?

Of course, applying the OpenID brand to this solution isn’t something that I would do trivially, since the OpenID Foundation is the real authority for the trademark. However, at the foundation’s board meeting earlier this year at the OpenID Summit West, we unanimously decided to expand the scope of the OpenID Foundation’s mission to include advancing the technological underpinnings of internet identity in general, without regard for the existing OpenID technology.

This is a critical recasting of the role that OpenID and the OpenID Foundation plays in the ecosystem. Though there are other groups with similar mandates, the OpenID Foundation has decided to take on the internet identity opportunity as a general problem, rather than one narrowly scoped to disposable use cases.

In that light, it seems to me that we have come to a crossroads in the history of the foundation — however knowingly — and decided to take aggressive actions to advance the cause.

Without speaking for the foundation as a whole, I believe that it is essential that we are able to reconceive OpenID as the brand for decentralized digital identity. OpenID need not be thought of as merely an identity algorithm, but as a means for representing and conducting oneself online and across digital environments. Thus as the identity landscape undulates, the OpenID Foundation is in the position to articulate solutions that are not protocol-bound, but responsive to needs of the time, and able to adapt to and weather the shifting winds of technological progress.

After OpenID 2.0, OpenID Connect is the next significant reconceptualization of the technology that aims to meet the needs of a changing environment — one that is defined by the flow of data rather than by its suppression. It is in this context that I believe OpenID Connect can help usher forth the next evolution in digital identity technologies, building on the simplicity of OAuth 2.0 and the decentralized architecture of OpenID.

Yesterday’s launch of Google Buzz and the fledgling Google Buzz API is like a downpayment on what I see as Google’s broader social web ambitions, that have been bubbling beneath the surface for some time. Understand that Buzz is not entirely an end unto itself, but a way for Google to get some skin in the game to promote the use and adoption of different open technologies for the social web.

In fact, I’d argue that Buzz is as much about Google creating a new channel for conversation in a familiar place as it is about how we’re going about building its public developer surfaces. Although today’s Buzz API only offers a real-time read-only activity stream, the goal is to move quickly towards implementing a host of other technologies — most of which should be familiar to readers of this blog.

As Kevin Marks observes, in order to address the mess of the social web that Mike Arrington described, we need widespread use [of common standards] so that we can generalize across sites — and thus enable people to interact and engage across the web , rather than being restricted to any particular silo of activity — which may or may not reflect their true social configuration.

In other words, standards — and in particular social web standards — are the lingua franca that make it possible for uninitiated web services to interact in a consistent manner. When web services use standards to commoditize essential and basic features, it forces them to compete not with user lock-in, but by providing better service, better user experience, or with new functionality and utility. I am an advocate of the open web because I believe the open web leads to increased competition, which in turn affords people better options, and more leverage in the world.

Buzz is both a terrific product, and a great example of how the social web is evolving and becoming truly ubiquitous. Buzz is simply one more stitch in the fabric of the social web.

I’ve been thinking about how we make OpenID both easier and sexier for quite a while now. As frustrating as the answer may be to technologists, the problem is not necessarily one that can be solved with more technology. Instead, at some point, you have to move beyond the original constituents of a solution and start to package up the thing in a way that is less alienating, and less “insider baseball”.

“OpenID Connect”, therefore, is what I’m starting to use in casual conversation as my answer to Twitter and Facebook Connect.

It’s really creative, I know. That’s why they pay me the big bucks.

Seriously though, from a marketing perspective — it’s what I want the OpenID Foundation (and our new board) to offer the world in 2010. Essentially I think it’s time we ditched the “Open Stack” concept and put something out there that can stand up in conversation alongside the likes of Facebook Connect, in all its rich and specific expressiveness.

At some point, I want OpenID Connect to be what Facebook and Google and others implement that becomes the interoperable identity interchange protocol for the social web. But we’re not quite there yet, though all the technology is on the verge of being… ready.

Speaking of, from a technical perspective — I’m really just talking about repackaging OpenID as a profile of OAuth WRAP (credit: Recordon). It would provide relying parties with profile data, relationships, access to content, and activity streams — based on Recordon’s anatomy of connect.

Unlike the current incarnation, it would work in real-time, distributed systems, on the desktop as well as in mobile devices. Huzzah!

We’re not even that far away from such a solution. Since OpenID really just bootstraps identity — we need a way to provide relying parties with all the other stuff they’ve come to expect from the Twitter and Facebook Connect APIs… and that’s where the “connect” in “OpenID Connect” comes in.

So, to summarize:

• for the non-tech, uninitiated audiences: OpenID Connect is a technology that lets you use an account that you already have to sign up, sign in, and bring your profile, contacts, data, and activities with you to any compatible site on the web.
• for techies: OpenID Connect is OpenID rewritten on top of OAuth WRAP using service discovery to advertise Portable Contacts, Activity Streams, and any other well known API endpoints, and a means to automatically bootstrap consumer registration and token issuance.

At one point in our discussion, I suggested that an HTML tag for a person might make sense — with the ability to include a person’s face or list of friends — without the need for services like Facebook or Twitter. This idea was inspired by Mark Pilgrim’s retelling of the origin story of the <img> tag and conversations I’ve had recently with Michael Hanson of Mozilla (who wrote up a concept for supporting WebFinger in the browser after discussions at IIW).

Our conversation goes on around 15 minutes but does a decent job of capturing my current thinking on the social web.

I’d also like to point out that an OpenWebCampHelsinki is happening this weekend, in case anyone happens to be passing through Finland!

Earlier today, Rob Dolin announced the launch of additional sources of activities for Windows Live users — including MySpace, Hulu, Skyrock, and SlideShare.

Writing on the Windows Live Services blog, he outlines the premise behind the Activity Streams effort (emphasis original):

With today’s latest partner integrations on Windows Live, we’ll have over fifty web activities that Windows Live customers can add into their Windows Live experience. (To learn more about all the Windows Live partners, check out our Windows Live Team blog). Nearly all of the web activities employ a polling model where a customer enters some basic information about their presence on a website and then Windows Live periodically polls an XML feed of the customer’s activity on that site. In the past, this feed has been in RSS 2.0 or Atom and then for each partner, we have a custom XSLT that maps the elements from the customer’s feed to the data attributes in Windows Live’s system.

Challenges with Web Activities

There are two big challenges with this basic polling model of RSS 2.0 or Atom:

1. We need to develop a custom mapping for each partner
2. Each partner needs to have only one activity type or they need a way to communicate what type of activity each RSS 2.0 <item> or Atom <entry> is.

The emerging Activity Streams open standard comes in to help solve both of these problems.

How Activity Streams Help

Activity Streams help to address both of the above issues. First, instead of having to do a custom mapping for practically every Web Activities partner, with an open standard like Activity Streams, we can build a single mapping that can be used by multiple partners.

Second, Activity Streams includes <activity:verb> and <activity:object-type> elements so we can identify that one is a status update and another is a blog entry. Thus, services that have multiple activity types (like MySpace) can have a single feed that includes photos, status, blogs, music, and more.

This maps directly to my motivation in starting this effort, back in June of 2008:

The basic premise is this: lifestreams, alternatively known as “activity streams”, are great for discovering and exploring social media, as well as keeping up to date with friends (witness the main feature of Facebook and the rise of FriendFeed). I suggest that, with a little effort on the publishing side, activity streams could become much more valuable by being easier for web services to consume, interpret and to provide better filtering and weighting of shared activities to make it easier for people to get access to relevant information from people that they care about, as it happens.

By marking up social activities and social objects, delivered in standard feeds [...], we enable anyone to run a FriendFeed-like service that innovates and offers value based on how well it understands what’s going on and what’s relevant, rather than on its compatibility with any and every service.

We’ve come a long way since then — and the acquisition of FriendFeed only helps to reinforce the timeliness of this work.

It’s also been incredibly gratifying to see people like Rob and Monica Keller devote so much energy (see MySpace’s activity streams docs) to helping this effort get off the ground. Maintaining the momentum of this project has been challenging at times — considering that Mart Atkins (author of the Activity Streams specs) has a full time job at Six Apart and David Recordon (my other cohort) just left there to go work at Facebook (where Jerry Cain has been key in getting Facebook to adopt activity streams).

Seeing large players adopt the activity streams format is good for the open web ecosystem. It’s good for individual choice and for enabling market-based mechanisms that encourage competition and good behavior. It enables the decentralization of reading and publishing, and provides individuals with a record of both what their friends are doing as well as what they themselves have done. And these things are all good for the development of the people-centric social web.

This post is a collaborative essay written by Jyri Engström and myself, edited by Brynn Evans and originally posted to the ArcticStartup blog on September 11, 2009. Thanks to Brad Fitzpatrick for his comments on the draft.

·   ·   ·

Around 2003, things began to change.

Technology was then the black sheep, having left overnight millionaires destitute and without change to afford their $4 lattes. Even the posers had left San Francisco and gone back to suburbia to be office managers at Walmart.

It was a sad time for everyone — that is, except the die-hards and the hackers. The web for them had never been about making money, but about reshaping culture and toppling the old order. 2003, therefore, was the perfect time for a resurgence: the people who kept pushing on in the Valley and elsewhere were a concentrated motley crew of innovators and builders. They cared about technology for technology’s sake and about developing and advancing web culture.

What they didn’t realize, however, was that the services and technologies that they were destined to build would need to be cobbled and sewn together using a system that would fight them every step of the way — not out of spite — but because of its architecture. By definition the network available was decidedly anti-human: in 2003, there was only the document-centric web.

The document-centric web

We’ll spare you the history lesson of the origin story of the internet, but suffice it to say, the web we have today is because a bunch of scientists, academics, and government folks needed a way to share static documents — not set up identities or have a dynamic conversation in public. The net was decidedly antisocial and anti-serendipity, from the beginning.

Keep that in mind when you consider what happened around 2003: masses of people started blogging, publicly. Services like Blogger and TypePad surged; LiveJournal and WordPress started to grow stubble and Drupal emerged from a college dorm. In the absence of innovation since the bubble burst, people started to realize that the web could be a place for personal expression and public conversation — and blogging became the “it” thing to do.

The problem was that tools were built around the document model of publishing. Many people maintained collections of blogs that they kept handy as bookmarks — and visited regularly, sometimes several times a day (depending on the prolificness of a given blogger). The more savvy audiences discovered desktop feed readers that fetched new content automatically. But conversation was fragmented and inconvenient: to comment, you had to visit the publisher’s blog and create a single-purpose account there; to post an original response, you had to have your own blog and know how to send a trackback to the post you were responding to.

The pace was slow and cumbersome, but most early bloggers didn’t mind. Their new medium was exciting, expansive, and controversial. And for the time, it fit the write-print/publish model many people had become familiar with thanks to Microsoft Word and other text editors — and which was in turn rewarded by Google’s link-based approach to search.

But two things were lacking in the first generation of Web 2.0 tools: personhood and aggregated conversation streams. The document-web hadn’t made room for people-friendly affordances like “faces,” and didn’t conform to our restless animal brain, which is well suited to working with a flow of short snippets of information.

Proprietary, real-time platforms

Enter: the real-time web. If 2003–2006 could be defined as the emergence of social media on infrastructure still dominated by the document-web, 2007 through the present will be defined as the transition to the “real-time” web, even if through a proprietary side-road.

We’ve had chat, SMS, and other forms of asynchronous (near) real-time data streams for some time. But, just as blogging did to email, every new generation is about pushing down the walls that cage one-to-one and one-to-few interactions, turning the same private publishing tools into many-to-many-to-many-more public publishing platforms. Emphasis on the noun: from tools to platforms.

The catch? This real-time web is not mature yet, since the platforms that sequester all of our activities today are proprietary ones like Facebook and Twitter. These are convenient, to be sure, but of limited utility to users with cross-site ambitions, who require interoperability.

While “brand-mediated” profiles and relationships may not seem completely odious on the surface, there are four major drawbacks to keep in mind:

• Tying one’s identity and communications to a single silo means relying on a single point of failure, degrading the overall reliability and stability of the system. (Remember the failwhale and efforts to keep Twitter from going offline during the Iran uprising, for example).
• Handing over management of one’s identity to a company means being dependent on their decisions and priorities. (Consider the 5,000 friend limit on Facebook; Twitter’s arbitrary suggested users list; and examples of users being ousted from various services for controversial reasons).
• A web built on top of a few proprietary platforms means less diversity and ultimately smaller scale than a web built on non-proprietary protocols and standards (consider how useful email, the web, and the internet itself became once open standards for interoperability were adopted, and the power of “small pieces loosely joined“).
• And finally, on an ethical and emotional level — it just doesn’t feel right.

Fortunately, there are a number of initiatives that are gaining in popularity and finding pockets of adoption throughout industry, leading us to a juncture, where in one direction is the status quo and in the other is what we call “the people-centric (real-time) web”.

The people-centric (real-time) web

If the document-centric web was dominated by static pages, then the people-centric web is about placing you at the center (as Time Magazine did famously in 2006). We’re seeing the rise of dynamic, portable friend lists and non-brand-mediated identities that can be used across a range of standards-compliant websites. People are beginning to move freely between silos. Individuals are increasingly able to bring their data with them and substitute one service or service provider with another, as one can switch between Outlook and Thunderbird for email, or Photoshop and Pixelmator for image editing on the desktop. Relevant information and friends’ activities are starting to come to users via distributed push publishing. (Thomas Vander Wal has called this the “come to me” web).

Let us briefly describe the key enablers of this emerging new phase:

Portable profiles means that instead of creating an account on each service you join, you can now host your identity in one place and bring your profile and friends with you to other sites as you surf the social web. Webfinger, OpenID, Portable Contacts, and OAuth all make this possible (and for bootstrapping profiles from the legacy document-web, we have Google’s Social Graph API).

Distributed push publishing means there is no longer a need to rely on proprietary platforms. The emerging standards here are PubSubHubbub (PuSH) and rssCloud (see comparisons on TheNextWeb and TechCrunch).

Synchronized conversation threads means that users can participate on the same conversation thread across multiple interfaces and services (we are still waiting for a standard, for which various geeks are actively devising a plan).

Much work remains to make cloud services fully interoperable, but the foundations are in place to turn the web into a truly people-centric place. This call to action goes out to developers, corporations, and individuals alike. Best of all, it’s not that hard to start supporting these efforts:

Let people use existing accounts to sign in and sign up for your service. First, the signup ritual offers the least amount of value to users so get it out of the way as fast as possible! Plus, it’s an automatic barrier to entry — you’ll see an increase in successful signups by reducing the friction in logging in up front (as Plaxo did). Second, unless it’s core to what you do, this will also save you the chore of managing profiles on your service. Third, people have so many profiles these days, they can’t keep track of them and they certainly don’t want to be creating yet another. Instead, figure out a way to subscribe to someone’s existing profile — and keep a reference of it up to date on your site.

Sharing information and activities from your site is how other people will discover you. Stickiness as a business practice was a byproduct of the document era of the web; on the people-centric web, portability is critical. Data, identities, relationships, and activities need to flow between sites in order to expose insights, spread knowledge, and engender meaningful social interactivity. This sounds complicated but is relatively straightforward. To begin, your site can make available atomic units of data, exported as streams of activity that indicate who acted in which way upon what object. It’s easier than it sounds and formats are available to support this modular approach (see: Activity Streams)

As a user, consider how much control and security you really want over your online identity. How do you feel about leasing an identity from a web brand? Unsure about the benefits of owning your own? Some providers (Google, Yahoo, Flickr, MySpace, AOL) let you use their accounts as OpenIDs — a great step towards portability, and beneficial to everyone. The catch with any leased identity is that your identity will be under the provider’s brand, profile constrained by their design decisions, and personal data subjected to their terms of service. As an alternative, acquiring your own domain and setting up your own profile with an independent is becoming much easier with free services like Chi.mp and hi.im. More innovation is needed in this area to make independent identities for people and organizations first class citizens on the social web, and their setup and management simpler, accessible, and secure!

What’s yet to come

It’s 2009, going on 2010. For the past three years, the web has been morphing into a real-time and people-centric place. We’ve seen this trend among individual users — through their actions and demands for better social experiences — but also increasingly among companies and developers. We want a web that’s more “like us” than the old model was. We want a web where people are as important to the architecture of the system as documents.

And with this new model come new opportunities for innovation and personalization. It is possible to build applications for participating in decentralized conversations around various ideas and trends. This presents a new opportunity for identity management apps, community sites, social dashboards, real-time search, messaging hubs… and even browser makers, hardware manufacturers, and ad networks. Mobile platforms are also growing, as people connect over non-desktop devices. These small handheld technologies further underscore the importance of portable identity, microcontent, decentralization, and (near) real-time delivery. A document-centric approach just doesn’t make sense in a mobile world, and with new ground being broken in fields like augmented reality, demand for increasingly rich social experiences powered by open standards instead of proprietary platforms will continue to grow.

But consider the future: the benefits of a people-centric model are still evolving and remain to be fully realized. It’s critical to not be complacent with the platforms we’ve grown so accustomed to. If you wear the developer’s hat, now’s the time to get on board, read the specs, and implement support for OpenID, Activity Streams, OAuth, PubSubHubbub/rssCloud, or the other mentioned open standards that are relevant to your users. If you are a user, don’t be afraid to be vocal and ask the services you love to show they love you back, by giving you the rights to your data and the tools to take it with you elsewhere. If you’re a business, realize that the distributed potential of the social web has barely been tapped, and that you have a choice between (as Robert Scoble calls it) gifting your branding power to someone else, or leveraging these standards to turn your own site from an island to a node in a network of social activity as wide as the web itself. In the end, the internet as a whole will be better off if we stay in control of our own destinies.

·   ·   ·

Jyri and I will be presenting a workshop on this material during our MindTrek pre-conference tutorial on September 30th in Helsinki. Early bird tickets are still available at a discounted rate; register today!

Also, don’t forget you can still register for MindTrek, the Nordic conference on social media (Oct. 1st–2nd) in Tampere, Finland.

The workshop will start with a synthesis of several of my past talks on the social web.

It’ll cover an abbreviated history of social networking as background for what’s happening now — and lead into a framework for understanding what’s about to happen on the web as it becomes more social based on identity, relationships, and activity streams.

From digital identity to social objects, I’ll dig deeper into emerging technologies like OpenID, OAuth, Portable Contacts, Activity Streams and microformats, and take a look at bleeding edge protocols like WebFinger and PubSubHubBub. I’ll also spend time with the OpenSocial and Facebook platforms.

And though the specific technologies are important, I do want to make sure that attendees leave with an integrated, holistic view of how the open social web operates, is changing, and how it can be used to reach a wider audience and enhance community engagement. I expect that that’s one of the things that will set this workshop apart — providing a more accessible approach to ideas that can sometimes seem obtuse or obscured by jargon or technical terms. Given my background in user experience design and various marketing projects, I’m quite confident that I’ll be able to offer a unique and accessible perspective backed up with real world experience.

The workshop will be held on September 30, from 9am to 4pm. Basic refreshments — coffee and snacks — will be provided. The exact location is still being worked out, but it will be somewhere convenient in Central Helsinki (the MindTrek conference is actually two hours away in Tempere).

I’m open to bringing the workshop elsewhere or taking it to private companies who are looking for a more intimate, personalized experience while I’m in Europe. If you’re interested or want to learn more, do contact me.

“Brand-mediated identity” in and of itself isn’t bad. In fact, it’s a choice — one that I argue shouldn’t be made unconsciously or involuntarily (but all too often is because obvious or viable alternatives aren’t available).

Indeed, people mediate their online identities through brands all the time — the latest example being the “Madmenize” app that replaces your Twitter avatar with a cartoon head from the acclaimed Mad Men series. This kind of mediation happens with increasing frequency on Twitter, where identity is fluid and often the sum of a tweet, an avatar and a username. Renny Gleeson has even started cataloguing these “icon memes” — they’re that frequent.

But today I came across a truly inspirational approach to brand-mediated identity that portends great potential for OpenID and for brands generally — especially those with eager and adoring fans:

What better way to both support Creative Commons and show off your patronage than by identifying yourself across the web with your very own unique, secure, privacy-protecting creativecommons.net OpenID (just like Zach Beauvais)?

For a mere $50 minimum donation ($25 for students), you can own a limited edition URL and profile from Creative Commons that identifies you to the world and provides a compelling revenue opportunity for the non-profit foundation.

While companies like SAP become OpenID providers for pedestrian reasons like simplifying authentication across their many different distributed web properties, Creative Commons is redistributing the brand equity and social capital their members have accrued over the last several years by letting people show and verify their affiliation to the organization.

With this simple example, we can start to see the symbiosis of making an intentional choice about identity: Creative Commons finds a new revenue opportunity and members of the community have a way to express their affiliation and promote the brand. This is exactly the kind of thing that I could see the NYTimes doing for its writers (as an extension to its Times People platform) — providing them both a home on the web and a way to validate their association with a more well-known entity. This of course is just a small experiment for Creative Commons — but a very exciting one in terms of what it means for identity on the web.

On the one hand, I was sickened by the lack of analysis from the echolalic blogger news corps. It appeared that Opera PR had successfully reached out to all of them, shoved a news release down their throats and waited to give them the go-ahead to regurgitate it on their blogs, using the same screenshots, same content, and differing only in the pithiness of their post titles.

Of course, I could have gotten the same depth of analysis from half a dozen tweets.

Maybe they long ago wrote off Opera and aren’t interested in providing any kind of depth of insight but whatever, who knows — the nouveau press corps blew it. Social media proves its vapidity once again.

But, I digress. I’ll tell you what I think, since there’s a lot in the details of Opera’s announcement that bear inspection, even if I’m the only one to do it.

I’m going to talk about six topics:

• What is Unite?
• The Marketing Pitch
• Why isn’t Opera open source?
• Is Unite really decentralized?
• Owning Your Namespace
• Unite & Activity Streams

Let’s get to it.

What is Unite?

Like Flock before it (Disclaimer: okay, I’m just stroking my own ego here. Note to self: get over yourself), Opera is attempting to take advantage of the rise of social networking (the verb) and bake it into the browser, as a personal extension to one’s computing experience.

They accomplish this by embedding what amounts to a web server in the browser, and making it possible to share files, music and photos and to post notes or chat directly with your friends (or anyone who knows the URL to your account and in some cases, has the right password).

You can download an Opera Unite alpha build to try it yourself.

The Marketing Pitch

The marketing hype for Unite started recently, with a bright red page (above) hosted at opera.com/freedom. Of course this inspired a bit of buzz, and Kas Thomas from CMS Watch even guessed correctly what it was all about:

Folks, let me tell you what’s going to happen. I have a pretty strong hunch (but no inside info, I assure you) on this one. This is something I’ve thought about for years — it has needed to happen for years — and I’ll be thrilled if Opera pulls it off, although whether people will flock to adopt it is another question.

The answer is that Opera is going to embed a web server in itself.

When you fire up Opera, you’ll be operating a secure server and you will be able to serve all kinds of content (whatever you want, basically: bookmarks, contacts, cached content, arbitrary files from a roped-off area of your local storage, web pages of your own) to other Opera users, at the very least, and maybe all browser users, at the very most.

The mystery seems to have paid off, as Unite is topping Techmeme today.

They released a stylized video explaining Unite, remniscent of the Data Portability promotional video from several months ago:

What I find so fascinating about this marketing message is that it presumes that owning one’s own data and “connecting directly” with friends is somehow relevant to people — as though it’s a big problem that people have been complaining about for years, and that Opera has finally answered the call.

But I think they’re missing the big picture here — or intentionally obscuring it — which is that, while the idea of owning your own data may be attractive to neo-libertarians and open source geeks — most people really don’t care and are happy to outsource storage of their data to someone else who can be responsible for backing up their data and fending off hackers. 200 million Facebook users can’t be wrong, right?

People have embraced social networks because they make it easy to share and collaborate using the browser that they already have — and answering the question: “what do I do with all these stupid digital photos sitting idly on my harddrive?”

Let’s face it, bookmarks were pretty lame before we could peak over our friends’ shoulders at what they were reading.

So while Opera is right to seize on to the social networking meme, they’re doing so largely to increase the waning relevance of their browser — not to support freedom as they claim — especially at a time when Google’s Chrome and Apple’s Safari have entered the ring as the new twin contenders for the browser crown (even though no one knows what a “browser” is).

Furthermore, their whole pitch about owning your own data and disintermediating the large social networks will likely resonate much more with a European audience (i.e. one that would give 7.1% of their vote to the Pirate Party) than a mainstream, social network-obsessed American one.

If you consider how Lawrence Eng (Opera’s product analyst) puts Unite into context talking about “the Internet’s unfulfilled promise”, you’ll see what I mean:

Our computers are only dumb terminals connected to other computers (meaning servers) owned by other people — such as large corporations — who we depend upon to host our words, thoughts, and images. We depend on them to do it well and with our best interests at heart. We place our trust in these third parties, and we hope for the best, but as long as our own computers are not first class citizens on the Web, we are merely tenants, and hosting companies are the landlords of the Internet.

Social networking is important, but who owns it — the online real estate and all the content we share on it? How much control over our words, photos, and identities are we giving up by using someone else’s site for our personal information? How dependent have we become? I imagine that many of us would lose most of our personal contacts if our favorite Web mail services shut down without warning. Also, many of us maintain extensive friend networks on sites like MySpace and Facebook, and are, therefore, subject to their corporate decisions via “Terms of Service” and click-through agreements. Furthermore, what does it mean anyway to be connected to hundreds of our “closest” friends? What about our real social networks, the people we want to interact with on a regular basis (like once a week, or even every day)? Why are online solutions to help us with our real-world social needs so few and far between?

We are connected to a Web that has democratized much and is an amazing source of information. However, “the wisdom of the crowd,” along with the notion that our data ought to live on other people’s computers that we don’t control, has contributed to making the Internet more impersonal, anonymous, fragmented, and more about “the aggregate” than the individual. In fact, quite the opposite of the original promise. For too long, we’ve been going online to connect to each other, but sacrificing intimacy as a result.

With Opera Unite, I think we can start moving in a different direction.

Now, it might sound ironic coming from me that I think Opera was wrong to paint their pitch with the paint of libertarian ethos, but if they’re going to succeed, they have to go beyond “owning your own data” to talking about why owning your own data is better or easier. Philosophical rhetoric will only get you so far, as I’ve learned.

Speaking of…

Why isn’t Opera open source?

So, with all that raging neo-libertarian angst, why isn’t Opera open source?

Quite frankly, I have no fucking clue. And with Webkit giving everyone — including Mozilla — a run for dominance over the personal viewport to the web, I simply don’t see why anyone would build on the Opera platform (albeit, their platform is largely the web — though their rendering engine remains proprietary).

Could it be failure of imagination? Is it that Opera hasn’t figured out that the future of the web is in hosted and delegated services? Or, is it that they did figure that out, but desperately want to defeat that future in order to write an alternative future with their browser at its center?

In 2006, Opera didn’t see a business model for open source browsers. Little has changed since then, except that they now have three formidable open source challengers to contend with that have shipped “cloud services”: Mozilla Weave, Google’s Apps and Apple’s MobileMe.

So, although you can build widgets for Opera Unite, you’re still relying on a third party to stay in the room with you… namely, Opera. And Opera isn’t exactly an organization that has behaved favorably towards the open source community in the past. Though that seems unlikely to change, it still begs the question why they believe there is more value is staying proprietary than opening up their browser to outside contributors.

Still, regardless of the decision that they make for their business about open source, there’s a bigger elephant in the room that needs to be addressed:

Is Opera Unite really decentralized?

Opera’s CEO Jon von Tetzchner claims that “Opera Unite now decentralizes and democratizes the cloud”, illustrated like this:

I call bullshit.

Opera Unite does indeed rely on a P2P-like network to function, but the big problem is that you must push all your traffic through Opera’s proxy service:

Not exactly “decentralized” (more on this in the next section).

Furthermore, if you read through the Opera Desktop End User License Agreement (which you had to if you installed the browser — shame on you if you didn’t!), you would have read section 7: USE OF SERVICES (emphasis mine):

Opera Unite and Transmission and Receipt of Content: Certain features of the Software and Services, including Opera Unite, may allow you to post or send content and/or links to content stored on your computer, that can be viewed by others (“User Generated Content”). Opera Software ASA exercises no control over User Generated Content passing through its network or equipment or available on or through the Services. You agree that Opera Software ASA is not liable for any loss of data. YOU MAY ONLY POST OR SEND USER GENERATED CONTENT THROUGH THE SERVICES THAT YOU CREATED OR THAT YOU HAVE PERMISSION TO POST OR SEND.. You agree not to use Opera Unite to upload, transfer or otherwise make available files, images, code, materials, or other information or content that is obscene, vulgar, hateful, threatening, or that violates any laws or third-party rights, hereunder but not limited to third-party intellectual property rights. We do not claim ownership of any User Generated Content. However, by submitting User Generated Content to us, you grant us and our affiliates the right and limited license to use, copy, display, perform, distribute and adapt this User Generated Content for the purpose of carrying out the Services.

You agree that we are not liable for User Generated Content that is provided by others. We have no duty to pre-screen User Generated Content, but we have the right to refuse to post, edit, or deliver submitted User Generated Content. We reserve the right to remove User Generated Content for any reason, but we are not responsible for any failure or delay in removing such material. We reserve the right to block any user’s access to any content, web site or web page in our sole discretion. Opera Software ASA reserves the right to terminate your account if you use your account privileges to unlawfully transmit copyrighted material without a license, valid defense or fair use privilege to do so.

Disputes may arise between you and others or between you and Opera Software ASA related to content or commerce, including User Generated Content. Such disputes could involve, among other things, the use or misuse of domain names; the infringement of copyrights, trademarks or other rights in intellectual property; defamation; fraud; the use or misuse of information; and problems with online auction or commerce transactions. You agree that all claims, disputes or wrongdoing that result from, or are related in any way to, the content of information that you post, transmit, re-transmit or receive through the Services, Opera Software’s network or Software are your sole and exclusive responsibility. Opera Software ASA may at it’s discretion, block certain web sites or domains and re-route you to other pages. By accepting these Terms of Use, You hereby consent to this.

Besides this hands-on approach to their centralized proxy service, Opera also reserves the right to filter the apps that you can install, a la Apple and their approach to the AppStore (because everyone wants an AppStore, right?):

What are the guidelines for approval of an Opera Unite Service?

These are some of the guidelines that apply to services:

• The service must have a sensible name and description
• The service must not have obvious bugs, so ensure that you test it before uploading
• The service must not contain malicious or destructive code
• The service must not contain or use copyrighted information for which you do not hold the rights
• The service must not contain or point to adult or hateful content
• The service should comply with the Opera Unite Service UI guidelines. Any reason for diverging significantly from the guidelines should be documented in the submission
• The service should serve standards-compliant HTML pages that are viewable in all modern browsers on a variety of devices.

I fail to see how this changes our reliance on “large corporations — who we depend upon to host our words, thoughts, and images” of whom Lawrence Eng spoke so disparagingly.

Owning Your Namespace

So, if it isn’t enough that you have to tunnel your connection through Opera’s proxies and place your service’s existence at the mercy of Opera’s filters, they also want to own your identity, something that everyone also wants to do lately.

In order to use Opera Unite, you have to have a my.opera.com account — perhaps not a big deal until you realize that you’ll be assigned a URL like http://notebook.username.operaunite.com/ to access your “self-hosted” outpost on the web.

Chris Mills, Opera’s Developer Relations Manager, explains:

To use Opera Unite Services, you need to log into Opera. This is the same login that you use to log in to My Opera, Dev Opera, or Opera Link.

…

Choosing an Opera Unite name for your computer

This name is basically your computer’s identity on the Opera Unite system — this is the URL that your contacts can go to if they want to make use of your Opera Unite Services, and share them with you.

So, while it’s true that your friends can access your Opera Unite homepage without an Opera account, if they want to host their own Unite server, they’re going to have to both download Opera and obtain an Opera account (and no, they don’t support OpenID).

While there are technical reasons why this makes some sense (mostly to make it easier to get things up and running), it contradicts the whole promise of obviating central control. Indeed, AllPeers (now defunct) and others offered similar solutions previously. Why did Opera not launch with the ability for me to choose my own URL, or at least mask my homepage URL with something that didn’t tie me to Opera…? Oh yeah, that’s right — it’s all about owning the namespace.

At least Google was smart enough when they launched Wave to build in true decentralization from the start, and to choose a patent license for the Wave protocol that demonstrated that their desire was not to own the network, but to compete on it.

Unite & Activity Streams

Now, I know I sound like a curmudgeon, but I’m mostly just disappointed that few other people took Opera to task over the reality distortion field that Opera’s PR machine generated around this technology launch. But, as someone in the office said to me today, maybe no one cares enough about Opera to bother. Yeah, exactly, like I said before.

Still, there is a silver lining to this cloud computing fiasco which NO ONE else covered: Opera Unite supports activity streams!

It turns out that tucked within the Opera application is a directory called “unite” (on the Mac you can find it at Opera.app:Contents:Resources:unite) which contains a bunch of files with the .us extension (presumably for “Unite Service”). Like Mozilla .xpi files, these .us files are just zip files and can easily be decompressed by changing the extension.

In just about every bundle, there are several pertinent JavaScript files either in a folder called “asdstream” or with “activityStream” in the filename. The one that’s most interesting to me is the “activitystreamparser.js” file in the fridge.as bundle, which starts like this:

Now, I’m not sure how this is being used, but I imagine it’s being used to output updates on the personal homepage of the site… which is awesome.

I wish that Opera had reached out to the Activity Streams mailing list about this work, but I can also understand that they probably didn’t want to jump the hype stungun. Anyway, it’s a huge opportunity (in my eyes!) for them to join the discussion about the open social web (since they have been essential proponents of web standards on the open web to date) and I invite them to share their goals and ideas for this work.

Conclusion

Okay, so I shit all over Opera Unite, but you can’t come out and promise all kinds of world-changing, freedom-enhancing goodness and then not deliver! — worse, to do so when their newest competitor (Google!) is schooling everyone with the perfect example of how to do it right (see: Wave).

While I have problems with Opera’s marketing approach, I do think that it’s useful to have Unite in the marketplace so that I can point to it as an example of what I want to see happen with the Diso Project — though I’m not willing to rest my success on the fate of any particular browser.

Through a combination of technologies like OpenID, OAuth, XRD, Portable Contacts, Activity Streams and microformats, we’ve been moving in this direction for some time, without having to alter the browser. Of course that’s meant that the browser has been conspicuously missing from the conversation, but that too is changing (see Mozilla’s experiment baking OpenID into the browser with Weave), and with Unite, we have yet another vision to contemplate — though I would have loved to have seen Opera embrace more than just Activity Streams out of all the technologies from the Open Stack.

I’ll give Opera some credit — both for using Activity Streams instead of inventing their own protocol — and also for launching a fairly polished demonstration of Unite concept as an alpha. If they really want to offer transformative technologies, though, I think it’s critical that they align their business policies with their marketing rhetoric and technological objectives, down to the code level. Anything less will result in confusion and worse, more posts like this one!

When I was laid off from Vidoop last month, I didn’t so much as tweet about it. The circumstances were different this time. But because the lack of information coming from the company is disappointing (if not frankly irresponsible) it seemed time that I wrote down my recollection of what went down.

Joining Vidoop

I joined Vidoop just over a year ago, in May of 2008.

To be honest, my initial impressions of the company weren’t exactly positive, having first seen Luke Sontag (Vidoop’s co-founder and president, or ” Chief Koolaid Officer ” as he called himself) launch the company with a slick pitch at the Web 2.0 Expo in San Francisco in April of 2007, proclaiming that Vidoop was going to do a rev-share with OpenID relying parties as well as regular users of the MyVidoop service.

I remember muttering to Scott Kveton — friend and chairman of the OpenID Foundation: “Great, someone’s attempting to exploit OpenID already.”

I didn’t think about Vidoop again until February 2008, when I found out that Kveton had joined the company after leaving Strands, a former client of Citizen Agency.

Kveton urged me to reconsider my impressions, suggesting that I fly to Portland in early April and have Luke pitch me on joining the team. Over drinks at Clyde Common, Luke laid out his grand vision for the company and invited me to come work full time on the Diso Project under Vidoop’s stable. Considering the difficult changes I was going through professionally and personally, it seemed like a great opportunity to throw myself into my work without having to worry about finding new clients for a while.

So, with Kveton’s encouragement, I accepted their offer, pulling in Will Norris and announcing the news a month later — news that was met rather warmly.

I would work remotely from San Francisco with Will — our work on the Diso Project helping to raise the visibility of Vidoop in the open source and identity arenas — while Vidoop’s efforts would increase the relevance of strong security in consumer applications built on a raft of open standards, like OpenID.

The Oregon Trail

A month after I joined, I took a trip down to Tulsa to meet the crew for a company all-hands and get a taste of life in the wild wild west (as Luke called it).

I was surprised at the size of the company (around 40 at the time) and the feeling of familiarity ( in the “familial” sense ) among the employees — clearly these folks cared a great deal about each other and what they were doing and were eager to prove to the world that Oklahoma could product high-tech stars too.

The contrast between my initial impressions of Luke’s slick stage presence with the down-to-earth candor of the developers and rest of the company left me positively charged and ready to contribute. There was a lot of heart in the company; perhaps I had judged too hastily?

Joel Norvell — the unassuming CEO and one-time ballet dancer and former chairman and CFO of a jewelry manufacturer — surprised everyone, standing atop a stump to declare that the company would be relocating to Portland. The company would offer assistance for the move, taking care of various expenses and working with families to smooth out the transition. I was impressed by the amount of help offered to the employees — a level of hands-on support that I’d not seen at any company that I’d worked with. It gave me pause, considering the magnitude of asking some 40-odd folks to uproot their families and move across the country to follow a dream: “Would this actually work?”

As it turned out, this was not the first time that moving the company had been proposed. In fact, Luke had enthusiastically suggested a number of other possible destinations, only to be turned down by his more even-keeled CEO. This time, however, with Kveton on board as the resident “Portvangelist“, Luke succeeded.

The plan was to spend the summer finding housing and making arrangements and then leave in September, following the route of the original Oregon Trail in a train of rented campers and U-Hauls, recording, blogging, tweeting and podcasting the hell out of the whole ordeal (Silicon Florist coverage 1, 2 and 3 ) — culminating with a parade down mainstreet in Portland and a greeting from the mayor.

View Larger Map

Though thankfully no one died of dysentery (in spite of a few “unforeseen detours”), it turned out that the parade and mayoral greeting were just the beginning of several oversold and underdelivered promises from management.

Shiny, shiny things

Turned out that uprooting and transplanting an entire company from the middle of the country to the west coast is more costly than one might otherwise think.

The decision to switching from PHP to Python also had its costs, primarily on developer focus (even if the decision played to the strengths of the dev team). Between the upheaval of the move and switching development modes — the team lost a lot of time, resulting in missed deadlines, unfinished projects and lost contracts.

Merely two months after cozying in above Backspace in Portland’s Old Town, Vidoop announced “changes” — a euphemism for layoffs.

Blaming the economy, Vidoop shed 11 employees. Blogging as CEO, Joel prudently pledged to “concentrate on those areas that make the most sense in this economy.”

As part of the changes, they also cut me back to half-time — leaving me with rent money, health insurance and a shaky future with the company.

With a new emphasis on product, my work on Diso was scaled back and I was tasked with redesigning the company website, working on the UI for VidoopSecure and helping to architect the user experience for the-silently-launched VidoopConnect product (now defunct).

I traveled to Portland several times during the winter and spring. We were making considerable progress with a renewed sense of urgency and will to execute. The VidoopConnect team in particular, lead by Adam Lowry and Michael Richardson, was firing on all cylinders.

Some time in February, however, the focus again began to blur.

On top of the other half-finished products in Vidoop’s quiver, VidoopCAPTCHA was introduced a lightweight mechanism to promote the ImageShield — as well as attempt to dethrone ReCAPTCHA. Development on VidoopConnect ceased. Will Norris was reallocated to VidoopCAPTCHA and implemented a plugin for WordPress while the rest of the team produced an API and web service.

The shift from VidoopConnect was abrupt and unprecedented: just one more example of the chaos of Vidoop’s product strategy.

Now, I haven’t yet mentioned MyVidoop, Vidoop’s much-loved consumer OpenID provider and browser-based password manager. That’s largely because it too was deprioritized around the time of the first layoffs — kept alive on little more than life support. In some ways, the fate of myVidoop is both emblematic of the lack of focus and thorough execution that I believe contributed greatly to the fall of Vidoop, and remains one of the more problematic pieces of this story (more later).

The beginning of the end

This past March, I paid my own way to SXSW. Meanwhile, Vidoop picked up travel for Kveton (by now some kind of VP of Engineering Open Technologies), Sontag, Matt Selbie (VP of Marketing), and Scott Blomquist (CTO) who all shacked up in some sweet pad somewhere outside downtown Austin.

At BarCampAustin, Kveton presented on Bacn.com, a scrappy side-project he’d launched with Richardson that — get this — sells real bacon — and that took off with a life of its own. Turned out Vidoop didn’t take too kindly to Kveton telling the story of Bacn when he apparently should have been pimping their tech.

Upon returning to Portland, he found out that he’d been fired.

This was — for me as I’m sure for others — the beginning of the end.

Since Kveton had been helping to coordinate my work on the Vidoop side of things, I lost my representative at the company. Though I kept in close contact with a number of the developers, I ended up busying myself with speaking, traveling, and evangelizing OpenID on the road.

And then came the rumblings of financial problems. On April 15, I received word that the company was about to close a major round of funding — and just in time, too, because Vidoop had failed to make payroll.

Two days later — April 17 — I was in Sebastopol at Social Web FOO Camp when I received a phone call from Wiley Parsons, Vidoop’s CTO, with instructions to cut up my company credit card.

My first thought was that Vidoop had been sold, an idea later dismissed. To this day, I’m still not entirely sure what happened, but it was obvious that things were being kept together with chewing gum and shoelaces, threatening to split apart at any moment.

The final straw

On May 11, I was in Paris in the middle of a trip bookended by speaking engagements in Hamburg and Belgium. Luke messaged me, requesting that I call him ASAP. When I did, it turned out that Vidoop was out of money, unable to make payroll again. All but a skeleton crew remained. Luke assured me that he was going to keep fighting — attempting to sign some final deals to save the company. He promised to share more information by the end of the week but the only public statement that’s been made to date was a mealy-mouth blog post with no discernibly useful information whatsoever.

Two weeks later, Joel sent out what appeared to be heartfelt last rites for the company, again lacking any actionable information. A day later he clarified things, posting to Vidoop alumni mailing list that, “Vidoop LLC is officially out of business. Unfortunately, there are no funds to pay the unpaid wages or other liabilities.”

This was the memo that leaked to TechCrunch.

During the last two weeks of May, there were two parallel tracks of activity — segmented into those left fighting for whatever was left of the company — and those who’d been laid off. The unemployedstruggled to find new work, attempted to secure new Visas, grappled with the arcane unemployment and healthcare systems, and tried to pry more information from the company; others called it quits and moved back to Tulsa.

Those left fighting for the company — Luke, Blomquist, and Selbie — have provided strange accounts of what they’re doing to try to rescue the firm or — apparently — start something new.

There’s been no public acknowledgement of the situation, either on the company blog or on Twitter, save for this melodramatic post (presumably from Luke): “dead, no. bloody, yes. still got fight left. details soon…”

The media and wider community have been left to their own devices (and Arrington’s original post) to fill in the blanks. With no information forthcoming from the company, it’s impossible to know what to plan for, or what the fate of services like MyVidoop will be.

OpenID, myVidoop and unfulfilled promises

I’m writing this post not because I’m bitter — most startups fail and I knew this when I joined the company — but because the lack of information coming from Vidoop has been irresponsibly minimal — both publicly and privately. Vidoop has failed to speak clearly and consistently to the community that it pledged to serve and secure, and it has failed to produce definitive information for the staff that risked much and poured themselves into the company.

The failure of Vidoop was a failure of business and focus, not technology. It’s as simple as that. And yet, with the company out of business, those responsible for communicating clearly and transparently about the health of the company are failing to do so.

This is bad for several reasons. Among them:

1. First, those who continue to use MyVidoop have not been told what’s going on or planned for the service, and can therefore not make an informed decision about whether they should continue using the service. If they do — with the presumption that Vidoop is solvent — they may well end up locked out of not only their MyVidoop accounts, but also the accounts that MyVidoop holds the keys to.

   None of MyVidoop’s Terms and Conditions mention the availability of backups or access to data should the service be shut down — nor does it state what will happen to the servers that house personal data should the company file for bankruptcy. These are questions that Vidoop needs to have answers for, along with advice for people that want to leave the service. In contrast, Yahoo has taken aggressive steps to notify people a full 60 days in advance of the pending closure of the Yahoo! 360 service, providing guidance and tools to export user data.

   I discussed the fate of MyVidoop with Scott Blomquist when I was in Portland for WebVisions. I implored him to issue some kind of public statement about the welfare of the MyVidoop service, but so far he has demurred. He has proposed running the service as a “community project” and has attempted to enlist the help of several ex-Vidoopers, but I’m not convinced that his plan will hold water. Besides the trademark issues wrapped up in continuing to use MyVidoop.com as an OpenID provider, there are various licensing fees associated with keeping the strong authentication services functioning (voice confirmation, SMS-verification); and, even if those services were turned off, running a high-security service as a community initiative just doesn’t add up — not after all the fear-mongering that Vidoop does on its Twitter account!

   The responsible thing to do would be to announce the closure of the MyVidoop service in 30 days (if the servers can be kept running and secured for that amount of time); the “community project” idea should be scrapped in favor of building tools to export people’s data, and if it’s amenable to a company like Janrain, the MyVidoop users could be invited to move their accounts to MyOpenID.com (presuming that Janrain has reasonable data back up, export retention policies!) Otherwise, keeping the service running longer will just invite catastrophe with no one on the payroll to deal with issues related to security or uptime.

2. Second, this whole situation paints a negative caricature of a member of the OpenID community. It’s not the technology that isn’t sound or market-worthy — it’s that perception is oftentimes nine-tenths of the law. Vidoop’s drawn out failure highlights the risk and importance of choosing a responsible identity provider — or of using delegation — the feature of OpenID that lets you use your own domain as your OpenID, but assigns someone else the responsibility of serving your identity. Vidoop’s failure could be seen as a blight on the technology and community if people fail to recognize that the problem with Vidoop was not OpenID, but was the same thing that’s caused countless other companies to fail: the inability to focus and execute in a consistent and thorough manner.

To its credit, in its time, Vidoop assembled a cadre of highly talented and motivated folks who really did want to make their mark on the world, the right way.

Projects like Identity in the Browser (“IDIB”), Emailtoid and EAUT, VidoopConnect, and VidoopSecure exemplied solid and well-engineered solutions and proofs of concept that demonstrated an open, innovative approach to delivering secure solutions to the consumer web. To have those efforts sullied by the incongruous response from management is unfortunate and unfair.

With so much promise, it seems sad that Vidoop could fall so far, so fast.