What features do you have?
What services and softwares are you compatible with?

I've been thinking about buying a attaching a Google business account to my current gmail address, but I am reluctant to do so because their contact manager sucks balls. Zimbra seems like a reasonable approach since it would work in both windows and linux...but I really like outlook because it synergies so well with OneNote/Evernote.

Of secondary importance, I want relevant dates to appear in my Calendar:
Birthdays, Anniversaries, etc.
Also I want their address card to have a clickable urls if contacts have listed websites.

Of limited importance, I want to be able to access:
Each individual contacts social media connection info
their twitter handle,
their facebook page address,
their G+ address,
their diaspora address

I want my various devices to be able to access salient info:
eMail clients access and list with context the email addresses
phone dialer / sms access and list with context phone number
SMS filter out non-mobile numbers

I want to be able to read whatever notes I've written about individual contacts from any device.

My budget would be $5 per month per account. 1 account. Alternatively, I have no compunction against hosting it myself. I have (or will have) the equipment to do so...just not the knowhow (though there is a certain appeal to doing it simply to learn how).

I once created an LDAP database with this idea in mind, but found it was not easy to make everything use it. Some applications could only import from it, as opposed to interacting with it as a live "address book". This may still be the best solution, though.

Connectivity with Google Address Book is not quite there yet either.

I think it all depends on what you need to integrate it into. An online sql database might be best.

At least under Linux, if you wanted to implement a universal address book, best way to do it would be via a d-bus service (Actually, newer version of glib now include their own session bus daemon on systems where d-bus is not native, like Windows). The d-bus service can then worry about whatever backends needed - whether it be SQL, noSQL, LDAP, Webdav - or any combination thereof).

Yeah, or you could have somebody with a deck of 3x5 cards read them to you over a string with a paper cup on each end, and they could just update their 3x5 cards from whatever back-end you want (SQL, LDAP, whatever).

I once created an LDAP database with this idea in mind, but found it was not easy to make everything use it. Some applications could only import from it, as opposed to interacting with it as a live "address book". This may still be the best solution, though.

Connectivity with Google Address Book is not quite there yet either.

I think it all depends on what you need to integrate it into. An online sql database might be best.

So I did a quick couple of Google searches on LDAP and turned this up. Thought you might appreciate it since you are now the resident EMACS guy.

LDAP sounds like the winner. I'll probably fix up my Google so it is more cohesive until I can get the LDAP set up. Thanks for the heads up on it. It seems like a much more extensible solution than a Google Business Account.

LDAP is pretty cool. It's one of the principal technologies that Active Directory is based on, as well as Red Hat Directory Server (which you might want to look into, maybe it's available on Centos). I'm not sure about the equivalent Suse product.

I wanted to make my own from scratch, and I did manage to get my email client working with it on my local machine, but I never pushed it off to a separate server. I remember enjoying the fact that one of the utilities for working with it was called 'slapcat'.

LDAP is pretty cool. It's one of the principal technologies that Active Directory is based on, as well as Red Hat Directory Server (which you might want to look into, maybe it's available on Centos). I'm not sure about the equivalent Suse product.

If you just want to do a phone book, I think I'd approach if from a bare-bones LDAP perspective. Once you understand how LDAP actually works, it's probably easier to use something like the Apache product, although I think several of these bundled products include stuff you don't necessarily want (e.g., Kerberos), and are intended for much more than contact management.

Another avenue of investigation would be to look into open source CRM applications. I think most of them are web-based, but I imagine some might provide interfaces useful to products typically integrating an external contact databse.

If you just want to do a phone book, I think I'd approach if from a bare-bones LDAP perspective. Once you understand how LDAP actually works, it's probably easier to use something like the Apache product, although I think several of these bundled products include stuff you don't necessarily want (e.g., Kerberos), and are intended for much more than contact management.

Another avenue of investigation would be to look into open source CRM applications. I think most of them are web-based, but I imagine some might provide interfaces useful to products typically integrating an external contact databse.

Step one. Organize my current address book. /Mostly done.

Step two. Learn LDAP and setup a framework that can hold all of the information I need. /Started.

Step three. Convert csv file of addresses from my current address book into the LDAP format.

Step four. Serve it to Outlook over network.

Step five. Serve it to android over intarwebz.

Step six. Automated update.

Kerberos is something I'll look into. I'd like to make at least some attempt at security when dealing with everyone's personal information.

Would it be hard to, say, have a 'crawler' type program that goes through whatever contacts I have in whatever social media and updates each individual's contact information with whatever they put up for me to access? e.g. phone numbers, email, birthday, relationship status and significant other (with link to significant other's contact info, if I happen to have that in my contacts already?) Could this be done easily with say a python script or something?_________________"History began on July 4,1776. Everything before that was a mistake." -Ron Swanson

I once created an LDAP database with this idea in mind, but found it was not easy to make everything use it. Some applications could only import from it, as opposed to interacting with it as a live "address book". This may still be the best solution, though.

...I think it all depends on what you need to integrate it into. An online sql database might be best.

So I did a quick couple of Google searches on LDAP and turned this up. Thought you might appreciate it since you are now the resident EMACS guy.

What I mean is Step 2 is anticipated to be the only hard step because to do it I have to learn about a completely new type of software. I don't have a whole lot of experience with databases. On the plus side, there is a tremendous amount of resources about the topic LDAP and using it as an address book and some seem to be geared toward us less tech savvy bio majors.

Step 3 may be an exercise in brute forcing my address book into LDAP by entering all the info manually if I can't figure out how to convert it. I'd prefer to find a more elegant way to import it from my Google address book. Even with the brute force method, it will take less than a day, my address book isn't particularly huge.

Steps 4 and 5 seem to have pre-made tools built into the software that I intend to serve with the LDAP DB that automate the process.

Barring any disasters (e.g. procurement failures, equipment breakdown, etc.) I anticipate that this project should be done by mid February.

Step 6 will be a doozy. I think this is the step that stops me. Not 2 or 3._________________"History began on July 4,1776. Everything before that was a mistake." -Ron Swanson

Steps 4 and 5 seem to have pre-made tools built into the software that I intend to serve with the LDAP DB that automate the process.

Cool. This seems like it would be the hard part to using LDAP as a solution.

It's been a long time, but this is what I recall being a bit irritating. It uses a strange, markup-like data format wherein field names are included in the actual data. It's also tedious interacting the with the database using only the rudimentary tools. It's kind of odd and cluster-fuckish at first in the same way SSL CA tasks are. Interactive software designed for submitting and editing entries, running queries, etc., seemed barely nascent and buggy at the time I briefly used them. I would still recommend initially gaining familiarity with the underlying tools.

My experience with LDAP is pretty much the same, and not that long ago (~4yrs). I've seen it again recently, but only in passing, and it seems not to have improved. For custom solutions, it seems fine. The bigger problem is being able to integrate it into common applications. If I implement the back end and only 1 out of 100 apps support it, then it isn't particularly useful. Unfortunately._________________It takes a little while to get the facts. You still don't know the facts.

LDAP is the most widely-used directory services technology in the world. Most applications designed for individual users (i.e. home users, versus within an organization) do not make use of directory services, though.

LDAP is the most widely-used directory services technology in the world.

But no two implementations are necessarily compatible. For example, getting OpenLDAP & AD to interoperate (this may no longer be accurate). I know AD had some Unix tools, but they required certain versions of Sever and/or SP, and even then, weren't "great."_________________It takes a little while to get the facts. You still don't know the facts.

LDAP is the most widely-used directory services technology in the world.

But no two implementations are necessarily compatible. For example, getting OpenLDAP & AD to interoperate (this may no longer be accurate). I know AD had some Unix tools, but they required certain versions of Sever and/or SP, and even then, weren't "great."

Well, yeah. That's like saying, my home computer has SQL on it, so how come the AT&T HR system isn't showing up under my Start Menu?

Aren't there common SQL commands that work across many SQL databases? Implementations of TCP/IP are mostly compatible, etc._________________It takes a little while to get the facts. You still don't know the facts.