Github lets you specify your agency context

Github gave me a whole new reason to love them last week when they introduced agency-aware identity in their new organizations offering. Crazy cool. Now each of my clients can have their own Github organization and I can participate in each! Same goes for each of my Open Source projects. And I can use it for a day job if I had such a thing. And all with one identity—one set of credentials. Brilliant Github!

Numerous issues kept me from moving it back to the original domain. First, of course, there was the fact that I didn’t have control of the domain at all for three months. When I did regain control in the summer of ’07 I was right in the middle of the Oregon move. By then I’d been posting away and it just never seemed like a good time to switch back.

If you know me, you know I’ve got lots of opinions about what’s good and bad about our various online communication tools such as blogs, email, Twitter, forums. What better way to test some of those ideas than to um, write a prototype and then uh, use that prototype. So as ’07 neared its end I made a little pact with myself that I wasn’t going to blog until I did so on my own stinking blogging platform (one I’d created).

Well what with the day job and design school and the family and all, that progress was slow. However in September, ’08 I did launch a first cut as part of the Thought Propulsion corporate site. If you look at the blog tab there is a beginning there. Not a lot of the functionality is exposed yet and my assessment is that to expose a whole lot more is gonna take a whole lot more work. Go figure.

While all this was going on, my WordPress installation at TextDrive (the one running meme-rocket.com) got upgraded about once and was in need of another upgrade. I kept putting it off because I loathe upgrading WordPress. It makes me crazy that “themes” are not isolated from the rest of the system. It’s crazy that a WordPress upgrade cannot be push-button.

So I decided to go ahead and kill a few birds with a big hammer and set up a shiny new wordpress.com blog on my original domain. That’s what you’re reading now. I’m feeling great about this decision so far since:

1. I was able to use my own domain—yay!
2. I was able to reclaim my original domain
3. I was able (using my DNS provider dnsmadeeasy.com) to HTTP (permanent) redirect meme-rocket.com to memerocket.com
4. I never again have to upgrade WordPress

A few minutes after upgrading I received a positive message from The Universe in the form of a wordpress.com alert on my dashboard. It said that the system was going to be upgraded to version 2.7 in 23 minutes. And guess what. I didn’t have to back up my files or my database. And I didn’t have to do anything but refresh my browser to enjoy the sweet new UI.

On the downside I’m sure I’ll miss some customization features. More on those as I run into them. For now though, I feel like I got my old megaphone back. Get ready for some blasts. Ahem! And what of that early ’08 pledge to roll my own. Well we’ll just have to see about that…

If you use your WordPress blog as an OpenID (as I do) via a link rel=’openid.delegate’ tag (that delegates to an external OpenID service) then you may be locked out of your accounts after upgrading to WordPress 2.3.x.

WordPress 2.3 introduced a new feature called URL canonicalization that turns requests to foo.com into www.foo.com. The justification is that it helps normalize statistics gathering in some cases (though in my experience, Google Analytics needed no such help).

But what happens if you were using an OpenID like foo.com on a (OpenID ‘consumer’) site like pibb.com is that after the WP 2.3.2 upgrade you actually end up authenticating the id www.foo.com (not foo.com). So you can never get back into your foo.com account at pibb.com. Got that?

Update 4:49pm:

My initial solution was this nifty one-line disable canonical redirects plugin from Mark Jaquith. Simply drop that in your WP plugins and enable it and you’ll no longer suffer URL canonicalization. But a simpler approach was to simply set the blog URL to http://meme-rocket.com in general options. Now I’m redirecting www.meme-rocket.com to meme-rocket.com and all’s well.

So I was thinking — what do you do when you’re feeling alone in the new era of social media? Why, start a website of course. Now there is already a pretty good community site, Registerflies.com where folks can commiserate and get status updates, but the itch I really want to scratch is this: how many of us out here are actually affected by RegisterFly’s failure? What actual sites are impacted? Any sites you’ve actually heard of?

Another itch that needs scratching is that there is no such thing as a “forwarding address” on the Internet when the old address is unresolvable. Makes sense right. The analogy in the real world is you have a donut shop and a nuclear blast hits it. Your customers can’t go to the old location and see the sign on the door pointing them to the new location. On the other hand, if you step outside DNS, there are myriad ways to do “forwarding address”. Only problem is, none of them have been formalized the way DNS has.

Now starting another site is a fair amount of work even for a Ninja – and I sir, am no Ninja. Wouldn’t it be great if there was a ready-made site that hosted DNS meta-data and discussion?  A site editable and usable by all.  A free site where a guy could create a forwarding address registry for just this purpose. Well as it turns out there is just such a site operated by a bunch of renaissance wierdos out of Portland, Oregon. It’s called AboutUs.org and it hosts a page about every domain on the ‘Net. There’s a page for your blog. What’s more you can edit that page – and so can everyone else. The whole thing runs on MediaWiki so you can create any old page you want!

So without further ado, I introduce the RegisterFly Impact Registry. It’s my little social experiment. I’m really curious to see if folks will come and provide their data. And I’m really curious to see just how many people, and what kinds of services were disrupted by this whole fiasco.

Are you the kind of blogger who requires readers to authenticate to comment or do you allow open comments? Most blog comment interfaces allow the reader to submit a name, an email address, and a (blog) URL. Without authentication, anyone can submit any email address, and any URL.

There are a couple problems here. One of course is comment spam, but I’m not so focused on that since captcha’s seem to do a pretty good job of heading that off — at least for automated spam. The darker issue to me is misattribution — the ability for anyone to claim that they are commenting as the author of anyone else’s blog.

If you follow John Udell’s recent meme about the professional blogosphere you gain an appreciation for the threat — or at least the huge missed opportunity. John’s idea is that over time, more professionals will push more of their professional output to the web and that an accessible record of their professional life will emerge. Viewed in this light, the sum total of a person’s writings on the web become properly their “identity” — or at least the online reflection of it. In order for this to work though, the reader of the work must have an ability to find work by a particular person, and filter out misattributions — both intentional and unintentional.

So just turn on password authentication for commenters and the problem will be solved right? Um, well, hang on… Now every blogger becomes a certification authority. Every blogger has to hand out accounts on her blog and in doing so, certify that the identity information associated with those accounts is self-consistent. Are folks going to bother to sign up for an account on your little backwater blog just to leave a comment, or are they going to move on. Barriers to signing up include the initial time delay, and the need for the reader to remember the credentials and endure the subsequent time delay in the unlikely event that he wants to comment on your blog a second time.

Is there a way to validate a commenter’s blog ownership claim without your having to go into the CA business. Can this be achieved in a way that isn’t off-putting to commenters? We’re talking economics here folks. And barriers to communication trade.

This is where OpenID comes in. OpenID allows you to use your blog as an online anchor for your own identity and to authenticate commenters to your blog. Install a WordPress plugin (others are available) and you’re off to the races. If you use LiveJournal the work is already done for you.

Here’s how it works…

Your Blog Acting as Your Identity Server

Imagine you want to post a comment to SmallBlog. If SmallBlog supports OpenID, you will be prompted for a URL along with your comment. The URL is your blog URL. Technically it can be any URL that points to a page that has a link with rel=”openid.server” pointing to your OpenID server — which is just a reference to some PHP script hosted on your blog site (hint: it came with your OpenID plugin.) You see how the framework is flexible, but in practice everything is just running on your blog site for the simple case.

So the comment post form on SmallBlog looks up your OpenID server and asks it to authenticate you and your OpenID server does that — using a cookie from your browser. Now this is the cool part. The cookie is your blog software’s cookie. So if you’re “logged in” to your own blog, then the cookie will be present, and will be passed to your OpenID server and you will be authenticated. The OpenID server actually redirects the (requesting) browser to a page that lets you decide how long the session should last. You make your selection and bang! you’re back at SmallBlog and your comment has been submitted — marked with your URL/identity.

If you are not logged in to your blog when you try to comment on SmallBlog then the cookie will not be present and your OpenID authentication will fail. So that’s the key. You log in to your own blog and as long as you’re logged in there, any comments you make on other folks’ blogs from that browser, will succeed authentication.

Your Blog Acting as a Client of an OpenID Server

In the example just given, SmallBlog was acting as a client of your blog/identity server. The plugins handle both sides so your blog can act as your identity server and it can also authenticate (foreign) commenters.

What it Doesn’t Do — Next Steps

OpenID does not provide a way for readers (of comments) to validate the identity of the commenter. For now it only allows the blog itself to do that. So evil blogs could lie about having validated their comments. With OpenID as a foundation however, we can envision an explosion of layered protocols.

Imagine a microformat that lets me link to my public key from my blog. With OpenID as the foundation, we could build a protocol that would enable me to digitally sign my comments on SmallBlog. Later, these could be validated by readers, using my publicly available key. And that key is valid because it’s linked to from the page referenced by the identifying URL.

The mind boggles at other uses for OpenID, but that will have to wait for another post. Now if you want to tell me I’m full of it, you’ll have to authenticate with OpenID to do so. Ah, life in the bubble.