Distributed Membership and Preferences
Tuesday, July 17, 2001 by Dave Winer.
Background 
Membership and preferences standards are a hot topic among independent developers, because of Microsoft's Passport, which is in rapid deployment.
So developers are now faced with a choice -- support Microsoft's membership system, and thereby feed customers to them, or develop a unified, open, clonable and decentralized system, so that membership is a competitive space, not owned by one or two large companies.
Privacy vs publishing
The core issue is privacy. How do you control the information you provide about yourself? Are you transmitting data over secure lines to people you trust? In a chain where the weakest link determines how private your information is, can there be any realistic guarantee of privacy?
In 2001, the best advice, as a computing professional, that I can offer is: 1. Assume your data are not private. 2. If you want to maintain privacy, don't put the data on a computer network and 3. All membership systems must offer each user an easy way to copy all the content being stored in a cloud for backup or to allow relocation.
Once you make a decision about privacy vs publishing, the design falls out. Of course I have to go with publishing because it's realistic. The Internet is a fantastic publishing environment. On the other side, I don't think you can build a membership system in 2001 and make any guarantees of privacy. So once privacy is disclaimed, the problem is simply stated.
Membership and preferences at UserLand
UserLand has a mostly decentralized membership system. Every Manila site we host, and ones that are hosted by our licensees, has its own membership. We also have a special thing with userland.com, its membership info percolates across a group of machines that host userland.com sites. The synchronization is done in XML-RPC, it could easily be done in SOAP.
The frustration of decentralized systems, as expressed by many users of our software, is that it's cumbersome to enter your information manually for every site you want to join. Isn't there some way to automate this? Of course there is, but then we get into the issue of privacy, and that's guaranteed to be a controversial issue.
How decentralized membership should work
When I sign up to a new site, call this the dependent site, I wish there were a You Know Me button I could click that would link membership in this site to some other site I am already a member of.
A dialog appears, I enter a string that identifies both a server and my member name, call this server the legacy site. A message is sent from the dependent site to the legacy site asking for the URL of a static XML document that contains my membership information, call it member.xml. At the same time the legacy site adds a subscription to the XML document so that the dependent site can receive notification when I change it. member.xml is a public resource, its URL is discoverable. It contains all the information I wish to make public, however it does not include my password.
UserLand has specified an XML-RPC and SOAP 1.1 interface for such a system, it's the basis for the upstreaming feature in Radio UserLand. This is how we want to migrate, from a centralized system where we host sites, to one where more of the work is done by users' personal computers, where the centralized functionality makes information publicly available for users behind firewalls, NAT or low-bandwidth connections.
http://www.soapware.org/xmlStorageSystem
Four criteria
The four criteria are: unified, open, clonable and decentralized. The last three are inevitable and relatively easy. The first one, unification, is the hardest and least likely. But when things work on the Internet it's because unification was achieved.
Look at the protocols and formats we use now, and think about how they were unified. Often as a result of competition. Sometimes because someone had a good idea and no one cared until a format or protocol had already gained traction. With membership and preferences there are a lot of ways to go, a lot of competing ways to do basically the same thing. The question is, will we be able to settle on a common interface or will Microsoft end up having exclusive control over the protocol. I don't see any other fork in the road.
The key phrase is common interface. We can hide all the differences behind an XML-RPC and SOAP interface to invoke membership and preferences services. Imho, that's the key to unification.
It's pretty simple
Hopefully this frames the question and helps form a basis for discussion. We're looking for all software that can fill this need, not just our own, in the hope that we can have a common XML-RPC and SOAP-based interface for all such services. We're conversing with the XNS people, and think that Jabber can help. I've also been emailing with people at AOL about their work in this area. Now I hope to open a discussion with everyone who has an interest in this functionality so there's a chance of a unified and inclusive approach.
If you feel that I've missed a critical element of membership and preferences, please speak up as soon as possible. I'm happy to change this requirements doc, and am posting it publicly in order to get pushback from all corners.
Dave Winer
PS: I've been invited to the Open Source Summit next week in San Diego. I hope this document will form a basis for discussion there as well as on the Web.