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 ...
-
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. -
@silverpill idunno if it's quite the equivalent of `curl` but the universal resolver already has drivers for a lot of interesting did methods, including `did:plc` ...
https://dev.uniresolver.io/ -
@silverpill ... and `did:orb`
https://trustbloc.github.io/did-method-orb/ -
@by_caballero the curl for identity should be a command line tool that can read and write to blockchains without intermediaries (basically, an ultralight client)
-
@silverpill oh, you wanna WRITE too?
https://uniregistrar.io/
(less drivers/testing/maturity)cheqd is a cosmos SDK chain, might be one of the interesting ones to look at (i mentioned it on codeberg because it already has pathing and complex DID URLs, but i'm not too familiar with the details)
in my experience very few blockchain protocols really prioritize light-client use-cases in their core design/budget/spending, unfortunately...
-
@silverpill i would also note that `curl` is already the `curl` of ipfs and ipNS resolution; since the latter can be thought of as a DID method of sorts (it translates an opaque, self-certifying/content-addressed string into something a lot like a DID Doc), we might not need a new thing at all:
https://curl.se/docs/ipfs.html
note that in IPFS' case, the trick is in the protocol handler! -
@silverpill also, i would argue there is a fourth category of DIDs, which IPNS *almost is* (and was in 2019 when did:ipld was created to wrap it in one): DHT methods. Check out:
https://did-dht.com/
(also indebted to the sidetree family of DID methods, like orb and ion) -
In a permissioned setting (assume 0 malicious actors, and only need to be crash fault tolerant rather than Byzantine fault tolerant), just use Raft or something.
As far as N-of-M threshold signatures goes, FROST isn't too bad to implement.
https://github.com/ongardie/dissertation
https://cfrg.github.io/draft-irtf-cfrg-frost/draft-irtf-cfrg-frost.html -
@greyarea Thanks for the pointers. I probably won't work on this myself, my job is to pick a winning technology and integrate it. The winner is going to be the most resource efficient solution that supports key rotation and has redundancy while being user friendly.
One interesting project that I discovered some time ago just has come to mind: https://github.com/Revertron/Alfis
It is a lightweight blockchain-based naming system without cryptocurrency. Great idea, but it's PoW-based. There is gap between this and regular servers, and I think it needs to be filled.
-
@silverpill that’s an interesting one.
@Revertron is the PoW approach in Alfis unlikely to change?
-
@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.
-
@silverpill experimenting with fedi-ID built on did-plc would also open another door for cross-protocol interoperability.
I don’t really mind sending messages via two different social-post services, or even keeping two different post boxes. But I sure would love to have a singular digital-home address for both of these post boxes to be listed under.
-
@erlend No,
did:plc
is not good, it is just a centralized and vendor-locked version ofdid:web
. Even if they manage to switch to a distributed architecture, fediverse developers should avoiddid:plc
because it is owned by a company that develops competing social network.Good Enough solutions are
did:web
anddid: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 -
@silverpill what makes it vendor-locked?
-
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
-
@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.
-
@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):
https://fission.codes/blog/fission-tech-talks-bluesky-and-plc/