OpenAvatar - Combining OpenID and hCard
Cristiano and myself wanted to add avatar support to Four Starters so that people could put a face to the writer of a post or comment. There already exist some solutions for this, but something more open might be nice.
Existing Avatar Solutions
Prompted by the recent post by Chris Messina (“Raising the standard for avatars”), I started to think how we could do this using OpenID.
Being somewhat more practically inclined Cristiano installed the MyAvatar plugin which pulls avatars for commenters from MyBlogLog. It uses a mechanism similar to Gravatar, but whereas Gravatar uses e-mail addresses to retrieve avatars, MyAvatar uses the blog addresses of the commenters.
MyBlogLog gave us some trouble with authorship of blogs. I think it had something to do with non-canonical blog URLs. After I had dealt with that and the monstrous profile form at MyBlogLog, I was a bit turned off of the service. Yet Anoter Social Network, yet another profile to fill in, yet more diminished returns of value. After some more trouble Cris completely removed the plugin.
OpenID to the rescue
Seeing as this blog already supports OpenID signin for commenting (using the wpopenid plugin), I thought it would be much easier to extend OpenID to retrieve basic profile information. Portable social networks have been one vision of OpenID but they have been a bit slow in the making. So we might as well start somewhere: add discoverable profile information to OpenID by associating it with an hCard.
A small discussion with Tijs, led to one of two options.
- OpenID has its Simple Registration Extension which allows for identity providers to return a set of data commonly used in account registration to ease the process of signup at sites.
You can see this implemented in the persona support at MyOpenID.com. You can create persona and seed them with sets of profile information where you can then control which sites get to see which personas.
This is nice but there are two objections. SREG does not have a field value for avatars and this makes discovery too heavy weight. Anybody who wants to discover this information has to be a full blown OpenID consumer, go through the authentication step with an OpenID provider and negotiate the exchange of the SRE information. This is too much work.
I see this idea has already been proposed and rejected at SREG. We’ll have another go.
- The other option which I massively prefer is to embed an hCard in the URL where your OpenID is located. hCards are for publication purposes anyway, why not publish them somewhere where people can find them.
So in this case, my OpenIDhttp://alper.nlhas an hCard embedded withdisplay: none;and animg class="photo". Pretty simple.
Besides embedding the hCard there, it should also be linked in some way, but I could not find documentation saying how that should be done. Something likelink rel="hCard"seems fitting, though I’m not sure what thetypeof an hCard is (text/hCard, application/hCard+xml?).
Now to see if this is in line with the implications of OpenID. In Simon’s presentation I also see the conflict if you will maintain multiple online persona by using different OpenIDs or by having your OpenID provider return different persona for different sites. It depends on the level of separation you want, I suppose.
OpenAvatar
So how do we get that information out? Any way you like.
I made this small CGI which handles the simplest case: http://alper.nl/cgi-bin/OpenAvatar.py?openid=http://alper.nl. An hCard embedded in the page itself. It’s a proof of concept and is probably buggy so bear with me.
It returns the image directly so you can put it in the src of your images and they will be retrieved automatically.
Embedding it directly in your application code doesn’t seem too wise because for every avatar a request has to be made, parsed and another request for the image. Clients which are serious about using this should retrieve the images, transform them to their specifications and cache them, I think.
Next up to modify the MyAvatar plugin for Wordpress to retrieve its images from associated OpenIDs.
Useful, useless, or plain evil? I’d like to hear your opinion.
Update: After some useful comments, I changed my hCard at http://alper.nl to be visible. After that the process of pulling an hCard from an OpenID page looks very similar to the Representative hCard discovery process as brainstormed on the microformats wiki. I’ll modify my service to adhere to the process as outlined there. I currently get the photo from the first hCard on the page.
Other than that, it looks like we’re on the right track, sort of.
tijs http://tijs.org/
May 21st, 2007I think it’s an excellent idea, in fact i’ve just updated my openid page tijs.org to this effect. Let’s spread the word and we’ll see how far it takes us…
p.s. it might be a good idea to seperate openid login and comment posting (like http://simonwillison.net/ does for eaxmple) i exepected a login first and a post as a second step. oh well, maybe i’m just stupid
alper http://www.alper.nl
May 21st, 2007I’ll throw this at #microformats to see if they can punch any holes in it. Any uptake would be great, though I see it as a somewhat logical step to associate OpenID with public hCard information.
@About the OpenID, I’m not completely satisfied with the functionality of the wpopenid plugin. Using Simon Willison as an example is a bit unfair because I think he has written his entire blog (and OpenID support) from scratch. I wouldn’t mind if other plugins followed his best practice though. I’ll check to see if the plugin has been updated.
Robert http://robertgaal.myopenid.com/
May 21st, 2007Cool stuff! Your OpenID could contain so much more info, and this is one good example of that. The big question is: what do you solve with microformats (like my AlphaDash thingy), and what needs to be SREG’d? It depends on the security of the information I guess.
I like the /avatar.jpg by Cris actually. I use favicons on http://blueace.nl and it was really simple to implement. But hCards are of course structure-wise a little better.
alper http://www.alper.nl
May 21st, 2007Okay, one major mistake which I’ll fix as soon as possible is that having an hCard in a hidden element is a Bad Practice.
One of the bigger objections is that hiding your data does not incentivize keeping it up to date.
Furthermore discussion is still out on how to link to hCard data for a page. So until then I’ll change my hCard to be visible and all should be well.
Profile icon discovery has already been brainstormed.
alper http://www.alper.nl
May 21st, 2007@Robert: /avatar.jpg was summarily rejected and I think justly so. Just read the comments on that blog entry.
Reinier http://zwitserloot.com
May 22nd, 2007Simple. Excellent.
As you say, some information is just generally fit for public consumption, and should definitely not be ‘locked’ behind the OpenID door. Other information, like e.g. all your friend’s open IDs (which would be extremely useful, but that’s a topic for another day, plus the OpenID evangelisers already preach this one, I think) - should be, that’s not entirely fit for public consumption, but basic this is me and this is my name info: Well, if you have a blog, that’s already out on the street.
You can take this privacy thing ever so slightly too far, as well.
Some more public consumption food that could be useful to include:
- your blog(s)’s URL(s).
- physical location, though not neccessarily with exact granularity (say, at least country, and if you want to provide more detailed info, like city, or even street, that’s up to you).
- photo and name.
- links to profile pages on webservices. For example, your flickr home page, your youtube videos page, etcetera. Alternatively, just a site name (”youtube.com”) and your username there. Automatically parsing the data there needs some sort of knowledge of the site (at least for now) anyway.
It would also be useful, I think, if the choice of locking the information behind the consumer door or not is your choice, and that you can even split some of the above. For example, location on the page itself is just country, but after verification from your open Id provider that service X wants information Y, you can drill all the way down to ICBM address.
I must confess I’m not an OpenID guru just yet, so maybe this is exactly the point of OpenID and I’m just reinventing some wheels.
Pascal Van Hecke http://pascal.vanhecke.info/
May 22nd, 2007Nice solution. I read something along the same lines at Brian Oberkirch (his problem was the proliferation of hcards all over the web - and the need for a “canonical” hcard):
“With OpenID, I could anchor an hCard on my site and tell search engines and other services that this is the ‘gold’ hCard I want used for my contact information. What I change here should be thought of as current, and I want all services to pull from that.”
http://www.brianoberkirch.com/?p=820
Some openid providers already have hcard info (vb: http://danda.videntity.org/ ) on profile pages or import hcard info while creating a profile.
(apologies for the dummy comment as I was trying to log in, I get your point on the separation of commenting and logging in at Simon Willison’s blog
)
Robert http://robertgaal.myopenid.com/
May 22nd, 2007Hm, I see. This makes sense: http://bitworking.org/news/No_Fishing I’d like to see simplicity win over technical difficulties sometimes though
I still feel that OpenID and microformats are just tools to something a bit bigger. A true portable authentication, presence, ownership, relations and identification standard.
Tijs, Alper, anybody: feel like an OpenCoffee in Amsterdam this thursday? We could brainstorm a bit.
tijs http://tijs.org/
May 22nd, 2007At least we know Chris read it; http://tinyurl.com/2re2ab
Go make that Wordpress plugin! Maybe we should make a little webpage explaining the initiative and offering some tools… openavatar.com & org were taken hostage which is too bad.
alper http://www.alper.nl
May 22nd, 2007Modifying the MyAvatar plugin to become OpenAvatar should be a piece of cake. Just let me see where wpopenid stores that OpenID URL.
There are some issues for which I don’t have enough experience yet:
1. OpenID URLs should not be published without the consent of the user (as per the Implications of OpenID). The wpopenid plugin does not adhere to this, so I’ll leave it for now.
2. As I said a smart client should retrieve, transform and cache the avatars. I’ll save that for a future version.
damnian http://=damnian
May 22nd, 2007Nice, although hCard might be a bit of an overkill if avatar is all you’re after. When I was looking for an avatar solution for phpbb-openid, I found Pavatar:
http://openid.phpbb.cc/2007/03/13/avatar-invasion
Basically, all you need is a direct rel=”avatar” link. It just works
P.S. My OpenID isn’t http://=damnian
shirkevich http://shirkevich.myopenid.com/
May 22nd, 2007In addition to avatar person may wish to share more information with world. Did you look at foaf spec?
alper http://www.alper.nl
May 22nd, 2007@shirkevich: Don’t hCard and XFN do the same thing pretty much?
Napolux http://www.napolux.com
May 23rd, 2007Cool!
alper http://www.alper.nl
June 2nd, 2007Gavin Bell’s work on online provenance looks very much in the same direction.
He presented his work on XTECH.