Honest Cruft

When I went looking for a FOAF file to copy for my playing around with Ajax, RDF, Flickr, and so on, I immediately thought of Dan Brickley’s FOAF file, and once I had copied it locally, I just plugged it into my application, without validating the RDF/XML first. I did so with confidence because I knew that, if there was one FOAF file guaranteed to be cruft-free, it was Dan’s.

There’s more to ‘trust’ on the internet than is covered by openID: a person can create cruft and still be honest. What we need, as the number of services and data endpoints expand, is a way of attaching trust to the quality of a service–not to mention trust as to whether the service can be hacked and we’d be at risk using their data in our Ajax applications.

I have a great deal of trust with Flickr, but even when I was working on the book, one of their services went out, just for a few minutes, just as I was testing something. Still, I knew it would come back. Why? It was Flickr. The entire site would most likely be taken down before the API would be stripped–or Stewart Butterfield would be fired before he’d let it be stripped.

This is a measure of trust associated with how long a service will be available. If a service is pretty stable, such as Google Maps, or Flickr, or others of that sort, we can integrate such more heavily into our work. However, if the company is a startup, in trouble financially, well then, we better keep any integration at a surface level, ready to cut loose at any moment.

There’s issues associated with whether a service was meant for internal or external access. The recent del.icio.us JSON endpoint service, the Tagometer, wasn’t necessarily meant for completely open-ended use. I’m sure the organization won’t yank it, but…I’d only moderately integrate it into my applications, and keep a replacement handy.

How about ads? Payment? Google has always kept the door open for adding ads to Maps, but the company has said it would provide several days notice. Still: if our mashups, widgets, what have you become dependent on Google Maps, what happens when the ad drops?

We’ve focused so much on people and trust, that we’ve forgotten how much we’re putting our applications, our widgets, our web sites, and even our businesses at risk because of the services and data we’re tying into. What we need is an OpenID for data services: can this data be trusted, is this data trustworthy, is this data coming from the correct spot–hey, is this company going belly up? Does it have dangerous elements? Perhaps what we need is a trust scale we can apply to a service to determine how much we want to depend on such. ProgrammableWeb has a rating system, but let’s face it, that’s more a rank on the ‘coolness’ factor, than the stability, trust, and general warm and fuzziness.

Then there is the issue of our service requests: how about a ‘signature’ we can attach to our requests? Hi, this is Shelley passing through. No worries, I’m not a spammer. Looks like this one has been asked at the OpenID forum. It would be nice to have an API key that I could use with all services. More importantly, though, I’d like to establish a level of trust, so when I hammer the service, hopefully those who are monitoring the service see it’s only me, and I wouldn’t hurt a fly.

This entry was posted in Stuff. Bookmark the permalink.

2 Responses to Honest Cruft

  1. Danny says:

    I very much like the idea of using OpenID for trust in service calls etc, but are ratings actually necessary beyond go/no-go? (I don’t know ;-)

    One other aspect to the mortal service point (which sprang to mind because I’m playing in similar areas) is a way of representing & using alternate, approximately equivalent services. So if you’re preferred tag-lookup service or whatever goes down, your application can automatically use a fallback.

  2. Shelley says:

    That would assume, though, that we have a lot of services, all of which duplicate each other.

    A tag in del.icio.us isn’t the same as one in Flickr, or one in Technorati. Even a tag in Zooomr isn’t the same as one in Flickr: we have to assume most folks don’t use the same service, and upload the same photos.