• Principles of a Good (Human-Focused) DID Method
• Conclusions
• PKARR
• Clients
• Relays
• Republishers
• DID method

So new DID method is here !!!

§Principles of a Good (Human-Focused) DID Method

Sufficiently decentralized (or decentralizable). This means fulfilling properties necessary for decentralization: trustlessness, no single points of failure, censorship resistance, etc. Decentralizable, meaning the design leads to decentralization even if the current conditions are not decentralized (e.g., Bitcoin is decentralizable even if only one node were running)

• Able to scale to billions (world scale) while maintaining a low cost per transaction (< $0.50).

• Robust feature set including create, read, update, deactivate, recovery, multisig, service endpoints, multiple key types/cryptographic agility, key delegation, etc.

• Able to present a canonical DID state with point-in-time resolution.

• Able to be implemented across multiple permissionless anchor systems. This allows for a diversity of implementations without mandating interoperability between chains, which could be complex and hinder other principles.

• Limited complexity. Complexity leads to bugs; bugs lead to loss of trust. Less complex = higher diversity of implementations = more decentralization.

• Memorable and unique names. Human readability for additional utility.

• Flexible resolution (on/offline) and global discovery. This enables the broadest possible reach and utility of the DIDs.

§Conclusions

• After analyzing several common DID methods (web, ethr, key, sidetree, peer, keri, ens, cheqd) we realize that to fulfill the principles above, one needs to use either…

• A ledger-less or a multi-ledger system like KERI

• An L1 system like ETH or XTZ

• A sidechain or L2 system like a BTC spacechain We acknowledge that none of the existing methods fulfill all principles today. The closest are the sidetree, keri, and eth/ens based methods.

So as a result TBD folks create a DID method on top of L1 Network used by BitTorent

Repo

§PKARR

It is really depends on Pkarr project that Use a DHT as a storage relay

The simplest possible streamlined integration between the Domain Name System and peer-to-peer overlay networks, enabling self-issued public keys to function as sovereign, publicly addressable domains. This system would be accessible to anyone capable of maintaining a private key.

Where we are going, this https://o4dksfbqk85ogzdb5osziw6befigbuxmuxkuxq8434q89uj56uyy resolves everywhere!

To publish resource records for your key, sign a small encoded DNS packet (<= 1000 bytes) and publish it on the DHT (through a relay if necessary). To resolve some key’s resources, applications query the DHT directly, or through a relay, and verify the signature themselves. Existing applications unaware of Pkarr make normal DNS Queries over HTTPS (DoH) to Pkarr servers. Clients and Pkarr servers cache records extensively and minimize DHT traffic as much as possible for improved scalability. The DHT drops records after a few hours, so users, their friends, or service providers should periodically republish their records to the DHT. Also Pkarr servers could republish records recently requested, to keep popular records alive too.

§Clients

Pkarr enabled applications. Native applications, can directly query and verify signed records from the DHT if they are not behind NAT. Otherwise, they will need to use a Pkarr server as a relay.

Browser web apps should try calling local Pkarr server at the default port 7527, if not accessible, they have to query a remote server instead. Eitherway, these apps should allow users to configure servers of their choice.

Clients with private keys are also capable of submitting signed records either to the DHT directly, or through Pkarr server, to update user’s records when needed.

Existing applications To support existing applications totally oblivious of Pkarr, users will have to (manually or programatically) edit their OS DNS servers to add one or more Pkarr servers to proxy DHT records as DNS over HTTPS.

§Relays

Pkarr relays are optional but they:

Trustlessly relay requests from Web apps and applications behind NAT or firewall, to the DHT. Offer a DoH interface for applications that aren’t aware of Pkarr at all, so they can resolve something like https:// as usual. Relays are very light and cheap to operate, that they can easily run altruistically, but private, and paid relays are possible too.

§Republishers

Services and hosting providers mentioned in Resource Records of a user, are incentivized to republish these records and keep them alive on the DHT, for the same reasons they are incentivized to gain that user in the first place.

§DID method

Spec could be found https://did-dht.com/ So as I mention it is PARR related and use a DHT that quite limmited in size 1k of data - main part of spec is mapping a record to a full scale and verbouse did document. One more quite interesting invention is a DID gateways or smart gateway nodes thats work as republishers

See spec section

Gateways serve as specialized nodes within the network, providing a range of DID-centric functionalities that extend beyond the capabilities of a standard Mainline DHT node. This section elaborates on these unique features, outlines the operational prerequisites for managing a gateway, and discusses various other facets, including the optional integration of these gateways into a registry system.

TBD is still working on making gateways discovery and aware network.