Hi - I've got a proposal that I'm not sure has been aired before.

I'd like to see the hardwired "xri.net" be removed or, at the least,
"softened" so that we could use xri's of the form
or perhaps
that resolve using a local example.com resolver rather than Neustar.

Basically, resolving either an (OpenID-looking) URL starting with "xri." (the,
er, "bottom" level domain in a URL) or an iname starting with
"$(...anything...)/" considers the URL or the "...anything..." to be a XRI
resolver.  (Note: the '$(...)' construct has been proposed for XRI resolution
3.0 but hasn't been voted on yet.  But code is law. ;-)

This would enable local resolvers which would, of course, need some sort of
name translation should they wish to enter the global community.

I see local resolution as critical not just because it enables free (local)
i-names (which is crucially important to the growth of the XRI community), but
also for a deeper, reputation-based reason, which I will attempt to describe.

Reputation is key to any identity system.  Simple case in point: the addition
of 90 million AOL OpenID users does nothing to make the OpenID "global
community" safer or more worthy in any way.  Trust depends upon reputation,
which is most easily created over time and through experience/participation in
a closed community.  Once you move out of that community, you're a newbie and
you have to start from ground zero again.

Besides single sign-on and simple attribute exchange, the ability to carry
over some "reputation capital" to a new community is desirable.  Exactly what
the "exchange rate" is will be set by the admins of the respective
communities.  For example, the "reputation" carried between dissimilar
communities (e.g. Slashdot.com and Golf.com) may be something like
"years-as-a-member and karma (or positive group participation)".  Similar
communities may carry over much more information ("network wizard" or "golf 

When two communities wish to create a peering relationship, they will need
mechanisms to manage reputation transfer.  At the same time, they can
optionally determine name translation shortcuts, perhaps "@golf/=iname" (which
could be an easier-to-type synonym for either "http://xri.golf.com/=iname"; or

But all this starts with local resolution.  What do you think?


PS: There's some urgency around this in that if there is quick agreement, we
may be able to get it into Drupal 6 core which freezes June 30th, and Drupal
is a key framework for building local community sites.


specs mailing list

Reply via email to