user@domain identity form musings
M. David Peterson
xmlhacker at gmail.com
Fri May 27 11:31:09 PDT 2005
Excellent arguments Martin. I concede. :)
Do you see value in using the OpenID.name <http://OpenID.name>?
If you consider that .name invokes an identification then this domain could
very easily represent a way of labeling and identifying system nodes, and if
a common naming convention were to be agreed upon then it seems the task of
software distribution, bug reporting, feature requests, development status,
etc... could be built out and propogated from the very beginning and as such
develop a system that is easy to become a member of, easy to syncronize with
the latest bits, report bugs to a common tracking system, check code in and
out, exchange coding ideas across the entire system, etc..
using naming conventions such as:
Could lend really well to ensuring that software updates, bug fixes,
security holes, etc... find there way to the right environment in every node
on the system. Forgive me if I am thinking too grandeur here. This is the
exact system I have been designing for the ChannelXML project and what makes
sense for that project might be total overkill for this. Still, its better
to put things out there to allow for proper consideration as the reverse
tends to lend well to digression where as progression is all I can imagine
any of us have ever wanted.
Thanls again for your excellent counterpoints Martin! :)
On 5/27/05, Martin Atkins <mart at degeneration.co.uk> wrote:
> M. David Peterson wrote:
> > Separation of trivial is all a matter of who you are talking to. People
> > understand foo at bar.com to mean an individual email address. Most think
> of a
> > website when they see foo.bar.com <http://foo.bar.com> <
> http://foo.bar.com> or
> > http://foo.bar.comand, as a technical detail to you or me, causes them
> > to wonder why they have
> > to go to that site first and then what they have to do when they get
> > and.... the unsurities and anxietys of the unknown technology are more
> > worth the effort to regex an @ to . if it now means "oh, Ive used my
> > address before to log in to a site... thats easy...
> > all of this means higher adoption rate and I would bet that rate
> > to be quite considerable
> Most users aren't going to know it's a URL. For example, LiveJournal's
> documentation will say "Type username.livejournal.com<http://username.livejournal.com>into the OpenID
> Login box, where 'username' is your LiveJournal username". Users will
> then go ahead and do that, blissfully unaware of what is going on behind
> the scenes.
> What I *would* like is a way to clean up URLs which have slashes in
> them. Some sites aren't going to want the wildcard DNS, perhaps because
> they already have one or more real hostnames in the zone which conflict
> with usernames, so they're going to have identity URLs like
> mysite.com/username <http://mysite.com/username>, which looks quite odd.
> However, adding lots of little URL preprocessing rules isn't the answer.
> If that route is taken, inevitably every consumer will implement them a
> little differently and users will wonder why username at livejournal.com
> works on one site but not on another.
> I think that it looking like an email address would put off a lot of
> people. I certainly don't like giving my email address to arbitrary
> sites, as I never know what they're going to do with it. Sure, I know
> that in this case it's not really an email address, but most users will
> not. Also, as soon as we start playing the "it looks like an email
> address" game, people will wonder why they can't just use their Hotmail
> account instead of their LiveJournal account.
> yadis mailing list
> yadis at lists.danga.com
M. David Peterson <aka:xmlhacker/>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the yadis