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...

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)

Mike Macgirvin 🖥️

a did:uri is a string that represents you. It is not tied to  DNS, so it can represent you at any server. Now the truth is the web is DNS based so we have to resolve it to a location to find you. This requires a DNS operation of some kind. But the location is not actually you. It's just where you're hanging out today. You can move. Your id is the same.

OIDC is an authentication and authorisation framework. DID is just an identity. Proving it's your identity requires you to sign something.

Finding the responsible adult you  mention is just a slightly different algorithm. You can forget about the location. It is only relevant for knowing somewhere to look for the identity. But you're looking for the identity. In practice this means you won't have just 'user' storage. You'll have user (identity) storage and location storage, and it isn't necessarily a 1:1 mapping. You can have several locations for a given identity. For traditional fediverse accounts, there will be a 1:1 mapping.

If you want to  block a person, blocking locations isn't going to cut it. You will need to block the identity.

That's the short and sweet.

Mike Macgirvin 🖥️

Oh, and the did resolver algorithm we're going to be using with ActivityPub does not rely on proof of waste technology. It uses ed25519 keys and a lookup on participating servers at a .well-known endpoint. That's it.