social.coop is one of the many independent Mastodon servers you can use to participate in the fediverse.
A Fediverse instance for people interested in cooperative and collective projects. If you are interested in joining our community, please apply at https://join.social.coop/registration-form.html.

Administered by:

Server stats:

502
active users

Decentralized identifiers (DIDs) can be divided into 3 categories, depending on where the authority resides:

- Secret key (did:key, did:pkh).
- Server (did:web).
- Blockchain (hundreds of them).

With a #DID derived from a secret key you can truly own your identity. Unfortunately, key rotation is not supported, and if you lose your key, you lose everything. This can be partially mitigated with distributed key generation techniques that make key recovery possible if only M of N shards are available, but they are complicated.

Servers can rotate keys, but they can also suddenly disappear, and again you lose everything.

Blockchain-based systems support key rotation and don't have a single point of failure (if done right). Sometimes they are called "servers with superpowers". However, popular ones are not suitable for the job because writing to them is very expensive and their clients need powerful computing devices and a lot of storage.

Is there a way around that? Yes. Blockchains can be very lightweight and they don't actually need a cryptocurrency, miners or stakers in order to work. There is a simple consensus algorithm known as Proof of authority, and one of the Fediverse competitors, Bluesky, seems to be planning to build such system:

https://github.com/did-method-plc/did-method-plc

>We are actively hoping to replace it with or evolve it into something less centralized - likely a permissioned DID consortium.

They are afraid to say the B-word, but "permissioned consortium" is exactly what it is. Of course, their identity #blockchain doesn't have to be the only one in existence. I think in the future we might see quite a lot of "identity cooperatives" of different shapes and sizes. Perhaps even a universal client, curl for identity, can be developed.

www.w3.orgDecentralized Identifiers (DIDs) v1.0Decentralized identifiers (DIDs) are a new type of identifier that enables verifiable, decentralized digital identity. A DID refers to any subject (e.g., a person, organization, thing, data model, abstract entity, etc.) as determined by the controller of the DID. In contrast to typical, federated identifiers, DIDs have been designed so that they may be decoupled from centralized registries, identity providers, and certificate authorities. Specifically, while other parties might be used to help enable the discovery of information related to a DID, the design enables the controller of a DID to prove control over it without requiring permission from any other party. DIDs are URIs that associate a DID subject with a DID document allowing trustable interactions associated with that subject.

@silverpill while I’m clueless about this stuff at the low level, it seems to me like did-plc is Good Enough for a starting point that works *today*.

It is transitory by design, so whichever next-stage direction the Bluesky devs take it in can be diverged from if it doesn’t align with the requirements for #NomadicIdentity in the fediverse.

I’m afraid that if we wait around another year++ for the perfect solution to come along, Good Enough alternatives will be deeply entrenched by that time.

@erlend No, did:plc is not good, it is just a centralized and vendor-locked version of did:web. Even if they manage to switch to a distributed architecture, fediverse developers should avoid did:plc because it is owned by a company that develops competing social network.

Good Enough solutions are did:web and did:key.

- did:web is equivalent to what we already have in Fediverse: keys are controlled by instances. But FEP-ef61 separates identity and data, so you can have data portability even though identity is still attached to a single server.
- did:key is equivalent to what Nostr does: keys are controlled by users

@erlend

did:web is a standard with multiple implementations

did:plc is single implementation deployed on a single server

@silverpill sure, but that doesn’t make it vendor-locked. If others are free to host their own deployments, there’s no lock-in there.

@erlend The address of the server (https://plc.directory) is written in the specification:

https://github.com/did-method-plc/did-method-plc?tab=readme-ov-file#did-creation

Alternative deployments are not allowed. Even if they remove this requirement, what's the point? did:web is simpler and better

web.plc.directorydid:plc Directory

@silverpill @erlend Indeed:
“A central directory server collects and validates operations, and maintains a transparent log of operations for each DID.”

Ironic for a Decentralized ID to be anchored around “a central directory server,” for sure. Is did:plc actually a “Must” implement for DID 1.0 compatibility?

@cmdrmoto @erlend No, DID 1.0 specification doesn't require central directories. Many DID methods depend on some kind of registry, but I think in most cases it is based on distributed ledger technology aka blockchain, so when developers make claims about decentralization, they are not completely untrue.

did:plc is not like that, it is literally a single server, and I have no idea why Bluesky team uses the term "DID". Fake-it-until-you-make-it, I guess.

www.w3.orgDID Specification RegistriesThis document serves as an official registry for all known global parameters, properties, and values used by the Decentralized Identifier ecosystem.

@silverpill @erlend @cmdrmoto PLC today works with centralized servers for convenience, but it doesn't have to stay that way. the core of the method is self-certifying identities, and that info could be distributed any number of ways.

I gave a talk recently about PLC and ways to de-centralize it more while staying backwards compatible (video, transcript, slides):
fission.codes/blog/fission-tec

FissionFission Tech Talks: Bluesky and PLC – FissionBryan Newbold, protocol engineer for Bluesky, joins us to discuss DID PLC, a self-authenticating decentralized identifier that is key to account portability on the Bluesky social network.
bryan newbold

@silverpill @erlend @cmdrmoto folks are totally welcome to do mirrors and alternative deployments or forks or whatever they want. there is an audit log to facilitate this

@silverpill @erlend @cmdrmoto "permissioned consortium" could in theory be a blockchain of some kind, but are more interested in a transparency log like Certificate Transparency, particularly the recent more efficient "tile" implementation work by Let's Encrypt

@bnewbold @erlend @cmdrmoto If this system will have multiple identity roots (logically decentralized, not a single database), and will not depend on DNS, it might be actually useful.

@by_caballero @silverpill @erlend @cmdrmoto yup! been following/lurking both the key transparency and MIMI work at IETF.

I'm planning to attend IETF 120 in-person in July if you want to chat there (or email or other venues)

@bnewbold @silverpill @erlend @cmdrmoto I'm not sure if i can be physically present in Vancouver, but whether or not I am, i am definitely down to chat between now and then, as well as during the week of IETF whatever time zone i'm in 💪