OpenID - Everybody Wants To Go To Heaven, Nobody Wants To Die

I've been looking recently at OpenId a little more closely. It's a great system, that I've been using for a number of years.

My first free openid provider (http://stuartyeates.videntity.org/) went belly up for reasons I'm still not too sure about, but the life expectancy of internet startups and free services has never been that long. I have a new identity (http://stuartyeates.myopenid.com/) which does me just fine.

One thing I've been noticing is that while a host of the internet services that I use want to be my identity provider, very few of them want to let me login using an openid provided by another identity provider. From a business point of view I can completely understand this: they want to know everything about the user so they can (a) off better, more integrated services and (b) see more customised advertising. I have no problem with (a), but (b) is one of the reasons I'm eying up openid in the first place.

They don't understand that to get to openid heaven, they're going to have to die. By giving away the user-authentication-and-give-us-your-personal-information step, they can drive significantly more logins and significantly deeper interaction with their website and with their content. Sure, they can't necessarily get access to the users email address and whatever fake personal details they submitted at sign up, but I've yet to see this used particularly well anyway. The personal details certainly don't seem to be used to anywhere near the same effect as analysis of user behaviour.

What would be really good is an openid identity provider with (a) shared no information with any of the large advertising groups or dominant internet companies, (b) really clear information about privacy expectations (and I'm not talking here about a page of legalese titled "privacy policy," but discussion and disclosure of things which jurisdictions user data is stored in, steps taken to avoid collection of user data, etc) and (c) a clear sustainability model to prevent it being bought-out for the user data and to ensure it's continuity (I can imagine paying a subscription for it).

I can imagine that this is the kind of thing that google or yahoo might sponsor in their efforts to promote their next generation of web authentication standards. The existance of such an outfit would hugely boost the reputation of such a standard and lacking the huge advertising and existing lockin it would hardly challenge their own identity providers while answering a whole range of independence, privacy and monopoly questions.

Tinkering with ohloh

I've been tinkering with www.ohloh.net, which is probably best described as a web 2.0 freshmeat. Rather than tracking manually-updated releases it relies on automatically detected updates to version control repositories, RSS and geo-urls. It relies on wiki like editing rather than the strict ownership rules of freshmeat. ohloh does automatic language detection and source code analysis based on the version control repository and attributes individual commits to specific developers and their ohloh user account.

I've added and am actively curating a group of go/baduk projects. The overall goal is to encourage reuse and reduce the willingness of hackers to rewrite go/baduk systems from scratch.

My next step on the technical side is to write some GRDDL (Gleaning Resource Descriptions from Dialects of Languages) to transform the XML returned by the API into RDF, which I can them import into simal.

My next step on the social side is to mention what I'm doing in some of the go/baduk mailing lists, but I want to wait until I've got something concrete to provide that Sensei's Library (the current repository of information about go/baduk programs) hasn't already got.

Happiness is tests passing

All tests passed
Originally uploaded by Stuart Yeates


2 tests failing

I've just (re-)attained the happy state of the unit tests passing in the key package of jgogears. I've invested a surprising amount of time and energy in the unit tests, mainly as a form of requirements analysis, and I'm really pleased with the result.

Sadly, the core package that contains much of the code has some outstanding, longstanding failures which are going to be challenging to fix. They are represent failures in jgogears' ability to round-trip board states between GNU-Go ASCII and SGF files and will require a bug-for-bug reimplementation of the GNU-Go ASCII board printer.

jgogears has reached the stage where it now plays games that are obviously meant to be go, but is not yet a serious contender.

Resetting vmware networking

I had a hardware glitch (apparently chained failure of on-board network card, auto-negotiation on switch, auto-negotiation on larger switch) which left networking on my ubuntu edgy box somewhat randomised. Ubuntu recovered after a reboot, successfully finding the new network card (but calling it eth11). vmware-server didn't recover, and no amount of fiddling with the magic of vmware-config-network.pl would cause vmware to forget all it knew about networking and look only at the current state of play.

In an attempt to erase it's memory I removed /etc/vmware/locations but this caused vmware-config-network.pl not to run at all.

Eventually I worked out that the trick was to remove everything in /etc/vmware/locations other than the lines near the start telling it where to find directories and executables and rerun vmware-config-network.pl selecting all the defaults.

Suddenly everything worked.

Quality explanations of technical issues

I'm a big fan of clear explanations. If you want to explain something to someone (and given the alternative is letting everyone learn from their own mistakes, this has got to be good), clear explanations are really important. I've tutored computer science at uni and I've explained open source concepts to a whole range of people as part of my work at OSS Watch and come to learn that an analogy can be very useful.

Imagine my pleasure at reading this analogy of a really rather complex compiler / interrupt issue.

For the record, I know nothing about the x86 interrupts, since we were taught interrupts using the much simpler RISC SPARC system.

Tinkering with suffix-trees and algorithms

I've been tinkering with learning algorithms for my computer-go player, jgogears.

It linearises board positions and then uses classic string processing techniques, principally a large suffix-tree. Suffix-trees are widely used in information processing, information theory and compression fields of computer science. I also used them extensively in my recent Ph.D.

Currently I'm training with about 200 go games (~40k moves), giving me about 950K nodes in my suffix tree.

I've just switched my linearisation method from a strict distance measure to one which capitalises on adjacency much better.

There are a number of tuning parameters for the rate at which I grow the tree. I'll be tinkering with them as I increase the number of boards I'm using for training.

RedHat's MugShot and lockin

I've been playing with MugShot, the RedHat's venture into the social networking sphere. I was initially impressed by the site, which has builds a dynamic (if HTML-only) website while asking for really very little information and not asking for any confidential information (i.e. no asking of gmail passwords to pester friends to join up). The website is slick and glossy, if a little heavy on my dialup connection.

The more I use MugShot, however, the more I see it supporting rather than undermining lockin in the social networking sphere.

1 Login with Gnome account or local username/password

While many of MugShot's Gnome account initial target audiance may have had Gnome accounts suitable for logging into to MugShot, I'm guessing that a really small proportion of people they knew did. Login using openid or similar would be great.

2 Supporting only a small number of services, and not flexibly

It's great that mugshot supports delicious. However, by only supporting a single service of this kind, not only are my magnolia bookmarks unsupported, but the current delicious control over the social bookmarking market is strengthened. I understand that the differences between the delicious and magnolia APIs are largely cosmetic, and find it hard to believe that much effort would have been required to support it. Similarly, there are a number of exciting competitors to youtube, amazon, facebook and other MugShot supported services which could be supported with very little time and effort on the part of MugShot.

The services that are added, use a one-size-fits all approach, when I know of no two long-term users of (for example) facebook who use it in the same way.

3 No machine-readable export

There is (that I can see) no constructive machine readable export of any kind from MugShot. Two basic RSS feeds (which aren't advertised in the GUI). No RDF/FOAF, no blogroll for integration into the next generation of social networking and web services. MugShot may see itself as the top of the social networking heap, but until that's evident to the rest of us, they need to play nicely with third parties, both below them and above them on the heap. Failing to export anything useful in a machine-readable format is not playing nicely.

4 No "deep connection" back to the data sources

Having configured MugShot, I can see lots of books, photos and links that those in my network find interesting. But even though Mugshot can tell the difference between books, photos and links when it's displaying them and knows about the accounts I have on services for bookmarking, favouriting or commenting on books, photos and links it doesn't offer functionality to bookmark, foavourite or comment on them. By not driving content and information back to the underlying datasources, MugShot undermines the underlying services and devalues them, in so doing it also (a) devalues the commitment and investment I've made to those systems and (b) reduces the likelihood that those services will go out of their way to help MugShot.

5 "Invitation to tinker" only covers look-and-feel

MugShot has a great system for creating skins for music players, and several hundred people appear to have accepted this invitation to tinker and made come great skins. Unfortunately only cosmetic changes are possible. What I would like to see is a generic feed subscription creator which let me add new services that MugShot could listen to. Just like the music player skins, only a very small proportion users would bother, and most of those who did would not produce anything to shout about, but with a feed subscription creator, each success would lead to a whole new service that Mugshot could access and channel to their users. Such a effort would completely alleviate issue problems with the small number of supported services.

MugShot has an invitation to tinker in the traditional open source web 1.0 sense, with a wiki and version control system, but it doesn't have an invitation to tinker in the web 2.0 sense in which users can scratch their itch (and make the project better) from within their browser in the way the yahoo pipes, for example, does.