That said, the Querki project is reminding me that doing this stuff right is pretty hard. Consistently distinguishing between a User (an actual, real-life person, accessing Querki on their desktop or phone), and a potentially unlimited number of distinct Identities for each of them, requires constant, careful thought. Doing it *well*, so that Identities don't "leak", is especially tricky.
Mind, I'm not promising HIPAA-grade protections at this point, much less life-and-death security: it's infeasible for me to do that level of security auditing any time in the next year or two. But that *is* the long-term goal. I should be able to have a Facebook account, multiple Google profiles, an LDAP profile from work, a Twitter account, a native Querki login, an LJ login, and so on, all connected to the same Querki account, and I should be able to easily say that certain of those accounts aren't visibly the same person.
(Why? Because I'm trying to not build Yet Another Bloody Social Network. I would like folks to be able to use their existing flists from the social networks inside Querki, and have it Just Work. But that requires dealing with the fact that those flists aren't necessarily fungible: I might well be trying to keep them distinct. Querki should facilitate that, insofar as we can.)
The problem pervades almost everything. Take my current project, for a typical example: implementing Notifications. The trick here is that a Notification (a System Message, a Personal Message, a Space Change Notification, whatever) is sent from an Identity to another Identity, but is actually *delivered* to a User. That is, I should be able to easily see all of the new Notifications from all of my Spaces, regardless of which Identity I am using in any given Space. And when I reply to one, it should automatically come from the appropriate Identity, without me needing to think about it manually.
(Yes, there are nasty edge cases if I want to have multiple distinct Identities within the same Space. For the moment, I'm simply not allowing that -- it opens up all *sorts* of sock-puppeting abuses, and needs to be thought through very carefully.)
I don't think I actually know any service that has ever actually tried to do this right, although it wouldn't surprise me if a few exist. Making it usable is going to be a heck of a project. Mind, I'm not tackling the thorny UI issues yet -- so far, we only have the native Querki logins, and we don't yet have the ability to link those together. But if I'm ever to have the slightest hope of accomplishing this, I have to get the data structures and communication right, and if we're not going to have accidental breaches the system has to play completely fair internally: the knowledge of how Identities relate to Users is tightly controlled internally, and most subsystems don't have direct access to it.
It's a fascinating project, and it does give me a *little* sympathy to the social network companies. It doesn't require malice to not want to deal with this -- the simple truth is that, if you don't build it in from the beginning, with a crisp distinction between your concepts, it's probably nearly impossible to do it well...