This project has outstanding taste.<p>So few people appreciate why Bittorrent (Mainline) and DNS have been world-conquering successes while everything else (<i>cough</i> IPFS <i>cough</i>) struggles. Be stateless, be sessionless -- send only packets, allocate no state. Nothing else in the computing world scales the way the Mainline bootstrap nodes and DNS root servers do. Until recently the DNS root servers were just a handful of decent workstations at universities; Mainline's bootstrap nodes still are. None of the heavyweight cloudtech can match that kind of efficiency.<p>You should publish a spec for Pkarr -- the layer below did-dht -- first. Right now Pkarr is a software program/library, not a specification. I think this will help you simplify and articulate your work more clearly to people who aren't immersed in it. I think it will also be extremely useful to people who don't need the incredible complexity of w3c DIDs.<p>The choice to sign an entire <i>DNS packet</i> seems very strange and probably hasn't been through through properly.<p>Why use DNS packets? Presumably because you want to leverage the existing infrastrucure of recursive DNS resolvers. However <i>these resolvers do not preserve packets!</i>. If I send a query to my recursive resolver, and it makes a query to the authoritative server, it can (and almost always does) modify the resulting packet from the authoritative before returning a reply to me. The upshot here is: if you're signing packets, almost all recursive resolvers will destroy your signatures. This is why DNSSEC signs individual resource records instead of packets. I think that's what you want to be doing: sign an RR, not a packet. If you absolutely need to sign multiple RRs, you'll need to specify a canonical way to assemble the RRs (i.e. sort them).<p>I really think you want to sign an <i>RR</i> (which might include the hash of other RRs), not an <i>entire DNS packet</i>.<p>Lastly, please take this issue more seriously: <a href="https://github.com/TBD54566975/did-dht-method/issues/80#issue-2063225989">https://github.com/TBD54566975/did-dht-method/issues/80#issu...</a> the only response given was that "the DHT-DID [spec] uses Pkarr [a piece of software]" which makes no sense... specs depend on specs, not implementations. Then the issue derailed (as unthreaded discussions <i>always</i> do; github is why we can't have nice things) into some side tangent about KRPC and CBOR instead of answering the issue's question "why DNS?". Pretty sure the answer is "to leverage existing recursive resolver infrastructure" but you should state that clearly -- and then think through the consequences.