Unifying Address Books
At Gnomedex, Marc Canter explained his work on PeopleAggregator, which is a platform to enable interop between social networks.
The problem today is that very few people reply on a computer based address book because no one address book includes all of their contacts. The lesson is that an address book won’t be replied upon until it includes your entire address book, which will require interop between various address books. Social Networks have a similar problem in that their value is limited when they can’t connect to each other.
PeopleAggregator is working on server side interop and focusing on social networks. My team is working on Windows Vista and has been focusing on interop between address books on the user’s OS.
Coincidentally, Marc and I had a long conversation on this topic at PDC 2003 when we were each early in our work.
Marc with PeopleAggregator is taking an aggressive approach to accomplish server side interop with his company by using open standards. Some companies view network effect or controlled content as needed for their business model. It will likely take time and be a challenge to build critical mass on this technology because of these business model concerns. It can easily start with companies that don’t need this control. Companies that start with locking in their content and don’t hit critical mass are likely to change models and see if growth increases when they interop with a wider community.
Marc has the details about PeopleAggregator on http://peopleaggregator.org/. Here are good pointers in this area:
- i-names: An absolute way to identify a person.
- Windows CardSpace: Based on Kim Cameron’s work, his idea is that there is a “metasystem” which utilizes WS-Trust to translate tokens, so that all identity systems can interact with each other. Windows Live IDs will support WS-Trust, WS-Federation, CardSpace and ADFS (active directory federation server).
- Identity Woman has more information about open standards on her blog.
My team at Microsoft is passionate about the narrower issue of unifying address books on the client. Below I’ll go into details for anyone working in this area.
The “WAB” (Windows AddressBook) shows its age in Windows XP and some of the code dates back to 1989. In Windows Vista we replaced it – and it can be used by external software, such as Marc’s PeopleAggregator.
The goals for “Windows Contacts” are:
- Extensible schema: We knew we couldn’t come up with one schema to solve all needs. For that reason, our platform uses layered schema by using XML namespaces. The base namespace comes from vCard properties along with traditional WAB fields. 3rd party apps can add their custom schema by using separate XML namespaces in our APIs.Contacts are no longer stored in a “.wab” file. We now store contacts as separate “.contact” xml files.
- Integration with the Windows Vista explorer UI & search: In order to improve the UI for the address book list, we decided to use the windows explorer. This enables consistent views, search, sorting, and the new preview reading window. My favorite feature is the ability to open the start menu, type a few characters in the start menu’s textbox and it will filter to show contacts, files, and other matching items in the start menu. This is a great way to quickly jump to where you want to go.
- User Picture support & integration with the login user picture: Our address book now has support for user pictures. This feature personalizes working with the address book, especially when contacts come from internet sites. Our address book has the concept of the “me” contact so applications can find the contact that represents the user. In Windows Vista, we will automatically create the “me” contact that starts with the same name as the login name and use the same user picture as the windows sign-in screen.
- Better Synchronization support: An address book will never unify across different stores, devices, and internet sites unless it has strong built-in support to enable synchronization. In order to accomplish this, we have added:
- A unique ID called a ContactID that tracks a contact within the local computer. This is our database’s Primary Key that external applications can store as a foreign key. It will resolve to the contact even as the contact file is moved or renamed.
- The vCard UID field exists for an unique ID across computers. The RFC for vCards doesn’t define the behavior for this property as exactly as I would like and our platform doesn’t impose any behavior beyond the RFC. I’m thinking that an i-name system may be a better way to canonically identify users across systems, with UID being a fallback when i-name information is not provided.
- Version numbers / Time-Date Stamps: These are tracked on a per property basis for per property granularity sync. The schema supports a list of properties, where lists are phone numbers, web sites, mailing addresses, e-mail addresses, etc. Unique IDs are stored on items in lists to support all sync situations (re-ordering, etc.).
- App compat with the existing WAB APIs: Existing applications that call the existing WAB APIs will route into the new contact store.
- Support External Features: Often a product will need to interact with security or identity. The address book is a user level address book and don’t include these features for security reasons. External components can be created to implement this support, and later link into the address book by using the ContactID to find user level properties after security has been completed.