user@domain URNs, independent from OpenID spec

[Mario Salzer]

meepbear * wrote:
> In the context of leaving comments, people would still want to continue 
> using whatever method their using now which most likely includes listing 
> an email address:
> 
> "PersonA (personA at domainA.com) wrote:"
> and
> "PersonB (personB at domainB.com) wrote:"
> 
> One is an OpenID, the other is an email but there is no way to tell the 
> difference. You can show the OpenID icon next to it, but unless the 
> person reading it happens to know what OpenID is and happens to know 
> that OpenID IDs look the same as an email address they're going to think 
> it's one.

Ok, valid point. If such user at domain identifiers were supported, and
displayed as is (the intention behind that idea), then yes, confusion
MAY arise.
I'm however not sure if this applies in the context OpenID was meant
to be used. The reasoning to build an OpenID system in the first place
was to verify identities, and it seems unilkey that a comment system
would allow anonymous and just-enter-whatever-email-address-you-like
posts, yet introduces OpenID verification. And those that did, probably
took care of such issues themselves.

Displaying the verified user information is an entire different topic.
For example the Net::OpenID::VerifiedConsumers` display logic transforms
LJ addresses into strings like "bob [livejournal.com]". It is not all
too farfetched to assume, that a later version or another web site
switches to @-syntax for displaying completely. So why not use the
most intuitive syntax right from the start?

> I also don't really see how you could easily differentiate between the 
> following using an email address format:
> 
> http://www.example.com/foo/bar/
> http://www.example.com/foo.bar/
> http://www.example.com/foo.bar
> http://foo.bar.example.com/

It cannot.

The simplification introduced with the user at domain syntax means also
a smaller namespace. You can only map it to one of the above URLs,
there is no way to have multiple of them or map it back (other from
the standarized/primary URL/path scheme). The idea was to introduce
an easier to use "abbreviation" for whatever user id or profile URLs
a web site uses.

> ...
> 
> hostee at domain.com won't work because hostee.domain.com and domain.com 
> are totally different, unrelated sites owned by different people.
> @hostee.domain.com might work, but what would you put in front of it 
> when someone wants to use the root path?

Hostee could use //hostee.livejournal.com/ then, like before? The
@-syntax is just an alternative to map simpler account names to full
URLs. If you don't need a multi-account web site, or your provider
gives you a DNS name instead or you are happy with URLs already,
then just use them. Any @-syntax was an optional thing.

To close with a comparison to email again - if everybody had his own
DNS name (e.g. meepbear.hotmail.com) - there would have never been the
need for introducing the @ syntax. The point here is, that it is far
cheaper to use per-domain accounts (just an alphanumeric string, no
paths) instead of giving out one subdomain per user. And this is true
for many many web sites, LJ is one of the exceptions from the rule.


I'm still the opinion that the general user-friendliness of a non-URL
syntax far outweights the eventual confusion of just a few people.