The Web is really good at linking documents together, but pretty bad at linking people together. Why? Well, for one, people don't really exist on the Web, so it's kind of tough to link together fuzzy things. They have a "presence" in different places, what I'd call shadows of themselves being projected on multiple planes. I've got a Twitter stream, a Skype account and this blog, but even if you sum all these things up you can't make me. On the other hand, if you know a document's URL, you can get it in its entirety, a perfect duplication that is the bane of copyright protection people the world over.
So we've got a great Web infrastructure that is really really good at linking things together. Is there a way to leverage it to link people together? If that's possible, then actual "real life" relationships can be significantly improved: if a service somehow knows that I'm your friend, it can automatically link the two of us. For example, if GTalk knows that A is a friend of B because A said so on his website, then if A and B have accounts on GTalk they can automatically be linked as buddies on GTalk without any work at all on the part of A or B. And so A and B automatically are able to communicate on yet another channel, where before they were ignorant of it.
There are two main solutions today to solve that people linking problem.
The first is XFN, short for "XHTML Friends Network". It sounds complicated but it's straightforward. It adds a "rel" attribute to any anchor link on a webpage, allowing you to specify your "relationship" to that link. So you can write
<a href="http://jimmy.examples.com/" rel="colleague">Jimmy Example</a>
to say that Jimmy is your colleague. A simple solution that leverages (X)HTML nicely.
The second is FOAF, or "Friend of a Friend". In short, FOAF allows you to describe yourself in an XML format. So you write a description of yourself (your name, homepage, interests, who you know, etc...) and post it somewhere on the Web.
Applications can use XFN and FOAF to crawl the Web looking for relationships, and that's exactly what Google did. And it provides that data as a service, through an API called the Social Graph API.
.tel and Social Graphs
Is .tel of any interest in the social graph space? Absolutely!
As starters, .tel provides the person with an actual presence on the Internet, in a standardized (and therefore automation-friendly) manner. Owning your .tel means that you have a single point of contact for life, a distribution point for all your means of communications. In effect, you're telling an social application "You can always find me here, and here are all the means to contact me." So .tel solves the communications discoverability problem in a big way.
.tel can complement foaf in a couple of ways:
- I can point to one (or many) foaf documents describing me in more detail.
- And I could generate a FOAF document directly from my .tel information (this is currently left as an exercise to the reader)
One of the benefits of having a top level domain (TLD) dedicated to communications is that it solves the problem of actually finding people. It's great for you to create and host a foaf document somewhere, but search engines need to know where it is. foaf makes use of the "rdfs:seeAlso" tag to link a foaf document to another, giving foaf spiders the means to crawl. On the other hand, since .tel is a top level domain, the list of all .tel is made directly available. Of course subdomains need to be discovered and crawled, but that's under the control of the domain owner.
And then you need to be able to tell people "this is really me, not someone posing as me." When you own your .tel, that problem's solved because someone had to buy it. There's a clear paper trail. That's the other benefit of a TLD. On the other hand, with foaf it's much more complicated. You have to create a PGP signature, make sure it's properly hooked into a "web of trust" and that enough people trust that this key is yours, and then sign your FOAF file with that signature. Achieving a web of trust for a PGP key is not for the faint of heart, to say the least.
The other side of the trust coin is being able to trust people with your info, i.e. making your info only visible to your friends. Both foaf and .tel implement privacy through data encryption using the well-tested public key encryption. However, I think that one of the reasons foaf encryption didn't catch on is again that it's exceedingly complicated to implement. First, you need to create a public/private keypair and store it in the public keyservers. Second, you also need your friend to do the same thing. Good luck with that, using current tools. And finally, you need to encrypt some data with your friend's private key and store it in a new foaf file specifically for him.
When you own a .tel, you don't need to know any of that. The procedure is as follows: someone requests to be your friend, you accept, you put that friend in a group (say, "beer buddies"), and if you gave "beer buddies" access to your email, your friend sees it. Done.
Yes, behind the scenes you've got all this public/private key stuff, and yes you can completely control how that works (through the Friending API or even manually), but you don't need to. And more importantly, you shouldn't have to!
Also with a .tel I publish my communication protocols straight in the DNS for effective use by mobile devices. A web-based document such as a foaf one just can't be retrieved, parsed and made ready for use in real time by mobile devices.
This gives me the simplicity, persistence, control and exposure needed to give any personal information (including phone numbers or foaf documents) to whoever I want, whenever I want.
PS: Speaking of friending, this is an area where .tel can make use of the Social Graph APIs: after launch we will look into enabling the .tel Friending Service to talk to the Google Social Graph API, to discover if you have friends who have a .tel or are on the .tel Friending Service. This will make for a more streamlined user experience and will hopefully help grow what Tim Berners-Lee calls the Giant Global Graph.