Previous Entry Share Next Entry
Getting Identity abstractions right can be tricky, but useful
[For the identity geeks in the audience]

I sometimes talk about how piss-poor the major players in the social networking world are about Identity, and how annoying that is -- Facebook and Google's naive assumption that one person should have one and only one identity online, based on their wallet name, is both naive and dangerous. Frankly, it's poor engineering, and fails to recognize that *most* people have multiple distinct identities, even if those are as loose as "me at work" vs. "me at home".

That said, I will admit that doing it right isn't easy. I'm putting a fairly preposterous amount of effort into getting the abstractions right for Querki, even though Querki really only lets you have one identity so far. For the moment, your identity is your Querki login, but that's always been a temporary plan. In the long run, the notion is that you can attach any number of Facebook, G+, Twitter, (hopefully LiveJournal), etc, accounts to log into Querki, and use all of them distinctly as you see fit. Moreover, I'm trying hard to get Querki to grok the notion that there are distinct identities, and we should try hard to avoid "leakage" between them.

That's all about getting the abstractions right, and I just had a reminder about how useful it can be to do that correctly from the beginning.

I'm in the middle of implementing Apps -- the ability for one Space to be a "child" of a higher-level Space, using all of its Models and Things. Security's important there -- the child Space can see everything in the parent App, so I've added a new permission, saying who is allowed to use this App. That "who" is the owner of the child Space. And last night, I was tearing my hair out, because I was missing a bunch of code pathways to get at the User who owns the Space.

Fortunately, this morning I realized that that was because I was fighting my own abstractions. This was hard because it *should* be hard, because it's incorrect: if a User inherits the App from a Space owned by the wrong Identity, that leaks the relationship between that User's Identities to the owner of the App. It should be an Identity relationship, not a User one, and my own architecture was pushing back at me, telling me I was making a mistake.

That's as it should be, and it's an illustration that Identity isn't something you can easily fix after-the-fact -- you can't build a system assuming a 1-to-1 relationship between User and Identity, and then make it subtler later without a lot of difficulties. Rather, the distinction needs to be baked in from the very start.

(Why bother? User convenience, to a large degree: I don't want to have to keep logging out and logging back in in order to use a couple of distinct identities. And partly to allow you to manage your identities flexibly, so that you *can* treat identities from different services as linked if you choose to do so: the long-term goal is that you can manage your portfolio of diverse identities as you see fit. But in large part, it's a grand experiment -- an exploration of what happens when you take this problem seriously, so we can collectively learn how to make Identity on the Internet better.)

  • 1
a very nice idea! I miss this when using Google's stuff periodically

Yeah -- my opinions on this subject got a *lot* sharper during the Google+ Nymwars. (Which offended me, more than anything else, because it illustrated such poor understanding of the problem -- which in my book, is just bad engineering...)

  • 1

Log in

No account? Create an account