Conversation

Notices

1. Jeff Martin (cuchaz@gladtech.social)'s status on Monday, 03-Apr-2023 05:48:14 JST Jeff Martin

   • silverpill

   @helge @silverpill Turns out, the hard part there is the lookup mechanism. Sure, say we make the URI something where there's no HTTP(s) server listening to it. Something like `randoproto:myPubKey`. Then you need some kind of service to translate that into a URL on an AP server.

   But what service gets to do that translation? Right now AP basically depends on DNS as the translation service, except it's translating domains to IPs. But if we wanted to translate randoproto URIs all the way down to an IP and an HTTP path, we'd have to build something very DNS-like. That is, an authority that knows all the `myPubKey` values and their current domains. But asking an authority for permission to use your portable identity completely defeats the purpose of portable identities.

   It's the entire concept of linking data with URIs that's the problem. The whole point of portable identities is that they exist, and can be used, independently of any linkages.

   • silverpill (silverpill@mitra.social)'s status on Monday, 03-Apr-2023 05:48:13 JST silverpill

     in reply to

     @cuchaz @h

     >randoproto:myPubKey

     FEP-c390 is based on DID standard so it will be something like did:randoproto:myPubKey. In a DID document you can specify your actor URL:

     https://www.w3.org/TR/did-core/#also-known-as

     >But what service gets to do that translation?

     It depends on a DID method. You can see registered ones here:

     https://www.w3.org/TR/did-spec-registries/#did-methods

     I don't have a favorite one at the moment, though. IPNS could be a good starting point, but it is far from perfect.

   • Jeff Martin (cuchaz@gladtech.social)'s status on Monday, 03-Apr-2023 09:04:00 JST Jeff Martin

     in reply to

     • silverpill

     @silverpill @helge To be honest, I was never all that interested in DIDs. The idea that you have to ask some external service if the identity is valid or not was always a bit of a turn-off. Ideally, identities could show their own validity without the need to appeal to an external authority. At least, that's the approach I took with my Burger portable identities.

     Last time I checked, I think all the DID methods were basically blockchains. Ugh. No thanks.

     It's been a while since I looked, so maybe things have improved since then? Using a DHT might get you something a little more reasonable, but DHTs have their own problems.

   • silverpill (silverpill@mitra.social)'s status on Monday, 03-Apr-2023 09:04:00 JST silverpill

     in reply to

     @cuchaz @h Many registered DID methods depend on blockchains, but not all. For example, did:ipid requires IPFS node; did:onion requires an onion service.

     If you're looking for a completely self-contained DID, check did:key. It is just a public key represented as an URI.

     I think DIDs are very important for decentralized networks. You can start using one type of DID and add support for other methods later, without changing the protocol. For example, FEP-c390 is compatible with many kinds of external identities because the subject property is a DID. There's no dependency on any particular naming system or signature algorithm.