Priorities for adding OpenID support

Eventually, nearly all web apps will likely support OpenID in some form. But — here in the early days — what web applications are most in need of OpenID?

Apps where identity is important — you want to track several pieces of data back to a known identity, or allow an identity to come back and update their own data. Combine that with web apps where many users contribute, but might only come back irregularly, and you have the sweet spot. Prime examples would be wikis, forums, and blogs.

I had an interesting Skype-to-Europe call with Frank, who is working on some OpenID stuff for Mephisto, about how this relates to that project.

Blogs have two distinct sets of users: the blog owners, and those posting comments. Mephisto does not have a single, unified “user” to manage both. Blog owners log in to post and administer the blog, while comments just store the name, email, and ip of the commenter directly in the comment table — there is no login per-se.

So there’s a bit of a mismatch right now: Mephisto doesn’t really have the architecture in place (e.g. login for submitting comments) where OpenID support would be most useful. This leads to things like Justin’s OpenID consumer plug-in port to mephisto — it calls the OpenID libraries, but then mearly dumps the user’s email & name (from SRE) into the comment. You can’t re-login and go back to find and modify one of your prior comments, because Mephisto isn’t really using OpenID to know it’s “you” yet. So it only saves you some typing, and not much at that.

But adding OpenID support for admin login, while nice, wouldn’t be where the greatest need is.

This creates an issue for the upcoming screencast, since it needs to focus on OpenID without getting into more complex distractions (like fleshing out new blog comment functionality). That, and also Mephisto’s authors are trying to avoid adding any complexity to the trunk right now. The focus is on stabilizing, since you pretty much need to be on trunk to have it work out of the box (0.7.3 is getting quite old, and doesn’t work without some small updates from trunk). Mephisto needs some more time to bake before adding OpenID will be completely smooth.

What all this adds up to, is Mephisto is not a good match for the screencast. But I’ve got a set of smaller Rails-based app or app porting ideas which would. Hopefully they’ll be both interesting on their own, and very clear examples of Rails implementations where OpenID is most useful.

Google Gadget “creator page” and lists datatype

Feedsparks uses the new (as of Jan 17th) “list” datatype which google added to their gadget API. It enables a simple but nicely designed interface for configuring a gadget like this one. But the UI for the new datatype has confirmed problems outside of adding the gadget to your google homepage (which works flawlessly). Hopefully google will fix this shortly. Until then, the prior post describes a workaround you can use.

You can read some background (the dialog with google) at the google group for gadgets.

Configuring Google Gadgets for your page

google modules form screenshotGoogle gadgets on a Google property are easy to configure — Google provides a nice UI, and the user can just select the arrow in the upper right corner to configure it.

But to put a gadget on any old site, you need to first generate a javascript snippet, which has all the configuration in it.

Unfortunately, when generating this script for Feedsparks, Google’s form for configuring the script has a problem: Notice anything missing in the screenshot above? There’s no UI to configure the list of feeds!

This may be something to do with the newness of the gadget list datatype, or something fixable in how Feedsparks is written.

So, until the mystery of this problem is resolved, if you want to install the feedsparks gadget into any web page … and actually be able to configure it to display your feeds … you’ll need to add this snippet like this in the middle of the script line generated by Google.


Careful .. it goes right there alongside the other parameters to the gadget (you could put it after up_days). An example of the full, modified script line is…

<script src=";up_days=30&amp;up_feeds=BernieThompson|Haikupedia&amp;up_attribute=circulation&amp;up_userid=&amp;up_password=&amp;synd=open&amp;w=288&amp;h=81&amp;title=FeedBurner+Trends&amp;border=%23ffffff%7C3px%2C1px+solid+%23999999&amp;output=js"></script>

Resulting in a gadget on your page which looks like this.

If there are other problems configuring Feedsparks, let me know.

Feedsparks 1.01

Feedsparks is a Google Gadget showing at-a-glance subscription and traffic trends for your FeedBurner feeds.

A previous Feedburner tracking gadget I’d been using on my google homepage stopped working, and I had wanted one with a few more features anyway, including a historical chart — but one that had to be small. Sparklines, which were originated by the father of data visualization, Edward Tufte, would be a perfect tool for a case like this. So that lead to developing this mashup of these various ideas.

Features and Notes

  • First things first: to see your own feed statistics, either turn on the Awareness API in FeedBurner for each of your feeds (preferred), or provide your FeedBurner userid and password to the gadget.
  • Uses compact, expressive sparkline chart for historical trend (showing 30 days by default, but configurable)
  • Shows current day’s number, with green/red arrow showing if it’s up or down from yesterday
  • Easily add an almost unlimited number of feedBurner feeds (FeedBurner’s Awareness API must be turned on from your FeedBurner control panel)
  • Choose to show statistics on FeedBurner’s circulation estimate (default), or feed hits
  • Built on FeedBurner’s Awareness API and Joe Gregorio’s sparklines service which serves over a million hits a week. All other work happens in javascript in the browser, so the Feedsparks gadget should be quite scalable and reliable.
  • In the sparkline graph, the blue dot is the point of highest traffic, red is the low point, and green is the current number

You can add this gadget to your personalized home page –or– add it to any web page.

Note that google’s form in the “add to any web page” link appears to have a problem adding feeds. You’ll have to add them to the generated javascript directly.

Let me know if you have any feedback or feature requests!

Latest news on Mephisto and OpenID

Mephisto is still developing, but seems to be coming into its own as a blog engine of choice for Rails.

Since Mephisto does not yet have OpenID support in its trunk, this seemed like a good project as the running example for my peepcode screencast on OpenID.

There is some very active ongoing work, though, that if I go forward with Mephisto I will certainly build on. Here’s the latest I know of.

First, is Justin at transphorm’s Mephisto port of the OpenID Consumer plug-in for Rails. Normally, outside of Mephisto, the OpenID Consumer plug-in could be be used in conjunction with a authentication generator like ActsAsAuthenticated. Justin’s port is nearly fully baked, but does require hand editing several significant areas.

Second is Frank’s work at nullsense, which builds on Justin’s port and works to turn it into a full Mephisto plugin. This work isn’t yet released (and, when it is, may require some changes in Mephisto trunk), but it looks like a full Mephisto plug-in for OpenID is imminent.

For myself, where I want to show adding OpenID to Rails from the ground up, this raises some question of doing the screencast with Mephisto or with a project where there is no existing OpenID activity that i know of.

Also, if Mephisto remains the direction, there’s the question of whether OpenID should be a standard feature in Mephisto trunk, or kept separate as a plug-in.

If anyone has thoughts, let me know!

OpenID, Rails, and Peepcode

OpenID LogoOpenID is an exciting, up-and-coming technology which will make website registration and login simpler (Finally! Fewer passwords to remember!)

I’m hopeful that, over the next year, you’ll see a flood of web apps add support for it.

But today there are only a few dozen web apps that have that support. Support in web frameworks like Ruby on Rails is here or coming soon, but word hasn’t reached the masses yet.

To play some small part in filling that need, I’ll be helping to create a screencast which walks the viewer through adding support for OpenID to an existing Rails app. As this work is done, I’ll post here with some of the information and questions that come up, along with a little on the general process of creating a screencast. Subscribe if you’re interesting in reading this series of posts, and you can also see some of the resources I use at my openid tagged pages (

The screencast will be posted on, Geoffrey Grossenbach’s repository of professional, high-value screencasts on a specific topics. I’ve admired Geoffrey’s work and various projects for a long time, and am looking forward to working on one of his efforts.

Please let me know if you have any feedback — a question or topic you’d like covered, for example.

Here’s the tentative topics:

5m Getting an OpenID for ourselves
10m Installing the Mephisto Rails-based blog engine
5m Plugging an OpenID login into Rails
10m Creating our OpenID-unique tests
10m Analyzing and migrating our models
10m Merging our views and controller logic
5m The final product

Here are some examples of the early questions I need to answer:

  • How much should I summarize topics already hit by Simon’s introductory screencast for non-technical OpenID users?
  • For the example project, add OpenID support to Mephisto (blog) or Junebug (wiki)?
  • Will I need any major dependencies beyond ruby-openid (and its login generator)?
  • Will there be time in the screencast (targeted at 40 mins) to make a standard plug-in?
  • What are the top 3-5 gotchas that cause people to loose time when embarking on OpenID themselves?

Every Problem is an Opportunity

Apple is set to announce a new product line this morning — an Apple phone, previously called the iPhone.

The Internet is buzzing about this for one simple reason — the cell phone market today is one huge headache for consumers. The quality of the hardware and especially the software on phones is lousy. The carriers, especially here in the US, are all about lock-ins to long contracts, and towards that goal they use their bag of bait-and-switch, selective crippling, and other lock-in strategies against the consumers that they aught to be serving more honestly. Microsoft has been doing a better job with Windows Mobile, but still is resistant to open standards at the communication layer (e.g. syncing contacts).

Apple has a track record of taking a broken situation involving complex technology, focusing on the basics, and making it actually work. In recent years (since the second coming of Jobs), they’ve flipped to become a fairly steady supporter of standards. So thus all the hope and hype.

In this case, I have a nagging suspicion that expectations are running ahead of Apple’s ability to deliver. Many of the problems are too entrenched — for example, the rumor is that Apple will launch with Cingular, which is unlikely to change its ways for just this single partnership.

But we will soon see. The announcement, whatever it is, is minutes away now. And for anyone with a small business, it’s always useful to watch as others try, as we do, to turn problems into opportunities.

Technorati tags: Apple, iPhone, phone