FOAF meets XRI

FOAF uses the mbox field as a primary key. Here's a super-simple FOAF record:

<foaf:name>Fen Labalme</foaf:name>
<foaf:mbox rdf:resource="" />
<foaf:nick >fen</foaf:nick>
<foaf:workplacehomepage rdf:resource="" />
rdf:resource="" />
<foaf:mbox rdf:resource="" />
<foaf:name>Owen Davis</foaf:name>

Note that one thing being done to increase security is to us the SHA1 hash of the email address instead of the actual email address, so that connections can still be made without giving away a person's actual email address. But this is only one level of indirection, as anyone who has a large address book (I have over 1000 mostly technology folk in my Solstice/Equinox list - I'm sure Marc Canter and Joi Ito have many more!) can easily map the SHA1 hashes to actual email addresses.

Other keys can be used by various aggregators and bots, but imagine if instead of putting all this data out publicly, the "mailto:" schema in the mbox field was replaced with "xri:" and pointed to an i-name, access to which was governed by a personal i-broker. This requires ZERO modification to the FOAF protocol while immediately offering the full capabilities of XRI/XDI, DataBrokers and Link Contracts (which, admittedly, doesn't really exist except in theory, yet).

But it's a compelling story!


You can make this happen on

You can make this happen on your own:

Create a property, say somenamespace:i-name, make it an owl:InverseFunctionalProperty, and get people using it. You now have a key that's usable by everyone - without modification to exisiting usage.

The suggestion of another

The suggestion of another namespace with its own vocabulary sounds good, but I see two problems with it: 1) "get people using it", and 2) privacy issues and progressive disclosure are not addressed.

As of now, the FOAF community is already using the foaf:mbox property as sort of a primary key, so there's less of a problem with getting people to use it. Privacy and progressive disclosure would be handled by one's i-broker.

Certainly I can see that there may well be a need for an xri: or xdi: namespace in the future, and in fact we're building those now. It might just be that at some point down the road, rather than having XRI/XDI embedded inside of FOAF, it could be the other way around. But that future is a ways away.