Conversation

Notices

1. silverpill (silverpill@mitra.social)'s status on Thursday, 04-May-2023 05:24:17 JST silverpill

   in reply to

   • Jeff Martin
   • 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.

   • Jeff Martin (cuchaz@gladtech.social)'s status on Thursday, 04-May-2023 05:24:18 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.

   • Dmitri | 🇺🇦 (dmitri@social.coop)'s status on Thursday, 04-May-2023 05:24:19 JST Dmitri | 🇺🇦

     in reply to

     • Jeff Martin

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

   • Jeff Martin (cuchaz@gladtech.social)'s status on Thursday, 04-May-2023 05:24:20 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?