The portion with my comments reads:

But Google open advocate Chris Messina warns that if Twitter doesn’t handle the new feature properly, it could become a free-for-all of competing standards and markups. “I find them very intriguing,” he said of Annotations, but added: “It could get pretty hairy with lots of non-interoperable approaches,” a concern that others have raised as well. For example, if more than one company wants to support payments through Annotations but they all use proprietary ways of doing that, “getting Twitter clients and apps to actually make sense of that data will be very slow going indeed,” said Messina. However, the Google staffer said he was encouraged by the fact that Twitter was looking at supporting existing standards such as RDFa and microformats (as well as potentially Facebook’s open graph protocol).

Unfortunately some folks found these comments more negative than I intended them to be, so I wanted to flesh out my thinking by providing the entire text of the email I sent to Mathew:

Thanks for the question Mathew. I admit that I’m no expert on Twitter Annotations, but I do find them very intriguing… I see them creating a lot of interesting momentum for the Twitter Dev Community because they allow for all kinds of emergent things to come about… but at the same time, without a sane community stewardship model, it could get pretty hairy with lots of non-interoperable approaches that re-implement the same kinds of features.

That is — say that someone wants to implement support for payments over Twitter Annotations… if a number of different service providers want to offer similar functionality but all use their own proprietary annotations, then that means getting Twitter clients and apps to actually make sense of that data will be very slow going indeed.

I do like that Ryan Sarver et al are looking at supporting existing schema where they exist — rather than supporting an adhocracy that might lead to more reinventions of the wheel than Firestone had blowouts. But it’s unclear, again, how successful that effort will be long term.

Of course, as the weirdo originator of the hashtag, it seems to me that the Twitter community has this funny way of getting the cat paths paved, so it may work out just fine — with just a slight amount of central coordination through the developer mailing lists.

I’d really like to see Twitter adopt ActivityStreams, of course, and went to their hackathon to see what kind of coordination we could do. Our conversation got hijacked so I wasn’t able to make much progress there, but Twitter does seem interested in supporting these other efforts and has reached out to help move things forward.

Not sure how much that helps, but let me know what other questions you might have.

I stand by these comments — though I can see how, spliced and taken out of context, they could be misconstrued.

Considering that we’re facing similar questions about the extensibility model for ActivityStreams, I can speak from experience that guiding chaos into order is actually how “standards” evolve over time. Managing that process determines how quickly an effort like Twitter’s annotations will succeed.

Twitter’s approach of  balancing between going completely open against being centrally managed is a smart approach, and I’m looking forward to both working with them on their efforts, as well as seeing what their developer community produces.

Today marks six five months since I joined Google on my birthday on January 7. It’s been an interesting, busy time for me.

Having never worked for a big company (where I define “big” as having more than 100 employees), working for Google is a lot like moving from the suburbs into a big city — I’m just constantly meeting new people and finding out about stuff I had no idea was going on.

Still, to put things in perspective, Google only has about 20,000 employees, whereas, Microsoft has nearly 100,000 and HP has a whopping 300,000. Those numbers boggle my mind, but are useful to keep in mind when Googlers call their employer a “startup”, unironically.

Speaking of big numbers, Eric Schmidt threw some big numbers around recently about the amount of data being created relative today to the sum total of all data that’s been create thus far. Essentially, since the beginning of time and 2003, five exabytes of information were created; since then, we’ve been creating something like five exabytes every two days (skip to 19:43 in this video to see the actual quote; it of course also makes sense that Google would need to rev its indexing approach to accommodate this influx of data).

With all that data, it occurred to me that I should figure out what my contribution is — not in gigabytes, but in terms of other social media metrics. And given how data-focused Google tends to be, I figured I’d focus on areas of growth.

So in the last six five months, here’s my data:

• New photos and screenshots posted to Flickr: 1,520
• Total screenshot/photo views: 733,121 (via flickrstats)
• New Google Buzz followers:  2,377 (public), 118 (internal)
• New Twitter followers: 2,556 (1, 2)
• New tweets: 1,797
• New blog posts: 13 (including this one)
• New videos: 10
• Total video loads: 68,547
• Total video plays: 3,638
• Interviews given: 7
• Talks given: 6
• Views on slidedecks: 15,296
• Emails sent from my google.com email address: 2,233
• Trips taken: 11
• Countries visited: 2
• Listened to 251 different artists
• Weekly status reports submitted: 22
• Office moves on Google campus: 3

Also, based on my Fitbit weekly averages, I’ve also walked about 1,000,000 steps over the past 152 days (though it’d be so much cooler if they hurried up and offered an API!).

So, not completely exhaustive — and some data was more elusive than other figures to track down — but there’s a snapshot of various metrics from my first six five months at Google.

I highly expect things to only increase their “up and to the right” trajectory from here on out.

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.

Yes friends, I’m turning 29 and I’ve decided to go work for The Man.

In all actuality, I’ve been mulling over such a move for some time, considering a number of compelling opportunities for my next step. After reviewing my options — in light of the progress I’ve made so far and my familiarity and existing relationships with the new team at Google that I’ll be working with — I came to the conclusion that Google offers me the best possible opportunity to continue my work in an environment and culture that is compatible with my outlook, goals, and work habits.

I was trained as a designer, but I’ve been involved with the tech scene since I arrived in Silicon Valley just over five years ago. In some ways, technology has reshaped the way I approach and solve problems — forcing me to think in terms of adoption strategies first, rather than always trying to find the simplest, cleanest design, because of the disadvantaged position I occupied as a non-coder. I can see the consequences of these effects on my approaches first to OAuth, and then to Activity Streams, as well as with OpenID, with positive and negative results. In some ways I’ve had to temper my designer training and put technology first in order to grow an audience. But now I’m ready for new challenges that will expand my ideas and tactics, force me to attack problems from new perspectives, and dip into my design thinking repertoire to operate at a whole new level.

Though I consistently aim high, I want more success in turning my ideas into tangible outcomes, and in doing so, prove the power that I see in open, interoperable standards that can make the web a richer and more intricately spun space.

In some ways, I’m still just getting started with my work.  In joining Google, I see the chance to have a greater impact than I might otherwise on my own. That said, I won’t lose track of what intrinsically motivates me — that I’ve always been about spreading the benefits of the web by creating technology that  fosters innovation and choice. And there’s where I see alignment with what I’ve been doing, and what Google needs to succeed. In fact, my new title at Google? The same one I independently gave myself a year ago: “Open Web Advocate”.

In this role, I’ll still be an active community board member of the OpenID and Open Web Foundations; I hope to help push the Activity Streams project forward with a 1.0 release of the spec soon. And I’m still hopeful about the future of my our semi-neglected and half dormant Diso Project! I’ll also soon be publishing the results of my collaboration with Mozilla Labs, which will provide some insight into what social networking in the browser might look like, and how OpenID Connect might play a role in it.

For good measure, I should also point out that my good friend and colleague Joseph Smarr also made a similar decision recently  — unbeknownst to me at the time! —  and announced that he’ll be joining Google later this month as well.

So, net-net, I’m stoked to be joining The Man Google, and very thankful to have had as much support from the many, many people with whom I’ve connected through the synapses of the social web over these past several years. This is of course a very happy birthday present for me, and I’m eagerly anticipating what’s next for the open social web in 2010…! This can all still be made better. Ready? Begin.

Feel free to leave a comment here, or get in touch via email.

Update: here’s the latest theSocialWeb.tv episode where I make my announcement:

I’ve posted the video that Brynn shot of my talk. Slides are available here.

Of course, it’s purely coincidental that I used Pownce to illustrate my story of the “death of a web app”, since it was relaunched yesterday at TypePad Motion — without any of the relationships that were lost when the service shut down.

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.

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.

Chris Dracket responded to one of my tweets the other day, saying that “OpenID should be dead… it’s way over-rated”. I’ve of course heard plenty of criticisms of OpenID, but hadn’t really heard that it was “overrated” (which implies that people have a higher opinion of OpenID than it merits).

Intrigued, I replied, asking him to elaborate, which he did via email:

I don’t know if overrated is the right word.. but I just don’t see OpenID ever catching on.. I think the main reason is that its too complex / scary of an idea for the normal user to understand and accept.

In my opinion the only way to make OpenID seem safe (for people who are worried about privacy online) is if the user has full control over the OpenID provider. While this is possible for people like you and me, my mom is never going to get to this point, and if she wants to use OpenID she is going to have to trust her sensitive data to AOL, MS, Google, etc. I think that people see giving this much “power” to a single provider as scary.

Lastly I think that OpenID is too complex to properly explain to someone and get them to use it. People understand usernames and passwords right away, and even OAuth, but OpenID in itself I think is too hard to grasp. I dunno, just a quick opinion.. I think there is a reason that we don’t have a single key on our key rings that opens our house, car, office and mailbox, not that that is a perfect/accurate analogy, but its close to how some people I’ve talked to think OpenID works.

Rather than respond privately, I asked whether it’d be okay if I posted his follow-up and replied on my blog. He obliged.

To summarize my interpretation of his points: OpenID is too complex and scary, potentially too insecure, and too confined to the hands of a few companies.

The summary of my rebuttals:

• OpenID will become a necessary convenience in cloud computing.
• OpenID can be incrementally secured and, combined with OAuth, helps to defeat the password-anti-pattern.
• OpenID is about more than just accounts and fewer passwords — it’s a building block for online identity, and therefore personal agency for web citizens.

Convenience

OpenID should not be judged by today’s technological environment alone, but rather should be considered in the context of the migration to “cloud computing”, where people no longer access files on their local harddrive, but increasingly need to access data stored by web services.

All early technologies face criticism based on current trends and dominant behaviors, and OpenID is no different. At one time, people didn’t grok sending email between different services (in fact, you couldn’t). At one time, people didn’t grok IMing their AOL buddies using Google Talk (in fact, you couldn’t). At one time, you had one computer and your browser stored all of your passwords on the client-side (this is basically where we are today) and at one time, people accessed their photos, videos, and documents locally on their desktop (as is still the case for most people).

Cloud computing represents a shift in how people access and share data. Already, people rely less and less on physical media to store data and more and more on internet-based web services.

As a consequence, people will need a mechanism for referencing their data and services as convenient as the c:\ prompt. An OpenID, therefore, should become the referent people use to indicate where their data is “stored”.

An OpenID is not just about identification and blog comments; nor is it about reducing the number of passwords you have (that’s a by-product of user-centered design). Consider:

• if I ask you where your photos are, you could say Flickr, and then prove it, because Flickr supports OpenID.
• if I ask you where friends are, you might say MySpace, and then prove it, because MySpace will support OpenID.
• if you host your own blog or website, you will be able to provide your address and then prove it, because you are OpenID-enabled.

The long-term benefit of OpenID is being able to refer to all the facets of your online identity and data sources with one handy — ideally memorable — web-friendly identifier. Rather than relying on my email addresses alone to identify myself, I would use my OpenIDs, and link to all the things that represent me online: from my resume to my photos to my current projects to my friends, web services and so on.

The big picture of cloud computing points to OpenIDs simplifying how people access, share and connect data to people and services.

Security

I’ve heard many people complain that if your OpenID gets hacked, then you’re screwed. They claim that it’s like putting all your eggs in one basket.

But that’s really no different than your email account getting hacked. Since your email address is used to reset your password, any or all of your accounts could have their passwords reset and changed; worse, the password and the account email address could be changed, locking you out completely.

At minimum, OpenID is no worse than the status quo.

At best, combined with OAuth, third-parties never need your account password, defeating the password anti-pattern and providing a more secure way to share your data.

Furthermore, because securing your OpenID is outside of the purview of the spec, you can choose an OpenID provider (or set up your own) with a level of security that fits your needs. So while many OpenID providers currently stick with the traditional username and password combo, others offer more sophisticated approaches, from client-side certificates and hardware keys to biometrics and image-based password shields (as in the case of my employer, Vidoop).

One added benefit of OpenID is the ability to audit and manage access to your account, just as you do with a credit card account. This means that you have a record of every time someone (hopefully you!) signs in to one of your accounts with your OpenID, as well as how frequently sign-ins occur, from which IP addresses and on what devices. From a security perspective, this is a major advantage over basic usernames and passwords, as collecting this information from each service provider would prove inconvenient and time-consuming, if even possible.

Given this benefit, it’s worth considering that identity technologies
are being pushed on the government. If you’re worried about putting all your eggs in one basket, would you think differently if the government owned that basket?

OpenID won’t force anyone to change their current behavior, certainly not right away. But wouldn’t it be better to have the option to choose an alternative way to secure your accounts if you wanted it? OpenID starts with the status quo and, coupled with OAuth, provides an opportunity to make things better.

We’re not going to make online computing more secure overnight, but it seems like a prudent place to start.

Personal agency for web citizens

Looking over the landscape of existing social software applications, I see very few (if any) that could not be enhanced by OpenID support.

OpenID is a cornerstone technology of the emerging social web, and adds value anywhere users have profiles, accounts or need access to remote data.

Historically, we’ve seen similar attempts at providing a universal login account. Microsoft even got the name right with “Passport”, but screwed up the network model. Any identity system, if it’s going to succeed on the open web, needs to be designed with user choice at its core, in order to facilitate marketplace competition. A single-origin federated identity network will always fail on the internet (as Joseph Smarr and John McCrea like to say of Facebook Connect: We’ve seen this movie before).

As such, selecting an identity provider should not be relegated to a default choice. Where you come from (what I call provenance) has meaning.

For example, if you connect to a service using your Facebook account, the relying party can presume that the profile information that Facebook supplies will be authentic, since Facebook works hard to ferret out fake accounts from its network (unlike MySpace). Similarly, signing in with a Google Account provides a verified email address.

Just like the issuing country of your passport may say something about you to the immigration official reviewing your documents, the OpenID provider that you use may also say something about you to the relying party that you’re signing in to. It is therefore critical that people make an informed choice about who provides (and protects) their identity online, and that the enabling technologies are built with the option for individuals to vouch for themselves.

In the network model where anyone can host their own independent OpenID (just like anyone can set up their own email server), competition may thrive. Where competition thrives, an ecosystem may arise, developed under the rubric of market dynamics and Darwinian survivalism. And in this model, the individual is at the center, rather than the services he or she uses.

This the citizen-centric model of the web, and each of us are sovereign citizens of the web. Since I define and host my own identity, I do not need to worry about services like Pownce being sold or I Want Sandy users left wanting. I have choice, I have bargaining power, and I have agency, and this is critical to the viability of the social web at scale.

Final words

OpenID is not overrated, it’s just early. We’re just getting started with writing the rules of social software on the web, and we’ve got a lot of bad habits to correct.

As cloud computing goes mainstream (evidenced in part by the growing popularity of Netbooks this holiday season!), we’re going to need a consumer-facing technology and brand like OpenID to help unify this new, more virtualized world, in order to make it universally accessible.

Fortunately, as we stack more and more technologies and services on our OpenIDs, we can independently innovate the security layer, developing increasingly sophisticated solutions as necessary to make sure that only the right people have access to our accounts and our data.

It is with with these changes that we must evaluate OpenID — not as a technology for 2008′s problems — but as a formative building block for 2009 and the future of the social web.

Well, Twitter, along with Marshall and his post on ReadWriteWeb, beat me to it, but I’m pretty excited to announce that, yes, I am joining Vidoop, along with Will Norris, to work full time on the DiSo (distributed social) Project.

For quite some time I’ve wanted to get the chance to get back to focusing on the work that I started with Flock — and that I’ve continued, more or less, with my involvement and advocacy of projects like microformats, OpenID and OAuth. These projects don’t accidentally relate to people using technology to behave socially: they exist to make it easier, and better, for people to use the web (and related technologies) to connect with one another safely, confidently, and without the need to to sign up with any particular network just to talk to their friends and people that they care about.

The reality is that people have long been able to connect to one another using technology — what was the first telegraph transmission if not the earliest poke heard round the world? The problem that we have today is that, with the proliferation of fairly large, non-interoperable social networks, it’s not as easy as email or telephones have been to connect to people, and so, the next generation of social networks are invariably going to need to make the process of connecting over the divides easier, safer and with less friction if people really are going to, as expected, continue to increase their use of the web for communication and social interaction.

So what is the DiSo Project?

The DiSo Project has humble roots. Basically Steve Ivy and I started hacking on a plugin that I’d written that added hcards to your contact list or blogroll. It was really stupidly simple, but when we combined it with Will Norris’ OpenID plugin, we realized that we were on to something — since contact lists were already represented as URLs, we now had a way to verify whether the person who ostensibly owned one of those URLs was leaving a comment, or signing in, and we could thereby add new features, expose private content or any number of other interesting social networking-like thing!

This lead me to start “sketching” ideas for WordPress plugins that would be useful in a distributed social network, and eventually Steve came up with the name, registered the domain, and we were off!

Since then, Stephen Paul Weber has jumped in and released additional plugins for OAuth, XRDS-Simple, actionstreams and profile import, and this was when the project was just a side project.

What’s this mean?

Working full time on this means that Will and I should be able to make much more progress, much more quickly, and to work with other projects and representatives from efforts like Drupal, BuddyPress and MovableType to get interop happening (eventually) between each project’s implementation.

Will and I will eventually be setting up an office in San Francisco, likely a shared office space (hybrid coworking), so if you’re a small company looking for a space in the city, let’s talk.

Meanwhile, if you want to know more about DiSo in particular, you should probably just check out the interview I did with myself about DiSo to get caught up to speed.

. . .

I’ll probably post more details later on, but for now I’m stoked to have the opportunity to work with a really talented and energized group of folks to work on the social layer of the open web.

The intended audience of this podcast is really us, since it came out of lunches that Larry and I were having at Out the Door in downtown San Francisco. We realized that, while a lot of what we were talking about might be interesting to a wider audience, more importantly, starting a podcast of our conversations would give us a great pretext to invite folks who are inspiring us with their work to come out for some daikon cakes and Vietnamese ice coffee (following in the steps of Peter Rukavina et al’s Live from the Formosa Tea House podcast of course).

This past week, Larry and I brought together Todd Ditchendorf of Fluid.app and Jon Crosby of Actiontastic and recently Kloudkit to discuss site-specific browsers and related trends in cloud computing.

Obviously the question looms large about the competition between the open web, Adobe’s AIR platform and Microsoft’s Silverlight framework. With both Adobe and Microsoft jockeying for supreme “open” status with their platforms, we need to start asking the question differently: it’s no longer about whether a platform is “open”, but who controls its features, its priorities, and to what degree it facilitates interoperability by supporting industry-wide non-proprietary standards. Of course there’s always going to be proprietary development leading the way ahead of open development, and that’s fine. The difference, however, is that efforts like Mozilla’s Prism, Todd’s Fluid.app and Jon’s Kloudkit give us completely open stacks for implementing a lot of compelling ideas and features using tools and technologies without having to pick a corporate partner. They also provide us with the flexibility to innovate independently and see which ideas stick, while also pushing and pulling on the future of browser technology directly.

In any case, you should probably just listen to this episode and let us know what you think.

If you want to subscribe to Citizen Garden, you can grab listen in iTunes, grab our feed or follow Citizen Garden on Twitter.