microformats

Liminal Existence

Clouds in Iceland

Tuesday, May 05, 2009

Simple Addressing for the Web, Part 1

Addressing is important. It's something that many people have tried to solve.

I'm interested in addressing because it's an important piece of web-scale messaging, and of the federated social networks that are an emergent property of verified cross-site communication. In order to communicate with someone, you need to be able to route your communications to them.

The URL is the thing. Except when it's not.

The URL was supposed to become the way that we negotiated identity. We were supposed to have a "home page," a place on the internet to call our own. It didn't quite work out that way, and at the same time as Geocities is shutting down, we're finally facing the need for a strong conception of identity on the web.

It goes without saying these days that everything we do, everything we interact with, has an associated URL. I can give you my blog URL so that you can read my posts, or my calendar URL so that you can invite me to events. However, for the vast majority of users, URLs aren't a viable option. Fundamentally, it's a lack of consistency (or, put another way, unbridled diversity) that makes URLs unusable as identity markers. Take the following URLs as a proof-by-example:

  • twitter.com/blaine
  • myspace.com/romeda
  • flickr.com/lattice
  • search.twitter.com/search?q=%22Swine+Flu%22+OR+Flu
  • home.myspace.com/index.cfm?fuseaction=user
  • blogger.com/post-create.g?blogID=6135683561277543562
  • amazon.com/gp/pdp/profile/A1GUHSGP27QA4W

All of the above are URLs which I see while interacting with sites on the web. Unlike postal addressing, phone numbers, or email, there's no consistency. The path part of the domain may as well be line noise in the latter four examples. By association, the pattern used by Flickr, MySpace, and Twitter is a fluke. Beyond that, my username doesn't match across the three social networking sites, and as such it's nearly impossible for a friend, relative, or co-worker to guess what my URL is, even given a domain.

I don't see a way to fix URLs across the web so that we can encourage people to use them as identifiers. OpenID has tried, and the results are nothing short of abysmal.

Back to the Future

If not URLs, what should our new web addressable identities look like? The simplest answer is "like an email address." They're universally recognizable. Billions of people have email addresses and know how to use them. All the major IM providers have moved towards email-like addresses as identifiers (gone are the integers of ICQ). Most importantly, email addresses are easy to construct and resolve.

The net result of this line of thought is that instead of @blaine for my Twitter address, I'd be blaine@twitter.com, and on Identi.ca I'd be blaine@identi.ca. I could share my Myspace identity as romeda@myspace.com, and on Facebook I could be blaine.cook@facebook.com.

The problem is that those addresses conflict with an already-existing namespace, specifically email. Which isn't surprising, but it is problematic. Can you send me an email at blaine@twitter.com or romeda@myspace.com? What happens when you do? Unfortunately, there aren't clear answers for those questions, and while some social networks might choose to make "Social Network Addresses" work as email addresses, it would be an uphill battle to convince all providers to do so.

Use What's Already There

I've been thinking about this problem a lot lately, and while the approach of re-using email semantics to provide human-readable web addresses/identities is very attractive, the proliferation of addresses (one for each network) and namespace collisions are less than ideal. After having extensive conversations with Alexis Richardson and Tony Garnock-Jones, the general approach for discovery became clear to me, but I didn't have a more generally applicable form for the addresses themselves.

Eventually, talking over the problem with John Panzer and Breno de Medeiros at Social Web Foo, the solution was there, blazing as bright as the California Sun; Google Profiles means that Google is now providing links to all my social network profiles. They're also my email provider.

My email address is romeda@gmail.com. If you transform that to http://www.google.com/profiles/romeda, you get my profile data, and away we go. Every email provider these days has a website, and Eran's LRDD, new on the scene, provides a discovery mechanism that everyone (i.e., every mail provider, even if they're only hosting static content) can implement in just a few minutes.

This is an important, exciting transformation. Now, with one identifier, I can share all the social bits of myself to anyone I please.

Where are my photos? romeda@gmail.com.

Where's my calendar? romeda@gmail.com.

What's my phone number? Look it up with romeda@gmail.com, and I'll give you permission to see it and store it in your address book.

They're all the same.

If I want to share a different set of social interactions, say, my work identity, I can give my Osmosoft or BT addresses, blaine@osmosoft.com and blaine.cook@bt.com, respectively. Now just photos of conferences come up, and the calendar that you'll find is my work calendar, not my social calendar.

Talking about this problem with others unearthed a post last year by Brad Fitzpatrick and EAUT, which were both aimed at solving the OpenID problem, but both take the same approach as the one that I outline here. EAUT seems to have been lost in the swamps of XRDS-Simple, and Brad's post was probably too early to the races, in true Brad style (if you want to know what's coming to the internet in five years, just read his blog posts).

With a swift and general agreement-in-principle, there's been some very positive movement towards promoting this concept as a way to bring the power of strong identity that email provides to the web. John has an excellent post on the subject, and it seems like a name for the project has emerged: WebFinger.

Part Two (coming tomorrow) goes in depth about how this all works on the tech side. Bits on the wire, as Tim Bray says.

Labels: , , , , ,

24 Comments:

Anonymous Anonymous said...

This is very interesting! I never really thought much into URLs before. It's quite funny when you actually think of the concept in which they were made versus how we use them now. You really explained it well too!

-Chandace

Wednesday, 6 May 2009 01:09:00 GMT+01:00  
Anonymous Tom Carden said...

In summary: given an email address what social network profiles belong to that person? Aren't we back to FOAF and mbox hashes all over again?

Are you sure that email addresses themselves are any more uniform (*cough*) and meaningful than URLs? http://code.iamcal.com/php/rfc822/tests.php is frightening!

Wednesday, 6 May 2009 01:28:00 GMT+01:00  
Blogger David said...

Hi Blaine,

Is WebFinger designed to solely act as a glue layer between e-mail addresses and existing HTTP based services discovery ala Yadis/XRDS? I'm certain this has been worked on before, many years ago, back when I first researched Yadis (vague recollections regarding SRV records springs to mind).

I think the hard part here is still authentication, trust, and common data formats, discovery or a common transformation is relatively simple given these beasts. I'd certainly avoid having a machine-readable resource linking to my online life, while authentication of the remote party remain unaddressed. :)

David

Wednesday, 6 May 2009 01:43:00 GMT+01:00  
OpenID jsmarr said...

Blane-good thoughts, and I basically agree with all of this, but I do worry that it places too much power and responsibility in the hands of e-mail providers (to be the custodians of your links to other services). While Google/Yahoo/MSFT/AOL/etc are responsible and technically savvy providers, what about all the corporate domains and little ISPs and so on? Just saying "use LRDD" isn't enough--every site that's not an email provider is going to want to prompt their users to "add this site to your email-provider's site roster" (aka "I notice that IE is not currently your default web browser"). And managing links/access/discovery of non-public data is also non-trivial. And it puts most large social networks (who otherwise make great identity/service providers and nodes) at a structural disadvantage (since they need to be pointed to by an email provider). Not saying any of these issues are deal-breakers, but none are trivial to brush aside either, so I think this is where the dialog will have to focus next.

Wednesday, 6 May 2009 06:08:00 GMT+01:00  
Blogger Blaine said...

Tom: It's different than FOAF, since it's not discovery-of-your-friends, but discovery-of-a-person. FOAF+hashes is essentially an attempt of trying to publish all of your friends' email addresses without, well, publishing all of your friends' email addresses. With this approach, you add someone to a new social network exactly as you do now; that is, by entering their email address. The "who's my friend" discovery happens out of band (and will probably continue to happen primarily by rifling through your email contact list).

David: You're absolutely right; the key here is to address small pieces, while building something. The auth/trust question is one that we're much better suited to answer now than even a year ago. OAuth allows us to ask permission on the web, something we weren't able to do effectively a few years ago without writing code. I'm perfectly happy to publish my online life. The trick is that you don't get to see the good stuff unless we're actually friends, and I give you permission.

jsmarr: The providers are absolutely important. I'd actually go the other way, and say that I trust the small providers more than I do the big players, but maybe that's just me. ;-) It's also absolutely true that implementing this stuff probably isn't high on the small providers' list of priorities. However, open source comes in strong here, as does the fact that it's trivial to delegate to a "profile provider." As far as large social networks, my hope is that they'll come under pressure to actually be providers of these email-addresses-that-aren't-email-addresses; if they don't choose to do so, the nice thing about this approach is that it would be their choice, since there's no real competitive advantage for "email providers" inherent to the approach. The privacy question re: discovery is definitely a big one with lots of unanswered details. I'm definitely looking forward to nailing down the details and moving forward with this stuff!

Wednesday, 6 May 2009 09:33:00 GMT+01:00  
OpenID jpick said...

Problem: Looks like an email address. What if I don't want to invoke the idea that I'm reachable via SMTP? What if I'm not?

Maybe use a different separator to pair up service provider and username?

gmail.com:blaine maybe?

Wednesday, 6 May 2009 15:35:00 GMT+01:00  
Blogger Santosh Rajan said...

Blain: I think the users will end up using their email addresses rather than the "email-addresses-that-aren't-email-addresses". Any problem with that?

jsmarr: If the social networks are going to be at a disadvantage with this approach, they only have themselves to blame. They could have joined the party, they still can.

And finally slightly off subject. Is it possible for a dynamic OAuth generated on the fly, like associations in OpenID? That would really round this off nicely.

Wednesday, 6 May 2009 15:38:00 GMT+01:00  
Blogger Blaine said...

@jpick: That's why using your actual email address is so attractive. I think there's actually a cognitive aspect to the username AT domain approach. We learn addressing in early childhood; it's always of the form "(I live at) Specific Address, General Location, General Place"

The other thing that's interesting about using real SMTP addresses [as non SMTP-addresses] is that if my email provider doesn't support this discovery mechanism, you can just email me. In fact, this is exactly how social networks operate right now. When you go to add a friend (and I'm referring to explicit add, not bulk add which is just annoying), you enter their email address. If they're on the system (discoverable), then they get a request to be your friend. If not, they're sent an invite to the system via email. So this semantic is already in play, and building on top of it doesn't break anything but adds quite a bit of possibility.

Wednesday, 6 May 2009 16:28:00 GMT+01:00  
Blogger Blaine said...

@Santosh Rajan: Absolutely no problem with using real email addresses — that's the point! :-)

The dynamic OAuth is absolutely possible, but it's something that you can build on top of this, or separately, so I've chosen not to discuss it here.

Wednesday, 6 May 2009 16:30:00 GMT+01:00  
OpenID singpolyma said...

What's neat about email-style identifiers, is that you don't need to invent anything new to use them with OpenID or other URL-based systems. Why not? Because email addresses are valid URLs.

Think about it. http://singpolyma@yahoo.com/ is perfectly valid. That means if you run singpolyma@yahoo.com through a standard URL normalizer you get a URL that, in fact, already works as an OpenID. Hooray!

Wednesday, 6 May 2009 17:51:00 GMT+01:00  
Blogger Blaine said...

@singpolyma: How do you make the request? HTTP only allows for modification of the path in requests, and changing "Host: yahoo.com" to "Host: singpolyma@yahoo.com", while technically valid, doesn't work in practice with the installed base of HTTP servers, due to the way that domain-based virtual host routing works.

If we could make such a scheme actually work, I'd be all for it, but I'm not sure that it does.

Wednesday, 6 May 2009 18:12:00 GMT+01:00  
OpenID Anthony Eden said...

I'm biased, but http://anthony.mp/ does what you are talking about for me. It is my OpenID and also provides a unique URL that is consistent (since it is merely a second-level domain). I can tell people to go to anthony.mp and they see everything I want them to see about me and can use it as a starting point to get to other bits of content that I have scattered around the web.

Wednesday, 6 May 2009 18:58:00 GMT+01:00  
Blogger Blaine said...

Anthony: Absolutely. That said, not everyone has a second-level domain, and it's unlikely to ever be the case. There are a whole raft of reasons why this is the case, but suffice it to say that hierarchical naming schemes seem to work for people. I guess my offering would be that you could use "me@anthony.mp", as you likely do for email already. Is there a reason (any reason, really) that doing so doesn't work for you?

Wednesday, 6 May 2009 19:16:00 GMT+01:00  
Blogger Santosh Rajan said...

Consider this,
otherdomain.com/myname@mydomain.com
This is a valid url. The email address is the path here. Can this option be added to the scheme of things. This will solve all the problems you might face.
1) Users who cant have their own domain provide discovery, can point to another domain.
2) It also gives the user the freedom to change his discovery domain if he wants to.
3) You don't need to support "email-addresses-that-aren't-email-addresses".

Wednesday, 6 May 2009 22:41:00 GMT+01:00  
Blogger Blaine said...

Santosh: the problem with that approach is that there's no way to translate myname@mydomain.com to otherdomain.com.

So, for example, if I want to point you to my Flickr account, how do I do that? Sure, flickr can support "http://flickr.com/romeda@gmail.com", but I still have to tell you which photo site I use, and you have to know two pieces of information: (1) my email address, and (2) the site I use. After all that, we're still back to the issue that URLs suck for people.

The other problem is one of security / trust, and I think it's actually a much bigger issue here. Even if we were able to make this approach usable, what's to stop someone (i.e., not me) from claiming flickr.com/blaine@osmosoft.com? Flickr can stop them with special workarounds (e.g., email verification codes and the like), but in general there's no way for a 3rd party to know that just because flickr.com/blaine@osmosoft.com exists that it's owned by me.

Wednesday, 6 May 2009 23:29:00 GMT+01:00  
Blogger Santosh Rajan said...

Ok got it. Thanks Blaine.

Thursday, 7 May 2009 01:17:00 GMT+01:00  
OpenID carton said...

carton@Ivy.NET -> http://www.Ivy.NET/~carton/

in the default configuration of CERN/NCSA/Apache since 1995.

What exactly is the problem being solved here? Am I nauseous because I don't ``get it'', or have you really given up all sense of clue along with control of your data and namespace to google, yahoo, flickr, facebook, angelfire/geocities/jackoffAdHost? As far as i can tell, this is not just a solved problem, it simply isn't a problem, and hasn't been since the web was invented. It's just a problem for you because you don't have control of the computers you're using.

Thursday, 7 May 2009 03:27:00 GMT+01:00  
Blogger Blaine said...

carton: I'm not quite sure what to make of that. I'm going to ignore your more insulting comments for the moment, and instead ask if you mean it's been that way by convention, or if there's actually some way from the past to make an HTTP request that looks like:

GET / HTTP/1.1
Host: carton@Ivy.NET

and be redirected to http://www.Ivy.NET/~carton/? If you mean by convention, then you've missed the point entirely.

Thursday, 7 May 2009 09:58:00 GMT+01:00  
OpenID singpolyma said...

@Blaine: http://singpolyma@yahoo.com/ ... go ahead and type it into your browser or hit it with cURL, it's not theoretical, it works *today*.

How?

Recognize: http://username:password@domain.tld/

It's BasicAuth with a username and a NULL password.

Thursday, 7 May 2009 18:26:00 GMT+01:00  
Blogger Blaine said...

@singpolyma I appreciate that cURL does the translation to Basic Auth, but that's purely an artifact and not at all an approach that is supported by standards. In fact, HTTP URLs never allowed that syntax. The most recent URI specification, 3986, Section 3.2.1 explicitly deprecates the behavior across all protocols.

Moreover, a null Basic Auth password should produce 401 Access Denied response, not a machine-readable discovery document. Nearly all servers are configured this way. The nature of authentication handlers (i.e., intercepting handlers that modify environment variables) means that it's extremely unlikely that the existing installed infrastructure could be retrofitted to support this approach.

I asked in case there was some long-forgotten "Username: <x>" HTTP header that might assist us here. I wish we could directly support making requests to the literal URLs, but I just don't see it happening. WebFinger in that sense is an appeal to worse-is-better pragmatism.

Thursday, 7 May 2009 19:03:00 GMT+01:00  
OpenID singpolyma said...

@Blaine that section appears to deprecate the display of passwords, but accept the parsing of data entered in this way. It's not like cURL invented this. Every browser supports it, as well as all other URL parsers/HTTP libraries I have tried. As for server support, like I said, this works today with Yahoo. No changes to servers or clients is required, it *just works* :)

The fact that it happens to use BasicAuth is an artifact that doesn't seem to affect implementations.

Monday, 11 May 2009 23:59:00 GMT+01:00  
Anonymous Anonymous said...

I must be a bit slow - but if you manage to both implement it and turn this into a widely accepted tandard.... then what's the problem to add a couple' layers of gui and be able to create an open version of each and every popular service there is out there? namely an open version of all the services which you might want to return in the response?

twitter is literally another class to implement on top of this thing...
anyhow - at this stage, anything which is distributed and decentralized is fine with me.
of course the authorization issues are still quite vague, to say the least.

Sunday, 17 May 2009 19:42:00 GMT+01:00  
Anonymous Anonymous said...

I must be a bit slow - but if you manage to both implement it and turn this into a widely accepted tandard.... then what's the problem to add a couple' layers of gui and be able to create an open version of each and every popular service there is out there? namely an open version of all the services which you might want to return in the response?

twitter is literally another class to implement on top of this thing...
anyhow - at this stage, anything which is distributed and decentralized is fine with me.
of course the authorization issues are still quite vague, to say the least.

Sunday, 17 May 2009 19:42:00 GMT+01:00  
Anonymous Anonymous said...

I must be a bit slow - but if you manage to both implement it and turn this into a widely accepted tandard.... then what's the problem to add a couple' layers of gui and be able to create an open version of each and every popular service there is out there? namely an open version of all the services which you might want to return in the response?

twitter is literally another class to implement on top of this thing...
anyhow - at this stage, anything which is distributed and decentralized is fine with me.
of course the authorization issues are still quite vague, to say the least.

Sunday, 17 May 2009 19:42:00 GMT+01:00  

Post a Comment

Links to this post:

Create a Link

<< Home