Re: Introducing the DID DHT Method

 Brian,

Thanks for the feedback. Here is what we’re thinking:


   - As a fallback you can continue to use your did:key/did:jwk as intended
   — so the root/identity key is guaranteed to be stable
   - It is only ever an optional resolution step for more keys/properties
   in the document
   - Manu had suggested a new prefix for did:key that signifies the DID is
   resolvable specifically on this DHT, which should address at least one of
   your concerns
   - Forking is handled by the sequence number property of the DHT (as
   specified as a part of BEP44); historical resolution is something the spec
   covers which partially addresses this too


Open to suggestions to mitigate more of your concerns! I think it’s great
to call these out.

Gabe

On Dec 11, 2023 at 2:36:10 PM, Brian Richter <brian@aviary.tech> wrote:

> Although I see upgrading of static keys to a more dynamic method as a
> desirable trait the proposed approach gives me hesitations. I don't think
> an identifier should ever turn from static to dynamic as this introduces
> severe interoperability concerns..
> - Is this did:key the static one or has it been upgraded?
> - Was it upgraded on did:dht or
> did:another-method-that-has-similar-upgradability-pattern?
> - Is this fork A or B of did:key:z...
>
> In general though, this method is great. I look forward to playing with
> it. Thanks Gabe!
>
> On Mon, Dec 11, 2023 at 2:25 PM Gabe Cohen <gabe@tbd.email> wrote:
>
>> Steve,
>>
>> Definitely — you can find some comparison of IPFS and Mainline DHT here
>> <https://github.com/Nuhvi/pkarr/issues/5#issuecomment-1701608315>. My
>> condensed reasoning is that Mainline is more distributed, performant, and
>> has significantly more real world usage than IPFS.
>>
>> I spent some time looking at (and trying to implemented…) IPID DID method
>> <https://did-ipid.github.io/ipid-did-method/>. It is quite old and in
>> need of an update; I had a hard time implementing it properly and I’m
>> curious if there is anyone actually using it. I reached out to the original
>> author but that conversation didn’t really go anywhere. Conceptually IPID
>> is similar to DID DHT. There are some minor differences, such as Mainline
>> only supporting Ed25519 (IPLD supports RSA and some others too), and limits
>> on file size (1KB on Mainline), which I think is a good thing for
>> decentralization (see: block size wars).
>>
>> One of the most promising aspects, I believe, for did:dht is
>> interoperability and upgradability of existing methods like did:key and
>> did:jwk, which we’ve started to profile here
>> <https://did-dht.com/registry/#interoperable-did-methods>. Authors of
>> both specifications are amenable to this functionality, which I believe
>> could result in near-term wide-spread adoption of the method.
>>
>> Gabe
>>
>> On Dec 11, 2023 at 1:55:51 PM, Steve Capell <steve.capell@gmail.com>
>> wrote:
>>
>>> Hi gabe
>>>
>>> Well at least it’s not another me-too cryptocurrency Ponzi scheme ;)
>>>
>>> I like the idea of DHTs as a decentralised resource discovery mechanism
>>>
>>> Would you care to offer some comparisons / advantages / disadvantages
>>> over the IPLD did method?
>>>
>>> Steven Capell
>>> Mob: 0410 437854
>>>
>>> On 12 Dec 2023, at 4:23 am, Gabe Cohen <gabe@tbd.email> wrote:
>>>
>>> 
>>> Cross-posting from the DID WG mailing list:
>>>
>>> Hi everyone,
>>>
>>> Daniel Buchner and I have been working on a new DID method called DID
>>> DHT. Yes, I know what you’re thinking…another DID method, really? But we
>>> believe it’s worth it for a truly decentralized and (relatively) simple
>>> method which does not rely on a blockchain. We believe this sweet spot can
>>> enable true decentralization and broad adoption in the market, as
>>> blockchains remain undesirable for many.
>>>
>>> Here are a few key points:
>>>
>>>
>>>    - Utilizes BitTorrent’s mainline DHT
>>>       - Has tens of millions of nodes
>>>       - Has been around for 15+ years
>>>       - Already widely used by many large companies (e.g. Ubuntu,
>>>       Microsoft)
>>>    - 1 KB maximum payload size
>>>       - Uses a mapping of DID Documents to DNS resource records for
>>>       semantics and compression
>>>    - Relies on signed mutable records from Mainline DHT (BEP44
>>>    <https://www.bittorrent.org/beps/bep_0044.html>)
>>>       - No need to trust a server — each record is signed!
>>>       - Order enforced by a sequence number.
>>>    - Supports any feature of a DID Document
>>>       - Except for root key rotation; relies on a stable root key
>>>    - Interoperable with existing DID methods such as did:key and did:jwk
>>>       - We have spoken with authors of both methods, who are amenable
>>>       to support an optional resolution step to the DHT to extend these existing
>>>       methods
>>>    - We have mechanisms for spam reduction, gateway discovery, and more
>>>    features!
>>>
>>>
>>>
>>> You can find the latest draft of the specification here:
>>> https://did-dht.com/
>>>
>>> At Block / TBD we’ve already put out a number of open source
>>> implementations in Go, Kotlin, and Typescript. You can find links at our
>>> repository here <https://github.com/TBD54566975/did-dht-method>.
>>> Additionally we’re hosting a free-to-use gateway server which is intended
>>> for *testing purposes only: *
>>> https://diddht.tbddev.org/swagger/index.html. We will be continuing
>>> development of our open source gateway and plan to contribute a driver for
>>> the universal resolver.
>>>
>>> Concretely we are looking for feedback and other parties interested in
>>> testing the method out. We have high hopes that should DIDs be on a path to
>>> resolution in browsers, DHT could be a strong candidate.
>>>
>>> Looking forward to your feedback,
>>>
>>>
>>>
>>> Gabe Cohen
>>>
>>> Lead Platform Engineer, Verifiable Credentials
>>>
>>> gabe@tbd.email <gcohen@tbd.email>
>>>
>>> TBD <http://tbd.website/> | LinkedIn <https://linkedin.com/in/cohengabe>
>>> | Twitter <https://twitter.com/decentralgabe>
>>>
>>>
>>>