February 3rd, 2008


Social Graph Foo Camp 2008: Review

Social Graph Foo Camp was great. Props to David Recordon, Scott Kveton, O'Reilly, and everybody that made it possible.

  • Got to discuss the Social Graph API in public finally. I got a bunch of good feedback/questions/requests.
  • google-sgnodemapper rules for hi5.com, dopplr.com with Paul Lindner and Matt Biddulph, respectively. Matt's going to work on Ruby bindings for sgnodemapper.
  • Great hCard/XFN discussion/education from Tantek Çelik.
  • Great FOAF/RDF discussion/education from Dan Brickley.
  • Hacking with Joseph Smarr and Tantek.
  • I came up with a tiny proposal for doing email -> URL mapping that people seemed to (surprisingly) all agree on, which solves a bunch of different problems.
  • Saw Shelf (so cool!).

A proposal: email to URL mapping

People have different identifiers, of different security, that they give out depending on how much they trust you. Examples might include:
  • Homepage URL (very public)
  • Email address (little bit more secret)
  • Mobile phone number (perhaps pretty secretive)
As has been shown with OpenID, XFN, etc... URLs are people too. You can do a lot of things with a URL: give out information, point to other identifiers, do Yadis service discovery on it (to find, say, an OpenID server, calendar server, friend/contact server, etc...)

It's also possible to do a <a href="mailto:me@example.com" rel="me"> to an email address, making a one-way claim that you own an email address. But how do you make a rel="me" back from the email address to a URL, completing the cycle?

Another problem people have been bringing up regularly is how to use an email address as an OpenID identifier. For this to work, you need to do service discovery on it to find out the O.

If you could map from email address to URL (going from a private identifier to a more public identifier), both problems are solved... the mapping from email to URL is the rel="me" link, and the pointed-to-URL can then be used for any URL-like purpose:
  • Being an OpenID identifier
  • hosting an hCard
  • Pointing to another Yadis service type (OAuth-protected friends/contact server)


How to map from an email to a URL?
I propose:

Given, say, bradfitz@my-email-service.com, you do Yadis capabilty discovery on my-email-service.com, looking in the resultant XRDS service document for a capability of type, say, "http://schemas.net/2008/email-to-url/", and the resultant endpoint which speaks that capability protocol. Here's an example document (retrieved via Yadis, which means sending HTTP Accept: header of right mime type and getting it immediately, or looking at link from <head>):

<?xml version="1.0" encoding="UTF-8"?>
<!-- Sample YADIS XRDS file -->

    <Service priority="0">


The 2008/email-to-url capability endpoint (email2url_mapper.cgi, in this example), then speaks this "protocol":
GET /email2url_mapper.cgi?email=bradfitz@my-email-service.com HTTP/1.1
Host: apis.my-email-service.com

HTTP/1.1 302 Found
Location: http://bradfitz.com/
That's about it.


Why the Yadis indirection?
That's what Yadis is for. Discovery capabilities of an endpoint. This is exactly how OpenID works. There are libraries for it. Yadis discovery is cached. In practice, this step won't cost.

Privacy! Stealing my email addresses!
No, you start with the email address. You already have it. It's up to the user to determine if they want a public URL (presumably more public than their email address) attached to their email address.

Why not use $X?
What's X? I'm not aware of anything else. (Except for something I saw recently which was tied to OpenID and was pattern-based)

Why not pattern-based?
I want to tell, say, hotmail.com that my URL is http://bradfitz.com/, not MSN Spaces, or whatever hotmail.com might choose for a static username-to-URL mapping. It needs to be a dynamic lookup, not a published pattern.

Why not tie this to OpenID?
Layering violation.

The 302 could include an expires header.

But only the dorks would support this.
Maybe, but that's how it always starts. Maybe we could get some big email providers to do this too. Imagine a tab in your favorite Big3/Big4's email options which says:
Your public URL: [___________________________]
(This is the web URL that will be given out to anybody with your email address.)

The end