Ever since I started working on the "open social web", I’ve wanted to co-author some kind of crisp and clean manifesto or "bill of rights" to explain to all the social sites what their users will increasingly ask of them, and what specifically these sites can do to "be open". While there's plenty of room for discussion about various implementation details, it's become increasingly clear to me that if sites just do a few things right for their users in terms of openness--both technically and by having the right spirit--the rest can be layered and tweaked and otherwise made to "just work" for users.

Last week, I met with Marc Canter, and we found that our notions for how the open social web should come about were very much aligned. Over the course of several hours, we developed a lengthy, bulleted list of thoughts, philosophies, and pragmatic approaches. As we reviewed that outline, a set of core ideas stood out to us, which we could succinctly frame as a "Bill of Rights for Users of the Social Web." In the following days, we circulated a draft with a number of thought leaders in the community, and were pleased to have Robert Scoble and Michael Arrington offer their support and sign-on as co-authors of the document.

That Bill of Rights has now just been published at http://OpenSocialWeb.org. The document lays out the basic rights that users should demand from any social site they use, with respect to ownership, control, and freedom of movement of their personal information. It also describes four things that sites need to do if they want to be truly supportive of those fundamental rights.

I realize that not every company that operates a socially-enabled web app will readily agree with the ideas put forth in this Bill of Rights. Handing over ownership and control to the users might even seem crazy to some. But from our own experience at Plaxo, as the custodian of millions of our users's personal address books, such user-centric policies are good for business as well as good for users. For years, Plaxo's privacy policy has included these core principles:

• Your Information is your own and you decide who will have access to it.
• You maintain ownership rights to Your Information, even if there is a business transition or policy change.
• You may add, delete, or modify Your Information at any time.

And to be clear, "open" doesn't necessarily mean "public". Plaxo users generally consider their address book data to be extremely private, but they still want the ability to get it in and out of the trusted tools and sites they use (such as Outlook, Mac address book, Yahoo!, etc.). And "open" also doesn't mean "less control over who can see what"--each site will decide what user experience works best for their users. What matters is that whatever data your users can see, they should also be able to syndicate and use with other services they trust.

We think it’s time for socially-enabled web sites to stop competing over who can build a higher wall to trap their users' data. Instead, we are actively working to make sure that the "social web" is as open and vibrant as the Internet itself. We also firmly believe that the space of social apps is not a zero-sum game--as it becomes easier to find out what other sites your friends are using and to consume that content in novel ways, everyone will end up with more traffic and more satisfied users. We've already seen a bit of this with Plaxo Pulse users discovering and using new social sites by seeing what else the people they know are creating online, but the impact will be far larger when it's distributed across the entire web.

Lastly, this Bill of Rights is part of a larger conversation that has been going on for some time and with many important voices. It echoes earlier work like DigitalConsumer.org's Bill of Rights, follows earlier work in open data portability within the FOAF and microformats communities, and more recently, builds upon the conversations I've had with people like Brad Fitzpatrick, Tantek Çelik, Chris Messina, Dick Hardt, and others about practical ways to bootstrap the solution we all want. I hope the conversation continues to grow, and I hope this helps both sites and their users clarify how they want the social web to work, so that they can collectively make it so.

Continuing Plaxo's interest in the Friend-of-a-Friend Project (FOAF), one of our senior engineers (Joseph Smarr) will be attending the upcoming FOAF Workshop in Galway, Ireland. Joseph will present Plaxo's experiences with trying to integrate FOAF in a talk entitled "Technical and Privacy Challenges for Integrating FOAF into Existing Applications" and sit on a panel entitled "I want my data back" along with Marc Canter, Julian Bond, and others. We're looking forward to meeting the rest of the FOAF community face-to-face and discussing how FOAF can be scaled up to the point that large services like Plaxo can take advantage of it while giving their members sufficient flexibility and protecting their privacy.

See the full FOAF Workshop programme at http://www.w3.org/2001/sw/Europe/events/foaf-galway/programme.html. If you're going to be there, or you have any questions or comments you'd like to relay, feel free to contact Joseph at joseph-foaf@plaxo.com.

At Plaxo, we've been interested in the Friend-of-a-Friend Project (FOAF) and its potential applications for some time. There are potential synergies for Plaxo and FOAF both on the "input side" (e.g. you reply to update requests and/or pre-fill your registration by supplying your FOAF file) and on the output side (e.g. Plaxo can generate a FOAF file for each user that always stays up-to-date). We've built internal tools that do both of these things (in fact we quietly released limited FOAF output for Plaxo members a while ago), but we've run up against a few lingering technical and privacy-related issues that have kept us from releasing most of this work to the public. Given the recent fervor over Tribe's interest in supporting FOAF, we thought it was time to ask for your advice on how Plaxo can best work with FOAF.

Technical issues:

The primary technical issue with FOAF is that Plaxo supports more contact fields than FOAF does. We basically support all the fields that Microsoft Outlook does, which is roughly equivalent to what vCards support (note btw that we've had a feature for some time that lets Plaxo members create a link to a vCard with their contact information that always stays up-to-date). Our current FOAF tools fill out fields like mbox, phone, and workplaceHomepage, but we'd like to be able to read and write a user's full set of contact fields in FOAF. What's the right way to do this? Surely every social networking site has the same problem in one form or another (fields not supported by FOAF). There's a W3C Submission on representing vCards in RDF (and the RDF could be included in a FOAF file) but that seems to have languished and it's not clear how widely supported it is. Are there alternative schemes that people currently use to augment a FOAF file with additional contact information? Any suggestions on how we can import and export rich contact information with FOAF?

A further limitation of using FOAF files is that they're one-size-fits-all, i.e. you generally have a single FOAF file for everyone to view. In contrast, Plaxo members can set up detailed permissions about which users can see what of their info. So there's no single FOAF view that's appropriate for everyone. In our current auto-generated vCard/FOAF page, we let the user decide whether they want to share their business card, personal card, or both cards, and then everyone sees that. We could do something similar with FOAF but then each user could potentially have 3 FOAF URLs to pass around, and we don't want private FOAF files getting to unauthorized users. Any suggestions on if/how we can incorporate permissions and restricted viewing into a FOAF framework?

A separate technical/UI issue is that while we can always point to a Plaxo-generated FOAF file for a user, many users maintain their own FOAF files and might want to use them instead of their Plaxo version. For Plaxo members, we could let them type in an alternate FOAF URL, but non-members would presumably want this ability too (providing their FOAF file as part of a response to a Plaxo update request and/or as an auto-reply mechanism, e.g. "when a Plaxo member asks for my contact info, just give them what's in my FOAF file"). The problem is that most people don't use or even know about FOAF (yet) and we're wary of cluttering or confusing our interface with a feature that would (at least initially) only be appealing to a small number of users. The alternative is to obscure this feature (to avoid confusing people that don't need it) but then we're not really getting through to the people that it would benefit. Any suggestions on how we can let members and non-members tell Plaxo to use their own FOAF file without cluttering our interface and confusing non-FOAFers?

Privacy issues:

The bigger issue impeding Plaxo's public support of FOAF (and presumably the main issue that similar services are also mulling) is privacy: FOAF files make all information public and accessible by all, including the contents of the user's address book (via foaf:knows). At Plaxo we're extremely careful never to share any personal contact information without the user's consent, and we never share the contents of their address book (which differentiates us from most other social networking sites). But clearly this information is a key ingredient in making Plaxo-generated FOAF files useful: you shouldn't have to maintain separate friends lists on every site and also maintain your address book with Plaxo. So what should we do? We could of course allow users to opt-in to publicly sharing their address books (which could then be included in their Plaxo-generated FOAF file). But even this would be a privacy-compromising operation because the contacts in a user's address book might not want their information to be made public, and right now they don't really have any control over that. Plus it's like the FOAF features mentioned above--it will only impact a small number of users, but it potentially complicates and confuses the experience for everyone else, and in this case, risks running counter to our strict privacy practices, which are among our deepest core values. On the other hand, supporting FOAF without doing any linking seems half-baked at best. Any suggestions on if/how we can allow users to share their list of contacts without compromising privacy?

A FOAF-specific but related privacy issue is whether to show plain-text e-mail addresses in FOAF files or only SHA1 sums. Currently Plaxo users link to one another via e-mail addresses on their cards, so in a way we already leak the plain-text addresses in approved situations, and our permission system makes sure that no one sees any contact info they're not authorized to see (including e-mail addresses). On the other hand, many FOAF users seem to prefer to only display their SHA1 sum so that they can be identified but not spammed, and we want to accommodate those users. Plus, as mentioned above, FOAF data is generally more public and widely available than data inside the Plaxo network. Other than adding yet another obscure-and-potentially-confusing-preference about "show plain-text e-mails in FOAF files", any suggestions on how to handle plain-text emails vs. SHA1 sums in Plaxo-generated FOAF files?

Summary of Open Issues:

• Importing and exporting rich contact information with FOAF
• Incorporating permissions and restricted viewing into a FOAF framework
• Offering FOAF features without confusing people that don't use FOAF
• Sharing your contact list without compromising the privacy of you or your contacts
• Using plain text e-mail addresses vs. SHA1 sums (which is better where)

Conclusion:

There's been a lot of discussion lately on blogs and elsewhere about how social networking services should support FOAF. We totally agree that there's a great opportunity here to let users participate in multiple services without having to duplicate data and also to let developers build external services that can take advantage of the data gathered by these networks. But before we can fulfill these dreams we need to address some technical issues and, more importantly, figure out how to respect privacy in the process. We hope that some of you will have good suggestions on these complex issues, and you can be assured that as soon as we've found good solutions, Plaxo will be very FOAF-friendly!