Re: HTTP idea

[Michiel de Jong]

Forwarding with Benjamin's permission, curious what other people think
of this! We definitely need to think more in terms of this sort of
per-user web, and less in terms of client-server websites.

On Fri, Jun 22, 2012 at 3:20 PM, <byo...@bigbluehat.com> wrote:
> I've been toying with an idea for identification "routing" on the Web. By
> that, I mean a simpler URL pattern/design for things like OpenID, WebFinger,
> etc. URL-based login identifiers were said to be one of the major adoption
> hurdles for OpenID.
>
> The idea sprang from a bad/lazy/accidental habit I formed of occasionally
> typing in a person's e-mail address into the location bar of my browser.
> Needless to say I've been frequently disappointed. :)
>
> One day, I realized I *should* be able to do that! And in fact, HTTP already
> had specs (HTTP Basic) that looked quite similar to an e-mail address
> (http://user:pa...@domain.com/ which of course you know). :)
>
> My idea, is simply a "tweak" to HTTP Basic that would allow a different
> interaction if the password *and* the preceding colon are left off.
>
> So, http://byo...@bigbluehat.com/ would respond as if it were any other HTTP
> resource and not with an authentication request.
>
> I realize that "inside" the HTTP packets, it doesn't look like a nice,
> e-mail address-looking URL, but rather something like this:
> GET /
> Host: bigbluehat.com
> Authorization: Basic YnlvdW5n
>
> If the server received an Authorization header which, upon base64 decoding,
> had no ":" or anything to the right of it, then it would "upgrade" or
> "reconsider" the request as an "identity" request and return some
> identifying information--based on the server's setup, user's preferences,
> and included Accept headers.
>
> In the typical (or most-likely-to-be-implemented) case, the above address
> would return an HTML page containing "discovery" content for OpenID,
> WebFinger, etc. That HTML may also be that person's public profile
> (about.me, flavors.me style) or even their public microblogging feed
> (imagine http://bigbl...@twitter.com/ returning or redirecting to my
> twitter stream).
>
> This topic of "humanely parse-able URLs" is coming up more and more. OpenID,
> WebFinger, WebID, and i-names all offer "strange" looking (from a user
> perspective) URLs that "mimic" e-mail or Twitter-style identifiers
> (sometimes at a monetary cost to the user), and they're likely to be
> unmemorable. Additionally, it's often recommended by those specs, that the
> HTML-level discovery mechanisms be placed in a more memorable
> location...like the user's home page or blog URL. This spec/idea would
> provide a memorable location for just that sort of thing (in addition to
> other valuable uses).
>
> Now, besides HTTP spec tweaking/changing/amending/extending, there's
> obviously the concern of "exposure" of e-mail address, etc. If the
> "Authorization" header is used (and/or augmented with an "Identification" or
> similar header), then HTTPS should suffice in "hiding" things (to some
> extent). Browsers already do a good job of not keeping these URLs in your
> browser history/cache--at least not with the creds attached. That said, in
> the ideal setup, I'd very likely want to link to
> http://mic...@unhosted.org/ in a FOAF doc, XFN, or similar, and my doing
> that could expose that address to "spammers." However, that's the same risks
> we have now with mailto. The additional risk would be intermediaries and
> even destination servers "catching" requested headers (if not sent over
> HTTPS) and doing something malicious with the findings. However, all of
> those are likely separate considerations.
>
> References:
> OpenID: https://openid.org/
> WebFinger: http://code.google.com/p/webfinger/
> WebID: http://www.w3.org/2005/Incubator/webid/spec/
> i-names: http://www.inames.net/

[Michiel de Jong]

and this is what i replied:

On Fri, Jun 22, 2012 at 4:49 PM, Michiel de Jong <mic...@unhosted.org> wrote:
> cool! it's inventive, but as you also say yourself, it's a bit hacky.
> i think it can be improved.
>
> we hardly ever type the 'http://' or 'https://' in our browser address
> bar. the browser assumes we mean http://, and firefox and chrome also
> offer search straight from the address bar if you type in something
> that could not be a URL.
>
> so it would be easy (and Paul Jones suggests this, i think) to make
> the browser's address bar treat 'user@host' as not http://user@host/,
> but as acct:user@host. So basically, what you invented is the acct:
> scheme. :)
>
> another question is if we still need to address bar at all. Domain
> names and user addresses were a big step forward from IP addresses.
> but nowadays, how do most people get to the content they like?
>
> - use search terms, for instance first name + last name when searching
> for a person
> - icons on a home screen to get to apps
> - bookmarks in a bookmarks menu to get to reference material
> - using google as DNS (typing in 'facebook' as the search query)
> - searching on facebook
> - ISP home page
>
> that's only for actively going out to look for information - a lot of
> people just consume what comes recommended to them, and don't
> necessarily ever go to content, apart from to the tools that flood
> them with information.
>
> also, as a lot of web consumption now takes place on devices without
> proper keyboards, how important is the address bar nowadays? it's
> definitely not the only way to get to information.
>
> there is one special situation which is when you connect to your own
> account - for instance when you power on an android device for the
> first time, and it asks you to to specify your google account (or
> create one). We want remoteStorage to be the equivalent of that for
> Mozilla Boot2Gecko. There, we need people to type in their (own) user
> address.
>
> After that, they might type in the occasional user address of a peer
> when they send a friend request. but even then, they might already use
> first name + last name. or a QR code on a business card. Or what about
> facial recognition from the device camera?
>
> If we have to change how browsers work anyway to implement your
> scheme, then we might as well implement acct: support in the address
> bar, and tell IdP's to simply implement webfinger. I mean, your scheme
> makes sense, but given that webfinger already exists, i don't think it
> does anything webfinger can't do?
>
> is it ok to forward this to the unhosted mailing list? i think more
> people will find it an interesting idea!
>
> hth :)
>
> cheers!
> Michiel

[Melvin Carvalho]

On 22 June 2012 17:58, Michiel de Jong <mic...@unhosted.org> wrote:

and this is what i replied:

I'd expect user@host to be treated by the mainstream, as an email identifer, at least for the next few years.

[Nathan Rixham]

Melvin Carvalho wrote:
> On 22 June 2012 17:58, Michiel de Jong <mic...@unhosted.org> wrote:
>
>> and this is what i replied:
>>
>
> I'd expect user@host to be treated by the mainstream, as an email
> identifer, at least for the next few years.

random aside; the @ is synonymous with email, and it appears to me
there's scope for a symbol which has the meaning "on"

I'm nathan at/@ webr3.org
I'm webr3 on/* twitter.com

Make sense?

Best,

Nathan

[Michiel de Jong]

On Fri, Jun 22, 2012 at 6:24 PM, Nathan Rixham <nri...@gmail.com> wrote:
> random aside; the @ is synonymous with email, and it appears to me there's
> scope for a symbol which has the meaning "on"
>
>  I'm nathan at/@ webr3.org
>  I'm webr3 on/* twitter.com
>
> Make sense?

yes, interesting point! although this is also a matter of perception.
when i email people, i either reply to an existing thread, or i type
their name in the contact search, and tab-complete. i very rarely type
an @ symbol in the context of email. just like i rarely type in a
phone number when i send an sms or make a call. it's essential that i
am still very aware of the email addresses that are underlying the
routing, but i'm not even sure to what extent a non-technical user is
aware of that (for instance, if you're a power user on some social
platforms, you probably know your user_id by heart; other users
probably don't even know they have one).

the situations where i do type @ signs are ssh (including scp) and,
actually, twitter, but then for writing @mentions,

i guess you're right that most people write @-signs mainly when they
send emails, but that doesn't mean the symbol is taken. Melvin always
says it will be hard to teach developers a new scheme. Your suggestion
would require end-users to learn a new scheme, and i think that would
be just about impossible.

as long as it's easy for end users, i don't care what developers type.
the other day someone told me they thought javascript was hard for a
novice. i didn't understand until they referred to lines like "for(var
i=0; i<x.length; i++) {", and the number of ways you can make typos in
that. the average developer types that line on a daily basis, year in,
year out. I'm sure they can type whatever we need them to type, be it
user*host or user@host or acct:user@host. What matters is if things
are easy for end users.

and I think for end users, if Jan and Martin pull off a convincing job
with the Meute app (which i'm confident they will), then end users
will not have to type very many @ signs into apps, nor into address
bars. Just once, when they first power on their Boot2Gecko devices and
connect them to their remoteStorage. :)


cheers,
Michiel