Some, although much of it is pretty old. My old professional blog, The Art of Conversation, was focused on the subject of online conversation, and identity management was a thread that I developed during that.
(My original stab at a startup, CommYou, was specifically focused on line conversation; I shut that down when Google released Wave, which looked uncannily similar even though many of the key details -- *especially* around identity management -- were quite different. Art of Conversation was basically CommYou's blog.)
Anyway, my thinking on the subject originally coalesced (in 2012) in this post, which spells out the layers of a proper decentralized identity architecture. It's just a sketch, but I think it's still mostly correct.
As for Querki itself, I'm pretty sure I've described its identity architecture on LJ (and thus, now on DW), but it was probably back in 2013 so it's not trivial to dig out offhand. (ETA: ah, here it is.)
[NB: Querki is essentially a wiki system on steroids. Individuals and communities use it to create "Spaces", which are distinct namespaces, each of which is essentially a database-plus-website. The goal, spelled out a bit more here, is to make it quick and easy to create small, collaborative, data-centric websites. Basically, it's what I've always wanted wikis to be able to do, so eventually I built it.]
Anyway, Querki uses a simplified version of the decentralized architecture (easier since it is for a single site), which basically boils down to three distinct layers:
-- User: an actual account with Querki, that somebody can log into. Users are *private*: in principle, there should be no way for anyone else to see the entire User. So far, I see no reason to ever compromise on that point.
-- Identity: a *public* facade for a User. In principle, a User may have any number of distinct Identities. (In practice, I've realized that there need to be some limits, to cut down on sock-puppeting -- in particular, I limit Users to a single Identity per Space.) Identities *may* be publicly linked, but that's on a strictly opt-in basis.
-- Person: an Identity in a Space. This is public (within the constraints of the Space's own security controls), and is publicly linked to the Identity, but may be further customized to the needs of the Space. Basically, it's the application view of an Identity.
Mind, while most of this is built, it's not heavily tested yet and mostly not end-user-visible yet: for the moment, Querki still only allows one Identity per User. That'll change when I add the ability to link Querki Users to logins from other sites with OAuth2 (and maybe OpenID, although sadly that has mostly decayed away) -- part of the point is to make it easy to use Querki with whatever identity you care to import from elsewhere, while still keeping those identities distinct by default. And eventually I'll allow you to create multiple Querki-defined Identities per User, although that needs to be done carefully to avoid name squatting.
I built Querki's identity-management system in-application because it was easier, and Querki is insanely ambitious enough as it is. I still occasionally toy with spinning out a separate not-for-profit project to build the decentralized identity management system, and reorient Querki to use that instead. IMO, it's still the *right* way for all this stuff to work...
Re: Pseudonymity
Date: 2018-12-29 04:26 pm (UTC)(My original stab at a startup, CommYou, was specifically focused on line conversation; I shut that down when Google released Wave, which looked uncannily similar even though many of the key details -- *especially* around identity management -- were quite different. Art of Conversation was basically CommYou's blog.)
Anyway, my thinking on the subject originally coalesced (in 2012) in this post, which spells out the layers of a proper decentralized identity architecture. It's just a sketch, but I think it's still mostly correct.
As for Querki itself, I'm pretty sure I've described its identity architecture on LJ (and thus, now on DW), but it was probably back in 2013 so it's not trivial to dig out offhand. (ETA: ah, here it is.)
[NB: Querki is essentially a wiki system on steroids. Individuals and communities use it to create "Spaces", which are distinct namespaces, each of which is essentially a database-plus-website. The goal, spelled out a bit more here, is to make it quick and easy to create small, collaborative, data-centric websites. Basically, it's what I've always wanted wikis to be able to do, so eventually I built it.]
Anyway, Querki uses a simplified version of the decentralized architecture (easier since it is for a single site), which basically boils down to three distinct layers:
-- User: an actual account with Querki, that somebody can log into. Users are *private*: in principle, there should be no way for anyone else to see the entire User. So far, I see no reason to ever compromise on that point.
-- Identity: a *public* facade for a User. In principle, a User may have any number of distinct Identities. (In practice, I've realized that there need to be some limits, to cut down on sock-puppeting -- in particular, I limit Users to a single Identity per Space.) Identities *may* be publicly linked, but that's on a strictly opt-in basis.
-- Person: an Identity in a Space. This is public (within the constraints of the Space's own security controls), and is publicly linked to the Identity, but may be further customized to the needs of the Space. Basically, it's the application view of an Identity.
Mind, while most of this is built, it's not heavily tested yet and mostly not end-user-visible yet: for the moment, Querki still only allows one Identity per User. That'll change when I add the ability to link Querki Users to logins from other sites with OAuth2 (and maybe OpenID, although sadly that has mostly decayed away) -- part of the point is to make it easy to use Querki with whatever identity you care to import from elsewhere, while still keeping those identities distinct by default. And eventually I'll allow you to create multiple Querki-defined Identities per User, although that needs to be done carefully to avoid name squatting.
I built Querki's identity-management system in-application because it was easier, and Querki is insanely ambitious enough as it is. I still occasionally toy with spinning out a separate not-for-profit project to build the decentralized identity management system, and reorient Querki to use that instead. IMO, it's still the *right* way for all this stuff to work...