Bill Burcham’s memeRocket

XML Grrl Eve Maler pushed a string on identity standards for us long-tailers that piqued my interest in OpenID.

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.

As explanations go, it doesn’t get much more straightforward than Cody Fauser’s excellent post on Rails RJS Templates. When you try it out though, you may notice that TextMate doesn’t know that RJS templates which by convention have an “.rjs” suffix, are really Ruby code. If you want to make TextMate aware of the “.rjs” suffix simply open the Bundle Editor window, navigate to the Ruby bundle, scroll down to the Ruby language definition (it has a Gray circular icon with an “L” on it), and add ‘rjs’ to the list of fileTypes.

Once you do that, TextMate will treat .rjs files like other Ruby files and you’ll get syntax highlighting and stuff.

I submitted a Rails/script.aculo.us defect describing how Ajax.InPlaceEditor is stripping paragraph tags when loading the textfield/textarea. While waiting for the Universe to respond, I’ve had some time to research the issue a little more. Interestingly, the behavior seems to have originated with a changeset committed last September. That changeset actually addressed two issues: it fixed a Safari bug, and it added the convertHTMLLineBreaks functionality.

I hope the apparent author of the convertHTMLLineBreaks functionality will notice this ping to his blog. (I realize my approach for making contact is a bit unorthodox, but my feeling is that this constitutes better manners than intruding via email — though I can’t find his email address anyway). I’d like to understand more about the original reasons for the convertHTMLineBreaks functionality. What problems does it solve? Why does it need to strip paragraph tags as well as line breaks. And perhaps most importantly — why doesn’t it put something back in their place when the edited content is injected back into the DOM?