Kitmee: My Big Project

I’ve alluded to a major project a few times in recent months. Well, I’m now ready to talk about what it is. I apologize for the disjoined presentation; I’m a bit excited and will clean up as needed later.

Background

One of the most annoying problems that faces computer users is contact management. Most don’t have a truly organized digital address book, and even those that do suffer from contact-rot. This is where each passing day means one more mailing address has changed, someone got a new mobile number, and another person got married and has a new last name. In other words, time deteriorates the quality of your information about other people.

Many services have come and gone that tried (or are trying) to solve this problem. Most notable of these is Plaxo. Plaxo, as well as most of the other services like it, have essentially been services where you kept your updated information. The idea being that when you changed your info, Plaxo could notify the people in your address book that you had done so. At that point they could take some steps to update their information. The problem is that it’s required too much involvement with the third party service. Plaxo is, after all, a for-profit company, so it makes sense that they would want you to interact with them.

Identity Management + Semantic Web

My idea is simple: provide a free and open infrastructure upon which people can build identity-based services ranging from contact management to social interaction functionality. Focus on transparency and open standards, meaning that the exchange of informaton should be as simple as possible and should allow for infinite potential for securely sharing and manipulating the data.

Here are the two primary components:

1. Central, Server-Side Representation of People using XML I’m currently working on RDF for the main definition.
2. Open, RSS-based Client The client piece, while completely open to various implementations, will have two components. 1) Subscriptions to contacts via RSS, and 2) translation of the server’s XML to their own address book format.

Functionality

• Maintain constantly updated contact information by subscribing to your friends’ information on a central server. You stay updated because your information is not static. The information you see when you open your address book is what was last pulled from your contact’s RSS feed.
• Your contact list is constantly maintained in a neatly defined, XML-based format on the server (OPML?). To get your contacts onto any new system (including mobile devices), install any client (there will be many) that speaks both the server-side XML protocol and the local address book format.
• Link the elements within a given definition to other namespaces that carry weight within the semantic world. In other words, allow favorite bands, favorite foods, and a multitude of other attributes to be defined in such a way that associated information can be referenced (and mashed) semantically.

The Architecture

The server resides at kitmee.com (currently living in a VMware machine in San Fransisco that’s powered off) and hosts the various identity files (RDF, etc.). As an example, we’ll say we have two accounts — myself (Daniel Miessler), and my friend (Seth Kline).

We respectively live at kitmee.com/dmiessler and kitmee.com/skline. Within whatever client we’re using for the system (again, this will be any one of many available) I’ll subscribe to Seth’s address within my client that’s installed on my local system. The client works by maintaining two types of information: who you are, and who your subscriptions are (your contacts).

More On Client Functionality

The most basic client monitors the local address book for changes to my own contact information, and upon sensing changes translates the changed result into the server’s XML format and uploads it. This updates my information on the server and updates the associated RSS feed that represents me as a person.

Since people who have me in their “contact list” are actually just subscribed to my RSS feed, their respective clients (web clients, desktop clients, mobile clients) will be notified the next time they check in that I have updated my information. Their client will then update my information in their contact list (server-side) and make the associated change to the local address book on the system they are using (mobile phone, work computer, etc.).

So what we end up with is an infrastructure in which I can update my information using my own local address book, and that information will transparently be propogated (via RSS pull) to anyone who is subscribed to me using the system.

Once I have a client installed it disappears into the background. From that point on I interact only with my regular contact management application, and changes I make are propogated to my subscribers, and their changes are propogated to me.

The end result is that when I open my address book entry for Seth two years from now and dial his mobile number, I could very well be dialing a number that I never entered. He’ll still answer the phone on the other end, however, because at some point he updated HIS local address book, which updated the server, which updated MY local address book.

No extra steps. No extra hassle.

Considerations

Security is handled on the server by managing who can and cannot access your information. Obviously we don’t want just anyone to be able to pull your entire personal definition (essentially what’s now a vcard) by simply visiting a given URI. I also intend for the various elements/fields in the definition to be granularly controllable, e.g. work associates can see only your home number, while friends can see everything, etc.

Clients are the key; without them we don’t have the transparency that’s required to make the infrastructure useful. Specifically, we need the client to be able to translate between the server’s XML format and the local address book format. In later client iterations, however, I anticipate moving towards address book integration, i.e. being able to add kitmee subscriptions right into the native address book.

Final Thoughts

So that’s the project. I’m currently working with one other developer on the server side, and have not even started considering the client piece. Our development environment currently consists of a fairly stout Gentoo Linux server running in VMware. The application platform is RoR, and we’re using Subversion for version control.

I am very much interested in any feedback you may have. And if you’re interested in contributing — either via conceptual input or actual development effort — I’d love to hear from you. I will be following the comments in this thread and am also available via email.