Conversation

Notices

1. Embed this notice
   Jeff Martin (cuchaz@gladtech.social)'s status on Thursday, 04-May-2023 05:21:00 JST Jeff Martin

   @grishka yeah! I'm trying to design a decentralized identity system and I keep struggling with this problem too. If the using the pubkey as the identity is the problem, then what's the solution? And solutions that appeal to some centralized authority to resolve the issue aren't allowed, because, well ... decentralized. How can we do better?

   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Thursday, 04-May-2023 05:20:58 JST silverpill

     in reply to

     • Dmitri | 🇺🇦

     @cuchaz @grishka @dmitri did:onion is like did:web but without external authority. If you want to support key rotation and avoid single point of failure, blockchain is probably the only way.

   • Embed this notice
     Jeff Martin (cuchaz@gladtech.social)'s status on Thursday, 04-May-2023 05:20:59 JST Jeff Martin

     in reply to

     • Dmitri | 🇺🇦

     @dmitri @grishka DNS is technically disqualified here because it's a centralized authority. But despite that, it may be the best option we have. The trouble is, the DNS system isn't really accessible to most people, so the UX isn't great there.

     Most of the other DID resolvers are blockchains (ugh), so I'm trying to find something better. It may not exist though. If we're not going to use pubkeys as ids directly, then something like `user@domain` may be the best we can do.

   • Embed this notice
     Dmitri | 🇺🇦 (dmitri@social.coop)'s status on Thursday, 04-May-2023 05:21:00 JST Dmitri | 🇺🇦

     in reply to

     @cuchaz @grishka ok, but also, use DIDs (Decentralized Identifiers). Like, start with did:web (which is just a well-formatted JSON object that lives on a domain).