Okay, sure, let's do this. "nomadic identity" 1. No one has ever even come close to explaining how using a did: uri is supposed to work2. Even assuming it works, no one can explain how it's different than oidc3. Even assuming it was different, what hap...

Ariadne Conill 🐰:therian:

there is a longer discussion to be had about the political implications of nomadic identity, but suffice it to say the large question is “why should i have to trust my admin?”

and, well, my answer to that question is — ideally not. i have spent 20 years doing trust and safety work in OSS community spaces. the reality is that power structures where there is no accountability for an admin frequently get abused to suit the whims of that admin.

as i explained to andrew lee, before he decided to go run freenode into the ground, a freenode staff member had the authority to destroy the careers of people they found undesirable, with no due process. this isn’t something we should want for the fediverse.

the fundamental power imbalance is visible in the fediverse on a daily basis, both in terms of actual incidents, but also in terms of how larger instances get a larger pass because they are “too big to fail.”

the answer given is “move to a different instance with different governance,” which is a fine enough answer if moving were lossless and low cost. making that the reality is the goal of nomadic identity as pertaining to the fediverse.

right now, users are effectively locked into all decisions made by their admin, because if an admin decides to say, defederate an instance and they disagree with that decision, the relationships were already severed and the user has to go manually repair them from her new account.

in a nomadic world, i would have mirrored my account and preferences to other instances in advance, and when my preferred instance changes, the relationships were already mirrored ahead of time, thus protecting me against admins who make decisions that would otherwise negatively impact my use of the fediverse.

Irenes (many)

@jenniferplusplus we have read the DID spec (and related specs), mostly because we wanted to be able to speak to it

the short answer is that it is a framework for companies operating proof-of-waste systems to make money by selling your "decentralized" account to you

Irenes (many)

@jenniferplusplus reading the specs makes it very clear that that's the only use-case anyone cares about. there are a couple fig leaves suggesting that there might be non-anarcho-capitalist ways to use it someday, but none of those are actually specced out.

Ariadne Conill 🐰:therian:

@jenniferplusplus

these days however i am not really sold on what we presently have being an ideal solution.

my take on an ideal solution is more one of a “controlled identity,” where i publish some .well-known URI on my domain which maps to a set of inboxes and outboxes. users can then poll those inboxes and outboxes for interactions.

this would be a better approach than anything the nomadic folks are doing, as it enables a user to have full control over what data is where. that is something where the bluesky folks could have really won over AP, but sadly they are worrying more about their fake DID URIs instead

Jenniferplusplus

@ariadne see, these are real valid concerns and actual implemetable solutions. Compared to the libertarian fantasy land that is every explanation of nomadic/distributed/sovereign identity.

Jenniferplusplus

@ariadne fwiw, these are also concerns that I share. I think there's also an easy intermediate step, which is to allow for user provided private keys. That gives a lot of extra weight to the aka relation, and it allows people to manage a credible exit from their home server that doesn't depend on the home server's cooperation.

Hrefna (DHC)

@jenniferplusplus

My kingdom for user-controlled keys x_x

@ariadne

Hrefna (DHC)

@jenniferplusplus Every time I read anything on DID it seems to quickly devolve into ranting about ICANN and I just give up. If it's not in the spec it is in every doc that connects to the spec in any meaningful way. -.-

Jenniferplusplus

P.S. any identity solution that requires everyone to maintain their own individual domain name and dns records is a terrible idea that cannot work in practice. Not strictly the same thing as DID, I know. But it's always the very next thing that comes up.

Dana Fried

@jenniferplusplus any solution that doesn't require being part of a community is only going to appeal to the most paranoid and/or antisocial people.

"Oh no what if my admin blocks a domain I have followers on?"

Perhaps you should have read the about page of your server and realized it wasn't going to be friendly to the kinds of people who follow you?

Sometimes you do have a shit admin or shit governance. If you're paying attention, you'll usually notice it long before it's actually a problem.

Jenniferplusplus

@tess I mean, sort of. The whole nomadic identity concept is connected to a real problem. In the fediverse, we call it admin drama. All these servers are someone's little hill, of which they are the little king. The only real choice most people have is to choose their king, and there's basically no information to go on when making that choice.

But nomadic id is not an actual solution to that problem

Jenniferplusplus

@tess but it feels like a solution. And it's easier than the actual solution, which is to do the real work of governance. Although it would help a lot if we could build told that make governance easier instead of harder. Or more approachable instead of more elite. But that's a somewhat different topic.

Cassandrich

@jenniferplusplus I have a lot of ideas on this that solve a good portion of the problems.

Jenniferplusplus

@dalias ideas to make dns a workable identity registry?

Cassandrich

@jenniferplusplus One choice among others, and in a way that doesn't require perpetual maintenance of it.

Jess👾

Yeah, but users are absofuckinglutely TERRIBLE at keeping track of their own keys. The number of my users who have lost/broken their phones/hardware tokens, or wiped and sold them without migrating their keys first is Way too damn high, even among some very smart R&D engineers who really REALLY ought to know better...
@hrefna
@jenniferplusplus @ariadne

Hrefna (DHC)

@JessTheUnstill

That's why I mentioned controlled (or managed) keys rather than provided keys, specifically.

You can have a third party or system with key access (CMEK/KMS-style), you can allow revocation and blind replacement so long as you don't require key possession for login, you can use a third party to verify it (VC-style or keybase style), etc.

It just depends on what you are aiming for and what the consequences are of it going sideways.

@jenniferplusplus @ariadne

smallcircles (Humanity Now 🕊)

@hrefna

Great thread. Your mention of Keybase made me forward this discussion to the @keyoxide matrix chatroom.

Keyoxide

Modern and secure platform to manage a decentralized identity based on cryptographic keys

(keyoxide.org)

(Note: Years ago I mused a bit about use cases for Keyoxide on the fedi and created this issue https://codeberg.org/keyoxide/keyoxide-web/issues/105 )
@JessTheUnstill @jenniferplusplus @ariadne

smallcircles (Humanity Now 🕊)

@hrefna @keyoxide @JessTheUnstill @jenniferplusplus @ariadne

I cross-referenced this discussion on SocialHub in Nomadic Identity topic:

Nomadic identity for the fediverse?

hey all, was wondering, is anyone still actively working on #nomadicidentity for the fediverse? My interest in nomadic identity is somewhat inspired by scuttlebutt: to allow for migrating an account between servers, wit…

SocialHub (socialhub.activitypub.rocks)

smallcircles (Humanity Now 🕊)

@irenes @jenniferplusplus

Yeah, it's sad. Couple years ago I found this early draft spec about did:orb by a - unknown to me - club called Trustbloc. Focused on fedi, and not crypto-shenanigan-related afaics. I added the spec to delightful-activitypub-development curated list.

But I am not following this club and looking in the GH repo just now, I think we have a PoWaste going on. The spec is also related to a "Sidetree protocol" now (Not gonna check out more atm).

GitHub - trustbloc/orb: A DID method implementation that extends the Sidetree protocol into a Fediverse of interconnected nodes and witnessed using certificate transparency. Spec: https://trustbloc.github.io/did-method-orb/

A DID method implementation that extends the Sidetree protocol into a Fediverse of interconnected nodes and witnessed using certificate transparency. Spec: https://trustbloc.github.io/did-method-orb/ - trustbloc/orb

GitHub (github.com)