rel=me and rel=contact go a long long way
Chris Messina made a great point about simplifying XFN usage. rel=me by itself has a lot of untapped potential. Using a single URL as the entry point to a cluster of URLs that describe me, a detailed profile can be built from a diverse set of profile pages/services.
Each profile page can list friends, usually of the same service, with rel=contact. There is a question that comes from these links - is this rel=contact link mutual? i can have on a profile page but it doesn't mean much by itself. When the target of the link is loaded and contains a reciprocal rel=contact link, then it can be verified. The same idea applies for rel=me links.
Which brings up another point - this data has to be spidered or loaded via a background process. That takes time. if i give a website an entry point into my cluster of profile pages, that website cannot visit all those URLs and still respond to my web browser's request in a timely manner.
Using a tool I've been playing with, my home page points to 8 different profile pages. One of which is twitter and has 41 friend URLs. Each friend URL points to their cluster of profile pages. That amount to 239 URLs. Some of which (digg) will timeout or not respond. The user experience needs to handle this - profiles will start quickly with one url and will grow and change as the spider grooms the local copy of this data.
Another option is to query google's social graph api. That's what google is good at - spidering the web and querying its cached data quickly. I am not sold on this idea because as powerful as google's spidering is, it can still take days for an update to be noticed and it creates a dependency on a single web service. This cache is different, the URLs are in the hundreds or thousands, not billions, and need to be very timely. Running a local application with social graph smarts sounds like the right idea.
Each profile page can list friends, usually of the same service, with rel=contact. There is a question that comes from these links - is this rel=contact link mutual? i can have on a profile page but it doesn't mean much by itself. When the target of the link is loaded and contains a reciprocal rel=contact link, then it can be verified. The same idea applies for rel=me links.
Which brings up another point - this data has to be spidered or loaded via a background process. That takes time. if i give a website an entry point into my cluster of profile pages, that website cannot visit all those URLs and still respond to my web browser's request in a timely manner.
Using a tool I've been playing with, my home page points to 8 different profile pages. One of which is twitter and has 41 friend URLs. Each friend URL points to their cluster of profile pages. That amount to 239 URLs. Some of which (digg) will timeout or not respond. The user experience needs to handle this - profiles will start quickly with one url and will grow and change as the spider grooms the local copy of this data.
Another option is to query google's social graph api. That's what google is good at - spidering the web and querying its cached data quickly. I am not sold on this idea because as powerful as google's spidering is, it can still take days for an update to be noticed and it creates a dependency on a single web service. This cache is different, the URLs are in the hundreds or thousands, not billions, and need to be very timely. Running a local application with social graph smarts sounds like the right idea.