Life online – Page 5

OpenID on the iPhone

I helped lead a session on Saturday at iPhoneDevCamp on the topic of OpenID and Oauth (a new protocol a group of us have been developing) to a packed room of developers, designers and interested parties.

My basic premise was that if you’re going to be developing an application for the iPhone that has any kind of account or social functionality that you should dispense with creating yet another identity silo and instead make use of OpenID. Among the reasons I cited:

Safari on the iPhone doesn’t have a password manager like 1Passwd and won’t be able to import all the Firefox passwords you’ve been recording for years. And, as mobile web browsers become more powerful, remembering web service account credentials will become more important (and more of a burden). Better to make it easy on your customers — one OpenID url, one username and password.
if you’ve logged in with OpenID on a web service on your desktop or laptop and have set your provider to always allow you to login in automatically, logging in on the iPhone will require you to only login to your OpenID provider and then enter your URL once for every web service that you want to login to. This means that you avoid the challenge of invisibly typing in your password over and over on the error prone touchscreen keyboard.
The ability to cross-polinate authenticated data using a combination of OpenID and Oauth while remote will be increasingly valuable, especially if the expectation is that applications are going to be entirely web-driven. When you’re dealing with desktop apps, you’re operating off a harddrive with known permissions; when you’re passing between web apps, the permission model is radically different and, just as when you go to check out from Amazon you always have to authenticate, developing patterns for this experience between web apps needs refinement. OpenID can help smooth out that interaction.

Lastly, there is work going on (okay, I’m doing it so far) to make the OpenID login experience on the iPhone (and elsewhere) trump any kind of old school login system available. This obviously needs a lot of work and new thinking (maybe instead of authenticating by typing a password you have to SMS a unique shortcode, etc) but I think your money should be on OpenID if you’re going to be developing account-based web applications on the iPhone — or — generally.

Why I screenshot

Three months ago, Sarah Hatter asked me a question that I had intended on answering then and there. In fact I did, but I had intended to expand upon these thoughts in a longer post:

Actually, I take shot primarily for my own purposes — research, learning and as a repository of interfaces that I can dig up later and imitate.

If I had to go out an search for a specific UI everytime I needed inspiration, I’d be a *much* slower designer than I already am! This way I can capture the best of the web *as* I come upon it, when the moment of inspiration hits.

I think this hints at what I said the other day about cleverness: she is the most clever who is the sum of everyone else’s cleverness (Ok, I didn’t say that exactly, but that’s kind of what I was getting at). On top of that, it’s rather inefficient to try to “innovate” your way to the next big thing when most “inventions” are actually evolutionary improvements to what’s come before. As if social networking and Web 2.0 was new! I mean, the version got ticked up from one-point-oh right?

But that’s not really what I’m saying. What I am saying is that I screenshot for history, for posterity, for education and erudition, for communication, to show off and, heck, for my own enjoyment. Call me twisted, but I really get off on novel approaches to old interfaces, clever disk images or fancy visualizations. Jacob Patton once called me the pornographer of Web 2.0. Nuff said.

Still, there is more to be said. For one thing, I don’t screenshot everything that I see or come across. Just like my blog posts, I tend to like to write about things that are interesting to me, but that, if I’m going to share to the wider world, will probably be of some interest to other folks, one way or another. I never assume interest, but, y’know, I do try to make this stuff look good in the off chance that someone takes inspiration from something I’ve uploaded… as in the case of Andy Baio‘s work on the redesign of Upcoming. According to his own recollection of his design process, he relied more heavily on my shots of the Flickr-Yahoo Account merge than on any other online resource for figuring out how to implement the same for Upcoming. So yay? Go team!

This is the perfect example of why my screenshotting of design patterns can be really useful for clever people. When other smarter people have already solved problems, and start repeating the solutions or interface in consistent ways, it becomes a design cow path. These are most interesting to me because, as the patterns emerge, we start to develop a visual language for web applications that can be used in the place of verbal descriptors like “adding friends” or “upload interfaces“. Rather than speak in the abstract, we can pull from an existing assortment of solutions from the wild that have already been proven in place, that you can interact with, and that you can evaluate on a case by case basis as to whether any given pattern is worth emulating in a new design.

I also screenshot as a way of in-between blogging, I guess. Y’know, like Twitter, Tumblr, Ma.gnolia, Plazes and Last.fm (among others) are all forms of in-between blogging. They’re where I am in the absences between longer posts (such as this one) where I record what I’m up to, what I’m seeing and what’s interesting to me. My Flickr screenshots are probably more often than not more interesting than what I have to say over here, and certainly less verbose. And, most significantly, the screenshot is the new photograph, allowing me to connect through images of what I see with other people who are able to see things the way I see them. Imagine life before the original camera, where everyone’s depiction of one another was captured on canvas in oil paint; before screenshotting became a first class citizen on Flickr, we were living in a similarly blind world, cut off from these representations of our daily experience. But fortunately, as of a few months ago, that’s no longer the case:

And, following off that last observation, I screenshot for posterity. Now that this internet thing has caught on and it’s been around a bit, it’s fun every now and then to reflect and go back to the days of the first bubble and take a look at what the “it” shine was back then (now it’s the “floor” effect — formerly known as the “wet floor” effect — but back then maybe it was the java lake applet?). Which is all fine and well, but once you start poking around, you’ll notice very quickly that the Wayback Machine is way incomplete. And while Google’s cache is useful, it certainly tends care more about the textual content of a page rather than how it originally looked. And that’s where screenshots could make up the difference, just as photographs of real life offer us a way to record the way things were, screenshots provide a mirror in time into the things we see on screen, into the interfaces that we interact with and the digital communications that we consume (check out this old view of the QuickSilver catalog compared with its current look or how about the Backpack preview or when Gmail stored less than 2GB of email?).

I don’t tend to think about the historic value of things when I shoot them; I do tend to evaluate their interestingness or contribution to a certain series along a theme. And yet, I’m curious to see, over time, just what these screenshots will reveal about us, and about the path we took to get to where end up. For one thing, web application development has changed drastically from where it was just a few years ago and now, with the iPhone, we’re embarking into wholly undiscovered territory (where it’s unclear if screenshots will be possible). But these screenshots help us learn about ourselves, and help us see the pieces-parts of our everyday experience. If I screenshot for any reason, perhaps it is to collect these scraps of evidence to help me better understand and put order into the world around me, to tie things together visually, and to explore solutions that work and others that fail. Anyway, it’s something I enjoy and will probably keep doing for the foreseeable future.

A different kind of net neutrality: Carbon Offsetting Web 2.0

Flickr Green

A couple months ago I had an idea that I’ve wanted to socialize since, but had only taken to doing so behind the scenes. Things being as they are, I’ve had little time to really advance this cause further, other than push it on a few friends who, so far, have reacted quite positively.

Prompted by Jeremy Zawodny’s post about Yahoo going carbon neutral and in support of Chris Baskind’s month-long effort to get high quality environmental links added to his Lighter Footstep group, I thought I’d finally write this up to see if it draws any interest.

The idea is rather simple and requires but one piece of support infrastructure that fortunately my fellow citizen coworker Ivan Storck is already hard at work on (more about that later).

So what’s the idea? Well, quite simply, it’s a web service that you use to offset the carbon footprint of your customers using your app. This would be mostly beneficial for larger services, but it’s my belief that every little bits counts!

For freemium services like Basecamp WordPress and Last.fm, providing an option for paying members to add $1/month to their bill in order to offset their use of your web service is where it begins. In exchange for this contribution, they would get a special distinction within the community, like a green avatar or badge to denote their carbon neutral status:

Last.fm Green

Now, this might seem like a trivial incentive, but then you might also be surprised to learn that the number one reason that people pay to upgrade their Flickr accounts is not because they need more storage or unlimited uploads, but instead because they want that tiny little PRO label next to their name. Offering a similar incentive on social networks — and making “offsetting cool” becomes a way to propagate this behavior, ultimately working towards completely offsetting the entirety of Web 2.0.

Now, those of you who have read up on carbon offsetting or know anything about the power that servers draw will quickly be able to recognize that $1 month to offset a single user account is going overboard, given that it technically only costs a few cents per month to power most people’s individual use of social networking sites. And while you wouldn’t be wrong, you’ve hit on an interesting social component of this campaign: those who want to offset can do so, and in doing so, won’t just be offsetting their footprint, but some their neighbors as well, in an act straight out of Caterina Fake’s culture of generosity. So it’s not so much about offsetting one’s personal use, but on offsetting at a social level — and that this good deed is reflected a user’s avatar or badge means that anyone can effectively “upgrade” themselves to carbon neutral status — once they get annoyed that all their friends have “leveled up” and they haven’t. Meanwhile, those who have upgraded as a proactive choice can feel reassured that their influence is affecting those around them to make similar decisions, even if for different reasons — in the end, the result doubleplusgood.

So, about that API that I mentioned. It’s important to realize that 1) we’re in the early stages of carbon offsetting and the 2) not all carbon offsetting funds are created equal (this is something I’m becoming evermore familiar with as we move to certify Citizen Space as a green office). Therefore, Ivan (who I mentioned and who also runs Sustainable Marketing and Sustainable Websites) has begun work on an API that will allow companies to purchase carbon offsets in bulk based on the actual amount of power consumed in something like a server farm evnironment (where power measurements are fairly easy to come by). Once initiated, the purchase will likely take place through one of Ivan’s affiliates based here in San Francisco called 3 Phases. In any case, we’re in the beginning phases of making this happen, but if you’re interested in helping or in offsetting your customers’ usage, leave a comment or drop me a note and we’ll see if we can’t push this work forward.

Likewise, if you can think of other ways to minimize the environmental footprint of your webservice or web office, blog about it and let others know! We’re doing what we can to create green coworking spaces and the more success stories we come across, the better.

The relative value of open source to open services

There’s an active debate going on in the activeCollab community stemming from the announcement that the formerly exclusively community-backed open source project will lose much of its open source trappings to go commercial and focus a closed platform providing open web services.

For those who aren’t aware, activeCollab was created as a free, open source and downloadable response to Basecamp, the project management web app. In June of last year, the project founder and lead developer, Ilija Studen, offered his rationale for creating activeCollab:

First version of activeCollab was written somewhere about May 2005 for personal use. I wanted Basecamp but didn’t want to pay for it. Being a student with few freelance jobs I just couldn’t guaranty that I’ll have money for it every month. So I made one for myself. It’s running on my localhost even today.

Emphasis original.

Ilija offered many of the usual personal reasons for making his project free and open:

Learning.
Control.
Establishing community.
Earning money.

Now, the last one is significant, for a couple reasons, as was pointed out at the time of the first release: Ilija wanted to make money by offering commercial support and customization on a product imitating someone else’s established commercial product.

But competition is good, especially for my friends in Chicago, and they’ve said as much.

But, Ilija made one fatal mistake in his introductory post that I think he’s come to regret nearly a year later: I find it normal to expect something in return for your work. activeCollab will always be free.

And so a community of Basecamp-haters and open source freeloaders gathered around the project and around Ilija, eager to build something to rival the smug success of Basecamp, something sprung from the head of the gods of open source and of necessity, to retrace the steps of Phoenix before it (later redubbed Firefox), to fight the evils of capitalism, the injustice of proprietary code, and to stave off the economic realities of trying to make a living creating open source software.

For a little under a year, the project slogged on, a happy alternative to Basecamp, perfect for small groups without the ability to afford its shiny cousin, perfect for those who refuse to pay for software, and perfect for those who need such collaboration tools, but live sheltered behind a firewall.

A funny thing happened on the way to the bank, though, and Ilija realized that simply offering the code for people to download, modify and run on their own servers wasn’t earning him nearly enough to live on. And without an active ecosystem built around activeCollab (as WordPress and Drupal have), it was hard to keep developing the core when he literally was not able to afford continuing to doing so.

Thus to decision to break from his previous promise and close up the code and offer instead an open API on which others could build plugins and services — morphing activeCollab from a commodity download to a pay-for web service:

Perhaps I am naive, and this was the business model all along. i.e. Build a community for the free software during early development and testing, then close it up just as the project matures.

That was not original plan. Original plan was to build a software and make money from support and customization services. After a while we agreed that that would not be the best way to go. We will let other teams do custom development while we keep our focus solely on activeCollab.

But, the way in which he went about announcing this change put the project and the health of his community at risk, as Jason pointed out:

Ilja,

I’m a professional brand strategist, and while nothing is ever certain, I also feel that this is a bad move.

Essentially you’ve divided your following into three camps. For, against and don’t care. A terrible decision.

What you should have done (or should do… its not too late)__

—> Start a completely seperate, differently branded commercial service that offers professional services

—> Leave your existing open-source model the same and continue to develop the project in concert with the community

————————-

Sugar is not a great model to follow. It’s not.

A better example would Bryyght[dot]com, a commercial company hosting Drupal CMS. The people there are still very actively involved in the original open-source project.

Overall, you should choose your steps wisely. While you’re the driving source behind the project – NOBODY fully owns their own brand.

A brand is owned by the community that are a part of it. Without customers, a brand is nothing.

JH

A brand is owned by the community that are a part of it. Without customers, a brand is nothing. (Hmm, sounds like the theory behind the Community Mark).

I think JH has a point, and with regards to open source, one that Ilija would do well to consider. On the one hand, Ilija has every right to change the course of the project — he started it after all and has done the lion’s share of work. He also needs to figure out a way to make a living, and now, having tried one model, is ready to try another. On the other, closing up the core means that he has to work extra hard to counter the perception that activeCollab is not an open source project, when indeed, parts of it still will be, and likely, won’t be the worse for it.

That many of the original Basecamp haters who supported Ilija’s work have now turned their anger towards him suggests that he’s both pioneering a tribrid open business/open service/open source model and doing something right. At least people care enough to express themselves…

And yet, that’s not to say that the path will be easy or clear. As with most projects, the test is now how he manages this transition that will make the difference, not that he made the decision.

All the same, it does suggest that the open source community is going through an evolution where the question of what to be open about and with whom to share is becoming a lot harder to answer than it once was. Or at least how to sustain open source efforts that play into facile operation as web services.

With the Honest Public License coming in advance of the GPL v3 to cover the use of open source software in powering web applications and services, there are obvious issues with releasing code that once you could count on being tied to the personal desktop… now with the hybridization of the desktop/internet environments and the democratization of scripting knowledge, it’s a lot harder to make a living simply through customization and support services for packaged source code when you’re competing against everyone and their aunt, not to mention Yahoo, Google and the rest.

Steve Ivy asked a poignant question in his recent post on Open Source v. Open Services: If the service is open enough, what’s the value of the source?

Truly, that is a question that I think a lot of us, including folks like Ilija, are going to have to consider for some time to come. And as we do consider it, we must also consider what the sustainable models for open source and open services look like in the future, for we are now living finally living web service-based economy, where the quality of your execution and uptime matter nearly as much, if not more, than the quality of your source code.

Problems with OpenID on Highrise

Turns out that 37 Signals’ implementation of OpenID could use some… getting real.

Let me go over these issues and provide either resources or remedies.

Normalization of OpenIDs URLs

Look at these three URLs and make a note to yourself about any differences you see:

To a lay person (or even your average geek), these URLs all represent the same thing — especially if you type any of them into the address bar, they’ll land you on my out-of-date homepage.

But, in the land of OpenID and URI evaluation, these differences can be very significant, especially when you get into the differences between OpenID v1.1 and the forthcoming v2.0 (which adds support for inames).

To the contrary of some discussion on the OpenID list, the way in which you normalize an identity URL very quickly becomes a usability issue if the cause of OpenID login failures are not immediately obvious.

Remedy: Given some of the issues folks have had with OpenID at Highrise, DHH decided to make usability the priority:

I’m going to fix the trailing slash issue on URL-based OpenIDs. We’ll be more liberal in what we take.

This should mean that folks logging in with OpenID shouldn’t have to guess at what their appropriate identity URL looks like, instead only substantively know what the important parts are (i.e. the domain and any sub-domain or path(s)).

Outstanding issues: Of course, 37 Signals can do this, but what happens when the identity URL that someone uses on Highrise doesn’t work elsewhere because other consumers aren’t as liberal with what they accept?

Lack of support for i-names

One of the issues (features?) that OpenID v2.0 brings is the support for i-names, a controversial schema for representing people, businesses and groups using non-familiar formatting codes.

I’ve heard that there’s somewhere in the ballpark of 20,000 i-names users in the wild (I happen to have =chris.messina but never use it), but compared with the over 70 million (and growing) URL-based OpenID users, this is an incredibly small minority of the overall OpenID landscape.

Nevertheless, one potential point of frustration for these users is in the lack of standardization in implementing or indicating support for i-names, as Rod Begbie pointed out in the Highrise forum, to which DHH replied, . We don’t support iname OpenIDs for now, though. We’re just supporting OpenID 1.1.

And this, I imagine, is going to be a common issue, for both OpenID implementors (dealing with support requests for support of i-names) and for i-names users, such that I question, as others have, the wisdom of offering support for i-names identifiers, when issues still clearly remain in the usability of basic URLs.

Remedy: Once the OpenID v2.0 spec has been finalized, there will need to be a new logo to indicate which version of OpenID a consuming site supports; this will hopefully work to set expectations for i-names users.

Outstanding issues: At the same time, the addition of i-names to OpenID v2.0 has caused a lot of concern for folks, many of whom have simply decided to stick with v1.1.

Personally, I don’t see the long term value in fragmenting the OpenID protocol away from more familiar URL-based identifiers. I want something simple, straightforward and obvious. Otherwise, v2.0 is going to be a headache to advocate, to implement and to support that a lot of folks with just stick with v1.1.

Double delegation aka the Sean Coon Problem

My buddy Sean Coon pinged me the other day to see if I could help him debug the problems he was having signing into Highrise with his OpenID account. When he had signed up, he had used seancoon.org as his OpenID URL. He’d started playing with it, but then left it, only to return later, unable to login.

His problem was three-fold, but I’ll first address a basic issue with delegation that some folks might not be familiar with.

As it turned out, Sean had delegated seancoon.org to resolve to ClaimID as his identity provider. The problem was that he used http://claimid.com/spcoon as his identity URL instead of http://openid.claimid.com/spcoon, which is where his OpenID was actually stored.

Typically when people use claimid.com/[username] as their OpenID identity URL to login to sites, this transformation takes place invisibly. This is because ClaimID delegates to themselves.

The problem lies in that Sean delegated seancoon.org to his ClaimID profile, which in turn was delegated to ClaimID’s OpenID server. If this sounds confusing, it is, and that’s why it’s not allowed in OpenID.

As I understand it, delegation can only be done once, or else you might end up in an infinite chain of delegations that may end in some grandious infinite loop. By restricting your delegation hops to one, a lot of problems are avoided.

Remedy: In this case, Sean only needs to re-delegate to openid.claimid.com/spcoon, and fortunately, there’s a handy WordPress plugin that can handle this for him.

Outstanding issues: Delegation is probably one of the coolest aspects of OpenID, since it allows you to use any URL of your choosing as your OpenID and then let someone else deal with the harder part of actually talking to all your services. Furthermore, you can delegate any number of services and set up fallbacks in case your primary identity provider is taking a nap. Communicating how this works and how to resolve and communicate errors when things go wrong is one of the biggest holes in the OpenID offering, and with user experience experts like 37 Signals joining up, I hope that these issues get the amount of due diligence and attention that they deserve.

Untested assumptions

Finally, I discovered a serious mistaken assumption in the Highrise sign-up process. To test out this issue, I created a test account, using http://google.com as my OpenID:

Now, here’s the problem: they didn’t force me to login to that OpenID when I signed up; instead they just assumed that I knew what I was doing and that I was using a valid OpenID.

So here’s the email that I got confirming my account. Note my username:

Of course when I go to login, I can’t, and I’m locked out of my account — since I can’t login and prove that I own google.com — which, notably, is the same result as if I’d mistyped my OpenID. Fortunately, 37 Signals gave me a backdoor, but it kind of defeats the whole purpose of using OpenID and suggests that you shouldn’t let folks arbitrary set their OpenIDs without having them prove that they really have control of their stated identifier.

Remedy: For implementors, you must get proof that someone controls or owns an OpenID if you’re going to rely on it as their primary identifier. You can’t assume that they’ve typed it correctly or even that they’ve even used a proper OpenID. And, most importantly, you’ve got to stress test such a new system to make sure issues like this are avoided.

Oh, and it does appear that MyOpenID.com OpenIDs are totally not working at this time; I’ve put Scott Kveton and Jason Fried in touch, so hopefully they can resolve the matter. Interestingly, if you’ve delegated to more than one identity provider and you’re using your own OpenID URL to login to Highrise, you should be able to get in.

Conclusion

It’s still promising to see folks like 37 Signals get on board with OpenID, but we clearly have a long way to go.

I hope I’ve clarified a few of the current issues that people might be seeing, or that are generally confusing about OpenID, and I admit that while I’m trying to clarify these things, a lot of this will still sound like Greek to most folks.

Given that, if you’re having issues getting OpenID, feel free to drop me a note and I’ll see if I can’t help resolve it.

ClaimID adds social networking

In spite of previous disavowals of having social networking aspirations, identity link aggregator ClaimID has now added the ability to add other ClaimID members to your profile as contacts.

Interestingly, they restrict you to adding friends who have OpenIDs (since every ClaimID profile URL is an OpenID) and use the XFN microformat to define your relationship.

This is a significant decision because, presumably, every OpenID has an owner. As such, adding one of these “verified” OpenID URLs as a contact to your verified OpenID URL could represent a higher trust level — a stronger “claim” as the lingo goes — than simply using the XFN rel-me attribute to create a “weak” relationship claim. Or so goes the theory.

Meanwhile, I’ve recently been reordering my Flickr screenshot collections and have created a set devoted to adding friends interfaces. If you have examples of similar interfaces, leave me a link to the source and I’ll get them added!

The atmosphere of community

Photo shared by Glenn Letham under a Creative Commons License.

Was thinking over the Digg and Flickr hub bubs and had an observation.

For one thing, Kathy Sierra’s mediocrity index comes to mind — where you’re either at both ends of being loved and hated (to greater and lesser degrees) or you’re in the middle, and frankly, no one cares.

There’s something else that’s missing from that graph though… part of it is helping to prepare community builders and managers for what happens when you get a surge in one direction or the other… and the other part is what leads you to climb outwards, in either direction.

I might propose a natural phenomenon to be considered here, and that is the phenomenon of atmosphere and the weather that results by being contained in this protective particle shell.

Without atmosphere, you’re a dead planet — there’s no oxygen, the conditions are extremely harsh and barren, and life simply cannot thrive.

Too much atmosphere and you get global warming effects — things like “community algae blooms” where too much life is created too quickly and the internal ecosystems break down because they buckle under the weight of the increasing resource demands… we are living in a period similar to this today (also, think spam!).

Now, the sweet spot — where systems are in harmony and life is able to sustain isn’t necessarily a walk in the park. Under these conditions you definitely get weather — and that weather can be destructive, can come on unexpectedly and worse, can ultimate change the landscape forever.

From a community building standpoint, this is the kind of weather that you need to be extremely careful of, because these tempests in teapots can wreak havoc on the livelihood of your broader community ecosystem and can do untold damage if you’re unprepared when it happens. The strategy to take varies on the kind of weather we’re talking about, and whether you’ve conjured it up by something you’ve done or whether external factors are to blame.

A couple examples: Digg’s founder Kevin Rose declares the end of the Top Diggers list… Flickr declares their acquisition by Yahoo… 18 months later, they announce the termination of independent Flickr accounts… The Wikipedia co-founder breaks off to establish his own competing project called Citizendium… Mozilla revenues are flat after earning upwards of $80M the previous year… The Flock founders leave in semi-rapid succession… BarCamp is planned and executed in a span of 6 days “changing the way we think about, organize, and participate in technology conferences“.

All of these events bear an interesting semblance to what I might call social weather patterns: moments in time when a tropical storm could have made the shift from a benign warm rain into a destructive gale force hurricane at a moment’s notice. Also consider tremors and earthquakes as coming from within, typically along well known social fault lines where some well known controversy erupts and shakes the pillars of the community. In some cases, these shifts have happened, taking out entire communities or leading to the crumbling of support infrastructure or the dissolution of leadership causing people to flee for refuge in neighboring communities. These behaviors are all fairly well documented and established in the real world — but for once, because of the digital context I’m thinking on, we can see precisely that this weather is heavily influenced by us — a conversation of sorts that our environment is having with us and for us on a grand scale.

In any case, looking at Flickr in particular, there are lessons to be had.

In particular, Flickr decided to drill into a particularly well known fault line in the community and stirred up a minor tropical storm. They had prepared for it, however, and in the early hours of the storm, had staff manning the levee-forums as the first order of defense. Next came the blogger response with heavy winds and crashing waves — Stewart and others waded into the comments and attempted to diffuse any self-spiraling weather patterns. Finally, with the leadership and community infrastructure still firmly intact, the storm subsided into the sea (aside from a few stray lightning bursts) and things continued on as normal, as they should.

But this is not always the way things go down. And without proper preparation and an understanding of the goal of resiliency as opposed to domination, you’re likely to fare far worse under similar conditions.

So the greatest lesson from this is to consider the existence at the poles of Kathy’s index… to realize that stormy weather is a good thing, and a result of positively creating atmosphere — an excellent indicator that you’re alive and creating the conditions for life and for survival. Without weather, you’re probably dead; and with too much atmosphere, you’re probably suffocating your community, in which case, it could be too late to turn back anyway. Keep these things in mind as architect the foundations of your community — and remember that community isn’t warm and fuzzy all the time.

Making more sense of Flickr’s Ides of March

Yesterday I wrote a post that was admittedly vague and rambling. I definitely did not “go home” before I wrote it, so I’d like to correct that, and try to make my meaning clearer (and by “go home”, I’m using speaker trainer Lura Dolas‘ concept of being grounded and authentic before opening your mouth to say something).

So, if I were to rewrite my post, I might say something like this:

The account merger for Yahoo! and Flickr accounts on March 15 (the Ides of March) should not come as a surprise; indeed, we’ve known that it was coming for a long time.

What the deadline represents to different Flickr members is personal and unique; there is very little generalization that can be made of the event, except that the reactions vary greatly along a spectrum from utter indifference to downright anger and resentment.

What Flickr members are experiencing is consistent with what any passionate community experiences when something that represents the core of their experience is disturbed. Whether logical or not, it’s kind of like repotting a plant — the more sensitive to the environment, the more the transplant can be debilitating, destabilizing and disorienting. There’s no rhyme or reason per se, but the individual shock can be a challenge to overcome.

Anecdotally, my personal experience was rather blasé. Previously, I had maintained a “self-perceived independence” by not succumbing to the demands of the Yahoo! conglomerate and merging my account. Indeed, every time I signed in via the “old skool login”, I got a rush of silent pride that I was still free, having avoided “following the sheep”.

My resistance somehow guaranteed that I still had ultimate control over my destiny — and that no corporate monolith could tell me what to do — especially as long as I had trusted friends on the inside advocating for my right to free choice and free association.

But that was a temporary illusion that I knew in the back of my mind would someday end.

And yesterday, the jig was up, the mirage evaporating in the form of a FlickrMail: the embodiment of Flickr’s final transformation from a renegade underdog that busted convention and ran roughshod over a corporate hegemon to become yet another cog in the machine.

Or so the self-serving mythology goes.

In reality, I’m not so sure that all that much has changed, really. I am inclined not to make any final pronouncements about Flickr, Yahoo! or whatever else. Hell, I switched over my account, and it wasn’t that bad. Innocence lost, yadda yadda, the world carries on.

Now, the part that I want to take a moment to reflect on, which I also alluded to in the last two paragraphs of yesterday’s post (and is somewhat carried on here), is the part about managing, owning and making choices that effect the destiny of the identity (or identities) that one has spent time creating and cultivating online.

I would posit that the fear or fear-driven reactions that a lot of people have expressed or experienced in the past two days can be traced to this particular nugget of thinking.

What we lack online today is the equivalent of what we call human rights in the offline world. As it stands, Terms of Service are written foremost in the interest and protection of the Corporation. Thus individuals have little transformative recourse when things go wrong for the vocal are but few among millions.

As such, minority hold outs are left feeling particularly vulnerable and exposed. Especially in the case of Flickr, where people have developed visceral and almost human connections through the service, anything that threatens their “dominion” is an invasion that provokes an immune response by what I’d call the “proverbial community anti-bodies”, for better or worse.

In this case, Yahoo! — as the larger organism eclipsing the smaller — is perceived as effectively infusing its memetic DNA into the cultural neurology of the lesser system and without effective recourse to prevent this kind of “digital eminent domain“, the anti-bodies lash out in response to the invading foreign agents, as you would expect in any biomimetic system.

This dance is natural, is normal, and a simple part of biological and social evolution. In the scheme of things, I think the reaction of the minority does make sense here, even if it ultimately doesn’t matter that much. Given the current architecture of social networks, where your existence and environment is at the whim, pleasure and financial health of the network owner (let’s call her “God”), these kinds of decisions will continue to elicit strong social responses when God acts like… well… God.

Asides (lightly scrambled)

I do wonder, then, if this kind of personal exasperation would more quickly lead to the creation of “articles of digital personhood” or a collective “bill of digital human rights”. Or if, instead, it might drive the furtherance of independent identity services that promise to restore dominion over one’s online personas.

On a larger scale, will these experiences lead to the recognition of our digital selves as rights-weilding extensions of ourselves? Were there a “Digital Civil Liberties Union”, would those with grievances turn to such a centralized body for redress? or, rather than unionizing power, would they prefer to simply come and go as they pleased, as one does when she moves from one house to another, taking all her possessions and friendships with her but leaving the structure behind, and letting the market woo and serve her by playing to her desires and free will to choose?

Bating the mousetrap with chunky peanut butter

Original by starpause kid and shared under a Creative Commons License.
When it comes to mousetraps, it’s fairly common knowledge that an effective cheese alternative for trapping mice is peanut butter.

However, we already know that Yahoo isn’t too fond of peanut butter. At least the smooth kind spread thin.

So it’s interesting to note that, perhaps as part of the strategy to outlaw renegade peanut butter within the organization, the formerly independent outpost known as Flickr will be forcing users to either merge or create a new Yahoo account to login after March 15:

On March 15th, 2007 we’ll be discontinuing the old email-based Flickr sign in system. From that point on, everyone will have to use a Yahoo! ID to sign in to Flickr.

We’re making this change now to simplify the sign in process in advance of several large projects launching this year, but some Flickr features and tools already require Yahoo! IDs for sign in — like the mobile site at m.flickr.com or the new Yahoo! Go program for mobiles, available at http://go.yahoo.com.

If you still sign in using the email-based Flickr system (here), you can make the switch at any time in the next few months, from today till the 15th. (After that day, you’ll be required to merge before you continue using your account.) To switch, start at this page: http://flickr.com/account/associate/

Complete details and answers to most common questions are available here: http://flickr.com/help/signin/

If you have questions or comments about signing in with a Yahoo! ID, speak up!

You can imagine that not everyone is happy about this, especially after the reaction the first time around:

Now, I’m not interested in opening old wounds. The Flickr folks have given plenty of notice about the coming changes (figure at least a month and a half if not the full 18 months since they were acquired) and of course are available for consolation, hand-holding and so forth.

Oh, and contrary to my tendency towards conspiracy theories, I’ll let Stewart debunk them outright:

And that’s it: there’s no secret agenda here, no desire to come to your homes and steal your TV. Over time, it just gets more expensive to maintain independent means of authentication and we could “spend” those efforts on other things which make Flickr more useful, more fun, more versatile, etc. And the smaller the ratio of old skool to Y!ID-based gets, the harder it is to justify not spending that effort on improvements.

I will, however, take this opportunity to rise up on my soapbox again and point out something worth reflecting on…

Look, Google’s already done the same thing with Dodgeball; it’s a sure bet that they’re going to do the same thing with their YouTube acquisition. We know that Yahoo logins are going to show up on MyBlogLog and eventually, probably Upcoming too — and, for that matter, any other user-centered acquisition that comes down the pipe. Microsoft is no different. Let’s face it: the future of the web is in identity-based services. And this is a good thing, if you’re ready for it.

My buddies Brian Oberkirch and Aldo Castañeda talked about the potential for this new economy recently. It’s coming and it’s scary (for some) and it’s unclear what it looks like. But the more that this happens under authoritarian login regimes, the more concern I feel for the effect these consolidation efforts will have on true democratic choice in where and how you spend your attention.

Realistically, it’s not terribly surprising that Yahoo! and the rest are going this direction. Hell, from a systems perspective, you’re just two entries in a grand database in the sky whereas you could be one. From a service perspective, unifying “you” across systems allows convenience and synergies to emerge. The problem is that these actions belie the sophisticated relationships that some people have with their online accounts and how their personas are represented. Though not everyone cares a whole lot about their screennames, others absolutely do. And beyond that, for whatever reasons they have, some people simply do not want to go near Yahoo! — something they never thought would be a concern of theirs when they originally joined Flickr.

But there’s a curious reality to look at here.

While I call Flickr home (NIPSA’d and all), just as there is a vehicle to vent my individual frustrations to Flickr, those same vehicles and mechanisms are available to me to splinter off and build my own peanut-butter-rich outpost anew. The missing piece of the puzzle, however, is my identity. I can’t just pack up my digital self and move on… whichever login system Flickr uses — Yahoo’s, Google’s, their own — I can’t “take it with me”. Even with their API, which is one of the most generous in the biz, it still doesn’t give me the ability to fully reincarnate myself somewhere else.

Now, I could and would like to turn this into a pitch for OpenID, but I won’t, at least directly. The Yahoo! folks have already expressed their distaste for creating Just Another Identity Silo and I keep waiting for them to prove it. I don’t mind waiting a bit longer. The wheels of the OpenID community are already in motion and I don’t have to plead for acknowledgment from the powers that be. The truth is, there are only a few more sites that will fall. The truth is, we are only now beginning to realize the degree to which we are all exposed and what the reality of our transparent society looks like. And the truth is, we are only just beginning to wake up to the idea that we should and can have dominion over our online lives, just as we believe is our right offline.

Scoping XFN and identifying authoritative hcards

Before I can write up my proposal for transcending social networks, I need to clarify the originating and destination scopes of XFN links.

It’s currently understood that XFN links describe personal relationships between two URLs.

Typically the endpoints of XFN links are URL-centric personal blogs (i.e. horsepigcow.com or tantek.com), but not always. And because we can’t always assume that the outgoing linker speaks for the whole URL, or that the destination linkee is all inclusive, we need a set of standard criteria to help us determine the intended scope of the originating linker.

Put another way, how can we better deduce who is XFN-linking to whom?

Let’s take a concrete example.

The established XFN protocol states that when I XFN-link from my blog at factoryjoe.com to horsepigcow.com, that I’m describing the relationship between me and Tara Hunt, and our blogs act as our online proxies. Readers of our blogs already know to equate factoryjoe.com with Chris Messina and horsepigcow.com with Tara Hunt, but how can computers tell?

Well, if you check our source code, you’ll find an hcard that describes our contact information — marked up in such a way that a computer can understand, “hey, this data represents a person!”

If only things were so simple though.

If I linked to Tara and there were only one hcard on the page, you could probably assume that that single hcard contained authoritative contact details for her since knowing that Tara blogs at horsepigcow.com there’d be a good chance that she put it there. Sure enough, in her case, the hcard on horsepigcow.com does represent Tara.

Now, flip that around and let’s have Tara XFN-link back to my blog. This time instead of one hcard, she’ll most certainly find more than one hcard, and, most perplexing of all, most are not me, but rather people for whom I’ve marked up as hcards in my blog posts.

So, if you’re a computer trying to make sense of this information to determine who Tara’s trying to link to, what are you to think? Which relationship is she trying to describe with her link?

Well, as a stop-gap measure that I think could be easily and universally adapted to add definitiveness to any arbitrary hcard at the end of an XFN link, I propose using the <address> tag. Not only has this been proposed before and not been overruled, but it is actually semantically appropriate. Furthermore, there are already at least a few examples in the wild, notably on my blog, Tara’s blog, and most importantly, Tantek’s.

Therefore, to create ~~a definitive~~ an authoritative hcard on any page, simply follow this example markup (note the self-referencing use of rel-me for good measure):

.code { border: 1px solid #ccc; list-style-type: decimal-leading-zero; padding: 5px; margin: 0; }
.code code { display: block; padding: 3px; margin-bottom: 0; }
.code li { background: #ddd; border: 1px solid #ccc; margin: 0 0 2px 2.2em; }

<address class="vcard" id="hcard">
<a href="https://factoryjoe.com/blog/contact/#hcard" rel="me" class="fn n">Chris Messina</a>.
</address>

At the destination URL, include a fragment identifier (#hcard) for the hcard with the complete contact information and add rel-self in addition to rel-me (as per John Allsopp’s suggestion):

<address class="vcard" id="hcard">
<a href="https://factoryjoe.com/" rel="me self" class="fn n">Chris Messina</a>.
</address>

This practice will primarily help identify who XFN-linkers intend to link to when pointing to a blog or URL with multiple hcards. In the event that no definitive hcard is discovered, the relationship can be recorded until later when the observing agent can piece together who owns the URL by analyzing secondary clues (rel-me or other hcards that point to the URL and claim it).

Oh, and I should note that from the standpoint of multi-author blogs, we should be able to scope XFN links to the author of the entry — with hAtom entry-author making this infinitely easier.

Category: Life online