A must-read for those who care about standardised access to non-public Web data.
People want full ownership and control of their information so they can turn off access to it at any time. At the same time, people also want to be able to bring the information others have shared with them—like email addresses, phone numbers, photos and so on—to other services and grant those services access to those people’s information. These two positions are at odds with each other. There is no system today that enables me to share my email address with you and then simultaneously lets me control who you share it with and also lets you control what services you share it with.
“On Facebook, People Own and Control Their Information”, Mark Zuckerberg, Facebook blog.
A quick link roundup:
“The following provides some guidelines for the user interface define of becoming an OAuth service provider”
Detailed notes on UI issues, with screenshots and links to related work (opensocial etc.).
Myspace’s OAuth Testing tool:
The MySpace OAuth tool creates examples to show external developers the correct format for constructing HTTP requests signed according to OAuth specifications
… to help developers cure their OAuth woes. You can use the Playground to help debug problems, check your own implementation, or experiment with the Google Data APIs.
If anyone figures out how to post files to Blogger via their AtomPub/OAuth API, please post a writeup! We should be able to use it to post RDFa/FOAF etc hopefully…
Finally, what looks like an excellent set of introductory posts on OAuth: a Beginner’s Guide to OAuth from Eran Hammer-Lahav.
The laconi.ca microblogging platform is as open as you could hope for. That elusive trinity: open source; open standards; and open content.
The project is led by Evan Prodromou (evan) of Wikitravel fame, whose company just launched identi.ca, “an open microblogging service” built with Laconica. These are fast gaining feature-parity with twitter; yesterday we got a “replies” tab; this morning I woke to find “search” working. Plenty of interesting people have signed up and grabbed usernames. Twitter-compatible tools are emerging.
At first glance this might look the typical “clone” efforts that spring up whenever a much-loved site gets overloaded. Identi.ca‘s success is certainly related to the scaling problems at Twitter, but it’s much more important than that. Looking at FriendFeed comments about identi.ca has sometimes been a little depressing: there is too often a jaded, selfish “why is this worth my attention?” tone. But they’re missing something. Dave Winer wrote a “how to think about identi.ca” post recently; worth a read, as is the ever-wise Edd Dumbill on “Why identica is important”. This project deserves your attention if you value Twitter, or if you care about a standards-based decentralised Social Web.
I have a testbed copy at foaf2foaf.org (I’ve been collecting notes for Laconica installations at Dreamhost). It is also federated. While there is support for XMPP (an IM interface) the main federation mechanism is based on HTTP and OAuth, using the openmicroblogging.org spec. Laconica supports OpenID so you can play without needing another password. But the OpenID usage can also help with federation and account matching across the network.
Laconica (and the identi.ca install) support FOAF by providing a FOAF files – data that is being indexed already by Google’s Social Graph API. For eg. see my identi.ca FOAF; and a search of Google SGAPI for my identi.ca account. It is in PHP (and MySQL) – hacking on FOAF consumer code using ARC is a natural step. If anyone is interested to help with that, talk to me and to Evan (and to Bengee of course).
Laconica encourages everyone to apply a clear license to their microblogged posts; the initial install suggests Creative Commons Attribution 3. Other options will be added. This is important, both to ensure the integrity of this a system where posts can be reliably federated, but also as part of a general drift towards the opening up of the Web.
Imagine you are, for example, a major media content owner, with tens of thousands of audio, video, or document files. You want to know what the public are saying about your stuff, in all these scattered distributed Social Web systems. That is just about do-able. But then you want to know what you can do with these aggregated comments. Can you include them on your site? Horrible problem! Who really wrote them? What rights have they granted? The OpenID/CC combination suggests a path by which comments can find their way back to the original publishers of the content being discussed.
I’ve been posting a fair bit lately about OAuth, which I suspect may be even more important than OpenID over the next couple of years. OAuth is an under-appreciated technology piece, so I’m glad to see it being used nicely for Laconica. Laconica installations allow you to subscribe to an account from another account elsewhere in the Web. For example, if I am logged into my testbed site at http://foaf2foaf.org/bandri and I visit http://identi.ca/libby, I’ll get an option to (remote-)subscribe. There are bugs and usability problems as of right now, but the approach makes sense: by providing the url of the remote account, identi.ca can bounce me over to foaf2foaf which will ask “really want to subscribe to Libby? [y/n]“, setting up API permissioning for cross-site data flow behind the scenes.
I doubt that the openmicroblogging spec will be the last word on this kind of syndication / federation. But it is progress, practical and moving fast. A close cousin of this design is the work from the SMOB (Semantic Microblogging) project, who use SIOC, FOAF and HTTP. I’m happy to see a conversation already underway about bridging those systems.
Do please consider supporting the project. And a special note for Semantic Web (over)enthusiasts: don’t just show up and demand new RDF-related features. Either build them yourself or dive into the project as a whole. Have a nose around the buglist. There is of course plenty of scope for semwebbery, but I suggest a first priority ought to be to help the project reach a point of general usability and adoption. I’ve nothing against Twitter just as I had nothing at all against Six Apart and Movable Type, back before they opensourced. On the contrary, Movable Type was a great product from great people. But the freedoms and flexibility that opensource buys us are hard to ignore. And so I use WordPress now, having migrated like countless others. My suspicion is we’re at a “WordPress/MovableType” moment here with Identica/Laconica and Twitter, and that of all the platforms jostling to be the “new twitter”, this one is most deserving of success. With opensource, Laconica can be the new Laconica…
You can follow me here identi.ca/danbri
I am very happy to announce that Drupal’s OAuth module is now ready to use. Right now it just acts as server because we don’t need client support at this time, Client implementation will be done soon by the time release of Drupal 7 as ServicesAPI in Drupal 7 will be needing it. Endpoints for Drupal are:
At this time Services API is necessary to use OAuth (also it is the only module which is gonna use oauth as well – so not a big deal). This module also provides a test browser to produce OAuth tokens (whole Drupal way using multi-page form). Right now only PLAIN-TEXT signature method is supported but soon support for other methods will be added as well.
I’m slowly learning my way around Drupal, so this is rather good encouragement to learn faster…
See the announcement for more details and links.
Just want to let you know that we officially support OAuth for all Google Data APIs.
See blog post:
You’ll now be able to use standard OAuth libraries to write code that authenticates users to any of the Google Data APIs, such as Google Calendar Data API, Blogger Data API, Picasa Web Albums Data API, or Google Contacts Data API. This should reduce the amount of duplicate code that you need to write, and make it easier for you to write applications and tools that work with a variety of services from multiple providers. [...]
There’s also a footnote, “* OAuth also currently works for YouTube accounts that are linked to a Google Account when using the YouTube Data API.”
See the documentation for more details.
On the YouTube front, I have no idea what % of their accounts are linked to Google; lots I guess. Some interesting parts of the YouTube API: retrieve user profiles, access/edit contacts, find videos uploaded by a particular user or favourited by them plus of course per-video metadata (categories, keywords, tags, etc). There’s a lot you could do with this, in particular it should be possible to find out more about a user by looking at the metadata for the videos they favourite.
Evidence-based profiles are often better than those that are merely asserted, without being grounded in real activity. The list of people I actively exchange mail or IM with is more interesting to me than the list of people I’ve added on Facebook or Orkut; the same applies with profiles versus tag-harvesting. This is why the combination of last.fm’s knowledge of my music listening behaviour with the BBC’s categorisation of MusicBrainz artist IDs is more interesting than asking me to type my ‘favourite band’ into a box. Finding out which bands I’ve friended on MySpace would also be a nice piece of evidence to throw into that mix (and possible, since MusicBrainz also notes MySpace URIs).
So what do these profiles look like? The YouTube ‘retrieve a profile‘ API documentation has an example. It’s Atom-encoded, and beyond the video stuff mentioned above has fields like:
<yt:age>33</yt:age> <yt:username>andyland74</yt:username> <yt:books>Catch-22</yt:books> <yt:gender>m</yt:gender> <yt:company>Google</yt:company> <yt:hobbies>Testing YouTube APIs</yt:hobbies> <yt:location>US</yt:location> <yt:movies>Aqua Teen Hungerforce</yt:movies> <yt:music>Elliott Smith</yt:music> <yt:occupation>Technical Writer</yt:occupation> <yt:school>University of North Carolina</yt:school> <media:thumbnail url='http://i.ytimg.com/vi/YFbSxcdOL-w/default.jpg'/> <yt:statistics viewCount='9' videoWatchCount='21' subscriberCount='1' lastWebAccess='2008-02-25T16:03:38.000-08:00'/>
Not a million miles away from the OpenSocial schema I was looking at yesterday, btw.
I haven’t yet found where it says what I can and can’t do with this information…
danbri: fireup, help?
[13:29] fireeagle: danbri: I have just sent you a URL in privmsg, please click on it to authorize.
[time passes... things happen behind the scenes...]
[13:31] danbri: fireup Leiden, Netherlands
[13:31] fireeagle: Updating danbri to Leiden, Nederland
[13:32] • danbri gives fireeagle a botsnack
Behind the scenes, the bot passed me an URL:
fireeagle: Try Again! You must authorize first: https://fireeagle.yahoo.net/oauth/authorize?oauth_token=XYZABCD
And clicking this took me off into the Fireeagle Web UI, where I had to reconfirm my membership (3 months had lapsed; it times out if you don’t show signs of life). Then I had to give the IRC bot permission to access my Fireeagle data, and finally it send me to a duff return URL,
…which is understandable-ish given that IRC bots aren’t normal Web apps, though I wonder if an IRC URI would be allowed per the OAuth spec. I know there is work on wiring XMPP and OAuth together, after all.
So now Fireeagle and downstream apps (eg. the MacOSX widget pictured here) can learn about my location when I tell this IRC bot where I am.
So logged into Fireeagle Web site now I read:
Fire Eagle last spotted you about 1 hour ago in Leiden, Nederland using Fire Eagle GeoIRC bot. If you’ve gone somewhere else, then you should update your location!
And here’s the corresponding MacOSX widget:
Since I don’t use nickserv on the OFTC IRC network, this means anyone logged in there as ‘danbri’ can set my location data at Fireeagle. But at least they can’t add Facebook buddies, read my private email or ‘your password has been reset’ messages. And if they do, Fireeagle lets me revoke this token without messing up anything else.
Now, how to convince Dopplr to believe what it oauth-reads at Fireeagle? Logging into Dopplr by OpenID (hurrah :), I read the following falsehood:
…and when I try to tell it I’m actually in the Netherlands for a few days, and that my June 17th Dopplr journal entry “You returned from a trip to Guadalajara.” wasn’t a return to Bristol, it gets stuck: “Sorry, we couldn’t add that trip: You need a return date“. On closer inspection this seems to be my error; Dopplr has a new facility for multi-stop trips and if I’d added a Leiden stage to this last trip before it seemingly finished, Dopplr, Fireeagle and the IRC bot would be in agreement about my location.
So what’s so interesting about all this? Partly that OAuth provides a reasonable and deployable model for wiring up data pipes between socially oriented Web sites (and with some provisos, non-Web UI too), so that each can specialise in some task or domain. But also that, when the specialities of these sites and services do overlap, we’ll get into the business of conflict resolution amongst competing claims. When Dopplr reads that Fireeagle thinks I’m in Leiden, despite the last trip it knows about supposedly returning me to Bristol on the 17th, what should it do? Perhaps update its own state to a “well nobody told me, but it seems he’s in the netherlands” position?
ps. Fireeagle remains invite-only, and I don’t have any invites. Sorry about that, for those who haven’t tried it yet. There are some screenshots and a writeup at TechCrunch at least. Basically it’s an information broker for your location data, with data access mediated largely through OAuth REST APIs. For those with an invite, the developer docs have more detail than I’ve yet managed to digest.
From Wei on the oauth list:
We are happy to announce that the Google Contacts Data API now supports OAuth. This is our first step towards OAuth enabling all Google Data APIs. Please note that this is an alpha release and we may make changes to the protocol before the official release.
See announcement thread for endpoint URL details, supporting tools and implentation discussion.
For more on the Contacts API, see the developer’s guide (although bear in mind it may not be up to date w.r.t. oauth).