Add DHT create support

[mihai-chiorean]

Summary

The main goal of this PR is to implement DHT Create operation, however this comes with a few changes to the diddht package.

The DHT method requires a relay/gateway - hence it makes an HTTP request, so it needs a client. We've opted to have a default client, but also open the API for consumers to pass their own client.

DID DHT API

There are 4 methods exposed by the package for creating and resolving dids:

• Create(opts ...DHTDidOption) (*did.BearerDID, error)
• CreateWithContext(ctx context.Context, opts ...DHTDidOption) (*did.BearerDID, error)
• resolver.Resolve(uri string) (didcore.ResolutionResult, error)
• resolver.ResolveWithContext(ctx context.Context, uri string) (didcore.ResolutionResult, error)

Resolve API is part of a Resolver which can be instantiated with NewResolver(relayURL string, client *http.Client) *Resolver.

Create API takes some options as input; Available options are:

• WithKeyManager
• WithVerificationMethod
• WithService

[!TIP] A possible improvement here is to have a default resolver in the didddht package, which is now implemented in the dids package. This would make the API more consistent with Create

Package structure

The diddht package has some [internal/](https://go.dev/doc/go1.4#internalpackages) packages that are strictly used to implement the DHT method spec.

• internal/dns - includes the functionality needed to convert a did doc into DNS TXT resources according to the DHT spec
• internal/bep44 - used to create and decode the BEP44 representation of the payload that gets stored, according to the Pkarr spec
• internal/bencode - implements the bencode features needed for the DHT spec; we've chosen to implement a minimal functionality instead of bringing in a large dependency tree
• internal/pkarr - the Pkarr client code

TODO

• [x] Add and use the TLD from the DNS representation
• [x] Fix merge conflicts
• [x] a private key needs to be generated for each verification method provided
• [x] returning bearer did - pointer or value?
• [x] encode/decode vs marshal/unmarshal for bep
• [x] Consistent naming of options
• [x] Constants for dns encoded field names
• [x] relay/http client optionality
• [x] rename relay to gateway (to conform with similar to what was done in swift, kotlin, and JS )
• [x] Rename private key to verificationmethod
• [x] The identity key is also a verification method
• [ ] general comment not sure if you already have this - but these two vectors should be covered by tests here https://did-dht.com/#test-vectors

[mistermoe]

The DHT method requires a relay/gateway - hence it makes an HTTP request, so it needs a client. We've opted to have a default client, but also open the API for consumers to pass their own client.

do you mean http client here or relay url? in the code i see optionality for relay urls but not for http clients.

[KendallWeihe]

Apologies I'm late to the show here... looking over now... 👀

[mihai-chiorean]

The DHT method requires a relay/gateway - hence it makes an HTTP request, so it needs a client. We've opted to have a default client, but also open the API for consumers to pass their own client.

do you mean http client here or relay url? in the code i see optionality for relay urls but not for http clients.

func WithRelay(relayURL string, client *http.Client) CreateOption { I'd consider this as configuring an optional relay, including custom relay url and client. Or were you referring to having independent defaults for each and being able to "option" just 1 of them?

[mistermoe]

The DHT method requires a relay/gateway - hence it makes an HTTP request, so it needs a client. We've opted to have a default client, but also open the API for consumers to pass their own client.

do you mean http client here or relay url? in the code i see optionality for relay urls but not for http clients.

func WithRelay(relayURL string, client *http.Client) CreateOption { I'd consider this as configuring an optional relay, including custom relay url and client. Or were you referring to having independent defaults for each and being able to "option" just 1 of them?

was referring to the latter

[mihai-chiorean]

The DHT method requires a relay/gateway - hence it makes an HTTP request, so it needs a client. We've opted to have a default client, but also open the API for consumers to pass their own client.

do you mean http client here or relay url? in the code i see optionality for relay urls but not for http clients.

func WithRelay(relayURL string, client *http.Client) CreateOption { I'd consider this as configuring an optional relay, including custom relay url and client. Or were you referring to having independent defaults for each and being able to "option" just 1 of them?

was referring to the latter

Honestly I think the current optionality is good enough, maybe with some extra comment to call out the use of http.DefaultClient and our default relay url

[decentralgabe]

general comment not sure if you already have this - but these two vectors should be covered by tests here https://did-dht.com/#test-vectors