Linux, politics, and other interesting things
When advogato.org was still cool I signed up to it. It was an interesting research project in skill metrics (determining the rating of people’s coding skills by the votes of others and weighting the votes by the rating of each person), and it was nice to be rated Master soon after I joined. I still use it on occasion for the blog syndication feature (when I find a good blog on Advogato I add it to my Planet installation).
When orkut.com was really cool (when every time I had dinner with a group of people someone would ask if they could be an “orkut friend”) I signed up to it. It was interesting for a while but then most people got bored with it.
Now there is Facebook and MySpace for social networking for social purposes and LinkedIn.com for business related social networking. I periodically get invited to join those services but have not been interested in any other than LinkedIn. I can’t join LinkedIn because their mail server is regarded as a SPAM source by my mail server but their web server refuses to provide any information on why this is (the rejection was apparently long enough ago that it’s rolled off my logs).
The problem with all these services is that I am expected to sign up with each of them and go to a moderate amount of effort in writing up all the data in the various web pages. Writing it is a pain, keeping it up to date is more pain, and dealing with spam in “scrap-book” entries in Orkut is still an annoyance which I don’t want to multiply by four!
So far the only step I’ve seen towards addressing this issue is the XFN – XHTML Friends Network  project. But that seems to be of fairly limited scope (just referring to the friendship status of people in a <a href link).
I believe that the requirements for social networking are:
I think that the only way to go is to have a standard XML format for storing all personal data (including financial, career, and CV data) that can be used on any web site. Then someone who wants to be involved in social networking could create an XML file for a static web server (or multiple files with different content and password protected access), or they could have a server-side script generate an XML file on the fly with a set of data that is appropriate for the reader. The resulting social network would be entirely distributed and anyone could write software to join in. This covers item 1 and part of item 2.
For sending email to friends of friends it would be good to avoid spam as much as possible. One way of doing would be requesting that friends publish a forwarding address on their own mail server in a manner similar to SRS . SRS include the ability for such addresses to expire after a certain period of time (which would be convenient for this). In fact publishing SRS versions of friends email addresses would be a good option if you already use SPF  and SRS in your mail server. This covers item 3.
The XML format could include information on how far the recipient could transfer it. For example if my server sent an XML file to a recruiting agency with my CV it could state that they could distribute it without restriction (so that they can give it to hiring managers) with the possibility of some fields being restricted (EG not tell the hiring manager what I used to get paid). For my mobile phone number I could send it to my friends with a request that they not send it on. This covers part of item 2.
The URL for the friends file would of course be in the main XML file, and therefore you could have different friends lists published from different versions of your profile (EG the profile you send to recruiting agencies wouldn’t include drinking buddies etc). This completes the coverage of item 2.
Then to have a friends list you have a single XML file on a web server that has the public parts of the XML files from all your friends. This means that getting a list of friends of friends would involve getting a single XML file for each friend (if you have 100 friends and each friend has 50 unique friends on average then you do 100 HTTP operations instead of 5,000). Minimising the number of web transfer operations is essential for performance and for reliability in the face of unreliable web servers (there is no chance of having 5,000 random web servers for individuals all up and accessible at the same time). This covers item 4.
Item 5 is merely a nice thing to have which allows more easily replacing some of the recruiting infrastructure. As any such XML format will have several sections for arbitrary plain text (or maybe HTML) for describing various things the CV could of course be in HTML, but it would be good to have the data in XML.
I posted this in the “blog” category because blogs are the only commonly used systems where end users do anything related to XML files (the RSS and ATOM feeds are XML). A blog server could easily be extended to do these social networking systems.
As with a blog users could run their own social networking server (publishing their XML files) or they could use a service that is similar in concept to blogger which does it all for them (for the less technical users). Then an analogy to Planet, Technorati, etc in the blog space would be public aggregation services that compare people based on the number of friends they have etc, and attempts to map paths between people based on friends.
This could also include GPG  data such that signing someone’s GPG key would cause your server to automatically list them in some friend category. The XML format should also have a field for a GPG signature (one option would be to use a GPG sub-key to sign the files and have the sub-key owned by the server).
I don’t have any serious time to spend on implementing this at the moment. But if someone else starts coding such a project then I would certainly help test it, debug it, and contribute towards the XML design.