Hi, I'm the lead at Plaxo working on FOAF. I can see that Paul has voiced some similar technical and privacy problems, and I am excited to work together with you on trying to solve them. I've also gotten some useful feedback from Julian Bond at ecademy/voidstar so it sounds like word is spreading fast and the people working on FOAF and social networks are quickly coming together!

Let me start by sharing our point-of-view on Paul's "top 5" issues:

(1) Agreed, big deal for us too, especially since at Plaxo no-one has a truly "public" profile--even your so-called "public" information is only available to people that already have your e-mail address in their address book. It looks like at ecademy what they do is only show the name of your contacts with their SHA1 sum and a link to their ecademy FOAF file. This seems like a pretty good balance to me, because you're not really leaking any information about your contacts (other than their name and the fact that you two have a relationship) and yet this is sufficient to link up a social net.

(2) Hmm, not sure what to say about this. Plaxo can already protect e-mails in a communication because the sender could request an update from a friend-of-friend (hypothetically) without knowing his/her e-mail, and if the recipient doesn't want to respond, the sender will never get the recipient's email. We don't really broker communication through intermediaries like LinkedIn etc though I guess in theory we could.

(3) Plaxo's solution is that each member can associate multiple e-mail addresses with their account, so it doesn't matter which e-mail you join with as long as the other e-mails are on your plaxo cards. We also have an "old email" feature where you can register e-mail addresses you no longer use (these don't have to be validated) and someone with your old address will get a notification to re-connect with you (permission required on both sides).

(4) I assume this means you import someone's FOAF before they join and then later they want to join, so what's the procedure? At Plaxo all accounts are tied to e-mail addresses that the user has to validate with a round-trip so I guess if we had pre-harvested their FOAF we could just say "we already have this info for you, would you like to use it" after they validate. Of course I'm not sure we would go around pre-creating users via FOAF in the first place, because that sort of artificially grows the network without having real people maintaining their info, but I guess it's an interesting idea to consider.

(5) I guess it depends on where you're getting data from. If you pull info from a FOAF file and then that FOAF file updates and no user has touched the old data, you go with the new FOAF file. If the user manually edits their data and then their FOAF file also changes, maybe you ask for a merge or go with what the user did. That's why we want real users behind all the Plaxo accounts: so each person manages his/her own cards to make sure that everyone else gets the right data.

What applications/services do you intend to do with FOAF at tribe? Sounds like export your tribe profile as FOAF, join using a FOAF file, and is that it? Are their particular third-party uses of the FOAF data that you're excited about populating with tribe data? Are you hoping to auto-join people that have FOAF files to tribe? I think ultimately the design tradeoffs we make should be motivated by what user experiences they enable, but one of the problems at Plaxo is we're not sure exactly what to do with FOAF input/output other than create FOAF files for their own sake. Any ideas?

Thanks, js