base64url encoding is used in a few places e.g.

it might be worth specifying whether the encoded urls should include padding or not especially since JOSE expects all base64url encoding to include no padding:

from section 2 of the JWS spec:

had to accommodate for this in dart

context: I'm in the middle of implementing did:dht in dart.

Is there any rationale behind _did.TLD storing all the relationships? parsing a TXT record that into a DID Document could be O(n) if each _kN_did. had a rel (relationships) property e.g. rel=auth,asm vs. having to look up the relationships in the root entry.

          Possible to add length validation for these 3 fields?

Originally posted by @andresuribe87 in #21 (comment)

Also, helper methods when generating these structs

If we see the same DID multiple times with different data (higher seq numbers) we should be able to store and query multiple versions of the same record.

Can be an optional did creation parameter similar to how this works for did:key.

If there is ever a need for another version of the spec, then it would be useful for users to differentiate between them.

DKIMs and SPF do this. See https://www.cloudflare.com/learning/dns/dns-records/dns-dkim-record/ and https://www.cloudflare.com/learning/dns/dns-records/dns-spf-record/

For DHT, I would suggest adding it as an additional property in the _did. TXT record. The first example in https://did-dht.com/#dids-as-dns-records would become the following:

v=1;vm=k0,k1,k2;auth=k0;asm=k1;inv=k2;del=k2;srv=s0,s1,s2

Show how to represent deactivated keys / keys no longer in use, but keys that were once in use.

Produce log files and log to std out, optionally both

JsonWebKey is replacing JsonWebKey2020.

Is there a specific reason as to why the root record's RData delimits fields using ; but _kN and _sN uses ,? i think we should use ; to delimit fields so that we can use , for multiple values for a given field.

If not, there are typos here:

• _s0._did.'s RData value should be t=LinkedDomains,uri=foo.com,… not t=LinkedDomains;uri=foo.com;…
• _s1._did has the same issue

For secp256k1 specifically, given that k is is the base64URL [RFC4648] representation of the public key it might be helpful to specify whether k is expected to be the compressed, uncompressed, or either and check for both. a compressed EC key can be inflated. JWK expects both x and y to be present for kty: EC

After the spec is a bit further along, related to #11 #10

I suggest to update the test vectors so that:

• Did documents have the @context property.
• When verification relationships reference an existing verification method, use a URL that starts with a did URL.

If that makes sense, the resulting vectors are below.

Vector 1

{
  "@context": [
    "https://www.w3.org/ns/did/v1"
  ],
  "id": "did:dht:cyuoqaf7itop8ohww4yn5ojg13qaq83r9zihgqntc5i9zwrfdfoo",
  "verificationMethod": [
    {
      "id": "did:dht:cyuoqaf7itop8ohww4yn5ojg13qaq83r9zihgqntc5i9zwrfdfoo#0",
      "type": "JsonWebKey",
      "controller": "did:dht:cyuoqaf7itop8ohww4yn5ojg13qaq83r9zihgqntc5i9zwrfdfoo",
      "publicKeyJwk": {
        "kty": "OKP",
        "crv": "Ed25519",
        "x": "YCcHYL2sYNPDlKaALcEmll2HHyT968M4UWbr-9CFGWE",
        "alg": "EdDSA",
        "kid": "0"
      }
    }
  ],
  "authentication": [
    "did:dht:cyuoqaf7itop8ohww4yn5ojg13qaq83r9zihgqntc5i9zwrfdfoo#0"
  ],
  "assertionMethod": [
    "did:dht:cyuoqaf7itop8ohww4yn5ojg13qaq83r9zihgqntc5i9zwrfdfoo#0"
  ],
  "capabilityInvocation": [
    "did:dht:cyuoqaf7itop8ohww4yn5ojg13qaq83r9zihgqntc5i9zwrfdfoo#0"
  ],
  "capabilityDelegation": [
    "did:dht:cyuoqaf7itop8ohww4yn5ojg13qaq83r9zihgqntc5i9zwrfdfoo#0"
  ]
}

Vector 2

{
  "@context": [
    "https://www.w3.org/ns/did/v1"
  ],
  "id": "did:dht:cyuoqaf7itop8ohww4yn5ojg13qaq83r9zihgqntc5i9zwrfdfoo",
  "verificationMethod": [
    {
      "id": "did:dht:cyuoqaf7itop8ohww4yn5ojg13qaq83r9zihgqntc5i9zwrfdfoo#0",
      "type": "JsonWebKey",
      "controller": "did:dht:cyuoqaf7itop8ohww4yn5ojg13qaq83r9zihgqntc5i9zwrfdfoo",
      "publicKeyJwk": {
        "kty": "OKP",
        "crv": "Ed25519",
        "x": "YCcHYL2sYNPDlKaALcEmll2HHyT968M4UWbr-9CFGWE",
        "alg": "EdDSA",
        "kid": "0"
      }
    },
    {
      "id": "did:dht:cyuoqaf7itop8ohww4yn5ojg13qaq83r9zihgqntc5i9zwrfdfoo#0GkvkdCGu3DL7Mkv0W1DhTMCBT9-z0CkFqZoJQtw7vw",
      "type": "JsonWebKey",
      "controller": "",
      "publicKeyJwk": {
        "kty": "EC",
        "crv": "secp256k1",
        "x": "1_o0IKHGNamet8-3VYNUTiKlhVK-LilcKrhJSPHSNP0",
        "y": "qzU8qqh0wKB6JC_9HCu8pHE-ZPkDpw4AdJ-MsV2InVY",
        "alg": "ES256K",
        "kid": "0GkvkdCGu3DL7Mkv0W1DhTMCBT9-z0CkFqZoJQtw7vw"
      }
    }
  ],
  "authentication": [
    "did:dht:cyuoqaf7itop8ohww4yn5ojg13qaq83r9zihgqntc5i9zwrfdfoo#0"
  ],
  "assertionMethod": [
    "did:dht:cyuoqaf7itop8ohww4yn5ojg13qaq83r9zihgqntc5i9zwrfdfoo#0",
    "did:dht:cyuoqaf7itop8ohww4yn5ojg13qaq83r9zihgqntc5i9zwrfdfoo#0GkvkdCGu3DL7Mkv0W1DhTMCBT9-z0CkFqZoJQtw7vw"
  ],
  "capabilityInvocation": [
    "did:dht:cyuoqaf7itop8ohww4yn5ojg13qaq83r9zihgqntc5i9zwrfdfoo#0",
    "did:dht:cyuoqaf7itop8ohww4yn5ojg13qaq83r9zihgqntc5i9zwrfdfoo#0GkvkdCGu3DL7Mkv0W1DhTMCBT9-z0CkFqZoJQtw7vw"
  ],
  "capabilityDelegation": [
    "did:dht:cyuoqaf7itop8ohww4yn5ojg13qaq83r9zihgqntc5i9zwrfdfoo#0"
  ],
  "service": [
    {
      "id": "did:dht:cyuoqaf7itop8ohww4yn5ojg13qaq83r9zihgqntc5i9zwrfdfoo#service-1",
      "type": "TestService",
      "serviceEndpoint": "https://test-service.com"
    }
  ]
}

A day? A month? A year?
Are there different options for different difficulties?

Could use unix time stamp for version id - client would need to be aware of republishing
Should be configurable by the gateway?

The spec currently reads

Construct a signed BEP44 put message with the v value as a bencoded DNS packet from the prior step.

Since the encoded size of v is capped at 1000, then it can be desirable to compress the DNS packet before calculating the beconding.

Aim for higher test coverage (80%) and distinguish between tests that require the network and those that do not.

related to #16

Either DocumentDB (MongoDB) or Aurora (PostgreSQL)

as per the spec, related to #10

• index
• pkarr api
• did api

DNS servers have limits. If the goal is to eventually support DNS, then this is important to have those limits mind. The DHT spec could have affordances on the algorithm for splitting data when a record is over 255 chars.

Write sec & privacy considerations section!

Dependence on mainline, post quantum risk, public records, etc.

Allow an additional record for a type index. Create a type index registry. Create indexes for types & queryability.

          This call may simply return a subset of all the results. Might need to do some cursor tracking

Originally posted by @andresuribe87 in #21 (comment)

To specify

• discovery mechanism
• difficulty
• hash source
• maybe more?

Currently, in order to independently verify that a DID Document was indeed produced and published by the controller of a did:dht, implementers have to resolve using pkarr relays as noted here:

Are there any technical reasons preventing us from being able to return the signature from GET /dids/:did? It would be nice to leverage the simplicity of resolving a did:dht using the gateway endpoint while also being able to independently verify that the resolved document hasn't been tampered with.

This would also be beneficial for historical resolution.

Personally feel like providing a means to perform an integrity check is important as it prevents folks from falling victim to a bad actor gateway

is the primary reason behind using DNS packets as the wire protocol because did:dht leverages pkarr relays?

I did notice the gateway /did/:did endpoint which is nice, but i wanted sig verification. found it a bit strange that i was making HTTP requests to get back a DNS packet.

I had to handroll DNS packet decoding because there wasn't a third party lib available to do so.

Not complaining since the work is done, and I imagine most languages to have dns packet decoding libs. Just more-so wondering if there's specific reasons for having selected it. If compression is the sole reason, is there a comparison available between DNS packet sizes for this usecase vs. say CBOR?

I would think KRPC protocol mentioned in bep005 would even make more sense because thats the protocol used to communicate with Mainline DHT nodes over UDP. This way relays wouldn't have to transform DNS records into KRPC payloads.

Anyway, wondering if it'd be helpful to include rationale behind using DNS packets or simply defer to rationale behind using pkarr.

We have a predetermined set of types here: https://tbd54566975.github.io/did-dht-method/#type-index is an example of such. I generally struggle with pre-determined finite sets for a decentralized ecosystem, as it imposes certain restrictions around expression, but alas I do not have a better solution to solve the indexing problem (yet).

I suggest adding an index type 8 or 0, to express that "I want to be discoverable, but not express my type": for various reasons. I may index 0 or 8 because I do not find the typings available that will satisfy my category.

"Indexing is optional. You can just omit it!" -- This doesn't allow one to delineate between those that just didn't include the indexing vs. those that specifically do not want to categorize themselves against the available index categories. So, no, this doesn't accomplish the same.

yeah in that case i think _sN._did. should absolutely use ; to separate entities vs. , as you have right now because values like uri can have multiple values as noted here.

On that note, did did:dht make an explicit decision to not support serviceEndpoint being an object? DWNs require this which you can see here

Originally posted by @mistermoe in #83 (comment)

Add test vectors for different DID Documents and encoding results.

Add a universal resolver driver for the did:dht method

If the same DID is published to multiple nodes, there is a chance our records will be rejected with older seq numbers. We should be able to detect this and stop re-publishing until we get a later sequence number for these records.

Support pagination!

Currently there's no way to specify a controller for a Verification Method other than the DID itself.

Can consider adding a syntax such as c=... to VMs

No need to publish to the internet, should work without remote network calls

Consider using jaeger for monitoring and tracing, producing metrics

E.g. DWNs need properties "sig" and "enc" inside of a service such as:

{
  "id": "#dwn",
  "type": "DecentralizedWebNode",
  "serviceEndpoint": ["https://dwn.tbddev.org/dwn0", "https://dwn.tbddev.org/dwn1"],
  "sig": ['#1'],
  "enc": ['#2']
}

We will include a section in the registry to note supported additional properties.

Able to configure retention and check retention proofs. https://did-dht.com/#retained-did-set

After multiple reads, I am not sure what problem the gateways are aiming to solve. I think that the problem is "BEP044 establishes that blobs stored in Mainline DHT may expire. This implies that the data backing the DID Document of a did:dht may expire."

And I think a gateway solves it by "Gateways do this work on behalf of DID Controllers, by charging a fee for republishing for a certain amount of time."

Is the above correct?

It would be very useful to readers to understand the motivation behind it.

Some questions below that caused confusion:

• Where is republishing hasn't been defined?
• What does it mean to "act as a gateway"? The definition of "Gateway" is circular.
• What does "retention" mean? (I think it means republishing).
• Why does the fee need to be timelocked?
• Why does the fee need to be in BTC?
• What happens when the Gateway doesn't re-publish?

Could use a library such as this https://github.com/hashicorp/memberlist to facilitate gossiping records between DHT nodes

Consider an additional DNS property for an aka field in the DID Document. This could be a user-hashed name.

The user could 'mine' for a hash that extends their did (e.g. did:dht:example becomes did:dht:example:name). To add this property to their DID document they would find an associated nonce value that hashes to did:dht:example:name and include it in the DNS packet record.

as per the spec https://tbd54566975.github.io/did-dht-method/#gateway-api

https://www.openapis.org/

If a DID is fetched multiple times within a given time window (e.g. 5 min) return the cached DID

Upgradable did:key and did:jwk with did:dht

Leveraging existing work:

• https://datatracker.ietf.org/doc/html/draft-mayrhofer-did-dns-05
• https://danubetech.github.io/did-method-dns/

Potential to publish a draft at the IETF to standardize our method of encoding DID Documents as DNS Resource Records. Could align with did:dns.

Describe the bug
We use 404s for unimplemented features where we should probably be using 501s (hashing for POW spam prevention), and are using 404s on no results when we should probably return a 200 with an empty response (searching for types, probably should be an empty array).

Things like republishing optimization, handling scale, integrating with DNS, etc.

          We'll want to modify this slightly to:

1. Use the different prefix for a did:dht Ed25519 key (that just makes sure we bind the Ed25519 key to a resolution network -- did:dht). We can register the Multikey prefix pretty quickly to do that.
2. did:key can take an argument and you can get your keys back as either Multikey or JsonWebKey, so no need to be specific here. JsonWebKey2020 is definitely out of date and is not going to survive standardization. We should be using JsonWebKey anywhere that we were using JsonWebKey2020 before.
3. If you wanted the did:key to be encoded in z-base-32, we could do that... though I don't think there's a Multibase encoding for that yet? If there is interest there, we could look into that (this is one of the reasons Multibase exists -- because the base-encoding you use is largely driven by what the protocols are optimized for -- humans, ASCII, glyph compression, or some combination of the previous).

None of the feedback above is blocking for now, but wanted to just make sure it was registered as feedback so we can adjust going forward.

Originally posted by @msporny in #56 (comment)