cobolhacker.com

My pal Dan refers to the current crop of social networks as “walled gardens” because they do not talk to each other. I don’t care as much about the philosophy, but one practical problem with the lack of interroperability is your contact info and address book are not shared between the various sites.

Even a regular user can understand why this might be a problem. When you log on to a new social networking site, you have to add all your buddies to the account. A much better way would be if the social networking site knew about you and your buddies from a third source. That way the data would already be there.

So I couldn’t sleep the other night and I got to thinking about how you would go about implementing a Web 2.0 centralized address book. This is the braindump.

Where is the data stored?
A lot of people use a variety of different computers in their day so storing your buddy list locally is out because it ties you to the same computer and can’t be updated if you are not using that machine. So the list will have to be stored online on an “identity server”. The only real requirement is that the machine be running the correct software and be accessible from anywhere on the Internet. I’m thinking along the same lines as a Jabber server. There could be ones storing thousands of identities or a personal one with just one person’s stuff.

What does it store?
An identity record is indexed by a unique name (like Jabber), “bob@tzu.frankie.ca”, for example. The first part is a name unique in the identity database on the server. The part after the @ is a fully qualified server name. This record could be a real email address, but doesn’t have to be. The fully qualified server name effectively ensures that your “ident-name” is unique on the Internet.

Two password fields are required. The first is a password known only to the owner of the ident-name which allows them to access their record and change it. The second is a password which allows others to view the data and change certain parts of it.

An identity record has two tables. One is a table of metadata, the other is the “address book”. The address book is fairly straight forward: it is simply a list of the ident-name of the other people you know and the ident-name of who put them in there.

The metadata record contains a field with RDF-like data representing predicate and object, an ownership field and a permission field. Unlike an RDF triple, there is no need to denote subject, since the subject is always the ident-name itself. RDF-like data is useful here because it can be extended easily without breaking backwards compatibility. Like HTML tags, predicates unknown to a viewing application can be simply ignored. I haven’t fully thought through syntax, though a simplistic example of one record might be:

<meta>

xmlns:indent=”http://tzu.frankie.ca/ident/tags/1.0″

<ident:Name>Robert J. Young</ident:Name>

</meta>

In this sense the data is a lot like FOAF data. in fact, a lot of this concept is like FOAF.

How Does It Work
The owner of the record can create any metadata record they like. One of the features of the server would be a web interface to allow the owner of a ident record to view and modify their own data. A number of predefined metadata records are available in the standard: Name, Nickname, Address, Email Address, Phone Number, Occupation, Short Description, etc…

If another ident has been given the second password, they have the right to view the entire ident record. They also have the right to add a certain number of metadata records (say five) of any data they want (up to a certain length). They may also change these records as they see fit. The ownership field marks the entry as theirs.

The owner of the ident-name has the ability to:

• change any metadata record
• delete any metadata record
• lock a metadata record so only he can change it

Another ident holder with the password may also view the address book. They also have the ability to add a ident names to the address book, but they cannot remove them.

The owner of the ident-name can delete or add any address book entry they want.

In Operation
You’ve probably already figured out how the system is going to work.

When you log on to, say, Facebook, it will ask you if you have an ident account, and if so, what is the access password. Once Facebook knows this, it can download your address book, as well as your metadata. It also has acccess to metadata added to your ident-record by other social sites. Gmail may have added a gmail address record or Wordpress may have included a blog address record. If they did, Facebook would know these things too and could automatically fill out your profile.

When Facebook gets your address book, all it gets are the ident-names. If the idents are also members of Facebook and have given it their passwords, Facebook would be able to contact their ident servers to get their info as well. If they haven’t joined Facebook, they would remain just an ident-name, until they joined.

When you encounter a new friend on Facebook, you add him to your roster. The networking site then informs your ident server and adds the name. When you log on to, say, Gmail your new friend’s name and email address is already in the Gmail address book.

If you and a friend have a falling out, making him disappear is easy. Erase him from your address book on the server. His ident will disappear from every ident aware service you are on. Disappearing yourself is easy too. Simply turn off your ident server or change your account. Social networking sites are likely to cache the data they get, but they are going to notice that they can’t update what they have. Eventually they may cancel the account.

There may be a part two if I can think of more.