curl -X GET http://email@example.com/
I've been typing email addresses into browser address bars for over a decade. Now, I want something back.
A User URI Scheme
mailto and (more recently)
methods of identifying an entity (person, bot,
etc) by an email address.
userinfo portion of a URI
provides for such a format in HTTP URLs:
The userinfo subcomponent may consist of a user name and, optionally, scheme-specific information about how to gain authorization to access the resource.
There's more in that spec and in the more recent
httpbis that runs away from the use of this
userinfo URI component, but there is untapped value here.
userinfo portion of the URL is mentioned in the WHATWG URL spec as follows:
Userinfo must be a username, optionally followed by a ":" and a password.
Note: emphasis added to both specs...'cause that's the important bit.
HTTP clients will send a URL containing a
component as an HTTP Authorization header. For the
URL above, the outbound request looks like:
GET / HTTP/1.1 Authorization: Basic YnlvdW5nOg== User-Agent: curl/7.26.0 Host: bigbluehat.com Accept: */*
The server will treat this as an HTTP Basic
Authentication request. That Base64 encoded
bit after the word "Basic" above is the username
byoung without a colon. Most clients will also include
: in Base64 portion. This can be stripped
server-side of course, but should not be sent in
the first place (re:
Returns HTML + microformat hCard markup (at the moment).
curl -H "Accept: text/turtle" http://firstname.lastname@example.org/
Returns a WebID document.
curl -H "Accept: image/jpeg" http://email@example.com/ > byoung.jpg
Returns a photo.
For me, this means a RESTful endpoint for myself. I intend to use content negotiation to deliver my profile pic (in various formats) and social or authentication related markup: FOAF, XRDS, and hCard + OpenID discovery meta tags (done, but needs further testing and exploration).
For the web, my hope is this will prove a useful
pattern that could be adopted to more simply
locate a person's public content. It's easy to
imagine profile URLs such as
which at the very least could 302 to my current
Twitter profile: http://twitter.com/bigbluehat
There's much more to explore and explain, but this idea has sat in my head far too long and I needed it out in the wild to make room for new ones.
My hope is to work this toward an Internet-Draft at the IETF where I'd love to see it become an RFC that people find useful, interesting, and at least inspring.
The biggest need right now is client testing, reporting, and patching.
I'll be documenting this idea further in this repo in the coming weeks. For now, please use the issues on this repo to send me your thoughts.
All code (forthcoming) will be licensed under the Apache Foundation License 2.0.