Recent searches
Search options
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.
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?
Revertron @erlend @silverpill Yep, it is very unlikely to change. Ownership of a domain must have a price.
@Revertron @erlend Can ownership depend on approval by a group of authorities but otherwise be free?
(At least in theory - in a hypothetical Alfis fork)
@silverpill You may do this, but the people don't want any authority to "approve" their domains.
@Revertron @erlend This is a trust model of a fediverse server. People may dislike authority when there is only one name database, but there could be hundreds of them.
Blockchains are usually engineered with an assumption of powerful global adversary. That makes sense for a financial system, but not so much for identity. The system that I want is closer to a regular server, it only needs enough redundancy to survive a hardware failure and an admin who forgot to renew the domain name.
@silverpill > but there could be hundreds of them
And how will they interoperate?
For example, I have my own DB, you have yours. I direct my PC to resolve names from my DB, you from yours. But domains are different, even intersecting.
@Revertron Good question, and I don't have a definite answer. Perhaps databases can be identified by a public key of an authority (or something akin to a multisig address)? A fully qualified name may look like this:
myname.z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK.namesystem
That makes it poor DNS alternative (names are not human readable), but it's good enough for decentralized identity
@silverpill Don't try to invent the wheel :)
Database must be single and replicated. And generally you should choose between PoW/PoS and PoA.
Why do you need such a system in the first place? I didn't get it.
@Revertron See adjacent comment:
https://mitra.social/objects/018e570a-c86d-b3d8-caf2-88dfb8eaf5aa
I think it is better to avoid logically centralized systems. From the perspective of a user, cryptocurrencies are a total disaster, it's like 10000 competing standards. Only a tiniest fraction of them have network effects strong enough to matter, and you're constantly pressured to pick a single database, though of course all of them have different tradeoffs so it is not really possible.
Instead there should be one standard and 10000 competing providers.
@silverpill
But those providers must have the same synced DB.
@Revertron Coins need to move between providers, so bridges between providers and some shared database is probably unavoidable. I think with identities each provider can have different database.
@silverpill @erlend
The easiest way is something like this:
1. We have one small blockchain without coins.
2. Every server is proving their authority over their domain, and create a block in blockchain.
3. Every other node/server is checking for some key published on that server, for example server1.example/root.key AND accept that block in their copy of blockchain.
4. After that this server can create IDs in its 'namespace', signing blocks with new identities by its key.
5. Maybe every identity can have their own keypair to move from one 'namespace' to another. Even if that server1 dies.
@Revertron Yes, but this still requires a single database, right? Only the second tier (namespaces) is logically decentralized.
What if there is a single peer to peer network, but multiple databases, each database is completely independent and can not be removed from the network. Like torrents, but with mutability. Is it possible?
In such network clients will only download data they actually need, and each database will have its own rules (small invite-only namespaces, big commercial ones, and everything in between)
@silverpill
> independent and can not be removed
This is why the blockchain must be a single entity. Every node should have ALL info if you want it to be not removable :)
@Revertron Well, maybe we shouldn't call it blockchain then, but it doesn't have to be a single entity. Torrents and IPFS objects can't be removed. In fact IPNS is probably the closest thing to what I want, but it is too slow and buggy and the client is not lightweight.
@Revertron Also IPNS name is controlled by a single key, but in a proper system control should be distributed
@silverpill Distributed to which entities? Who will own those names?
@Revertron A single person, or a group, or a company. Let's assume for a moment that IPNS performance has improved and it supports FROST or something like that.
The IPNS name is a namespace root. It is a pointer to some verifiable data structure, probably an append-only log, where all identity operations are recorded: add key, update key, revoke key. If the root key of namespace is distributed, no one can single-handedly add or remove an identity. Operations are performed only by a consensus or a majority vote.
Such system would have all desired properties: redundancy on all levels, organizational diversity (no logical centralization), no payments required, key rotation is possible, user friendly.
So something like certificate transparency logs, but for identities?
@greyarea @Revertron I didn't know about transparency logs. Yes, sounds exactly like that
https://certificate.transparency.dev/howctworks/
>A certificate ties together a domain and a public key.
And in our identity system certificate would tie a name in namespace and a public key.
@Revertron I should probably provide more context. The goal is to build a user-friendly decentralized identity system for Fediverse. It will co-exist with DNS-based handles like @user@social.example, so readability is not a priority.
The idea is described in more details in this proposal: https://codeberg.org/fediverse/fep/src/branch/main/fep/ef61/fep-ef61.md
Key-based identity will also be allowed, so people who want more control could choose that. The 'smallchain' option that I'm thinking about is supposed to be a middleground between key-based identity and centralized identity providers.
@Hyolobrika @erlend @Revertron The advantage is having a choice between owning your identity key and trusting an authority (with varying degrees of trust: single authority, friendly majority, etc).
This is possible because identifiers will be based on DIDs.