veramolabs / did-eth

evolution of did:ethr
Apache License 2.0
14 stars 8 forks source link

Example of diamonds for DID resolution #22

Open Hmac512 opened 1 year ago

Hmac512 commented 1 year ago

This is a simple stupid example of how to set up replaceable resolvers with the Diamond pattern.

Screenshot 2023-01-25 at 6 48 00 PM

The tests were written really fucking quickly, and the code for the tests isn't pretty. Might be a good exercise for someone to go through and write full coverage tests.

There is nothing to do with DIDs in this implementation, it’s more like a NFT contract. All in due time.

Hmac512 commented 1 year ago

https://github.com/veramolabs/did-eth/issues/8

Hmac512 commented 1 year ago

The idea I am getting at is we can actually give each resolver direct access to the document storage to create/update DID Documents.

The following code is where the magic happens:

https://github.com/Hmac512/did-eth/blob/42cfdfa1d8101349e590deb7b7d46fd451b1695c/diamonds/contracts/implementations/documents/didETH.sol#L39

https://github.com/Hmac512/did-eth/blob/42cfdfa1d8101349e590deb7b7d46fd451b1695c/diamonds/contracts/libraries/DocumentStorage.sol#L27

In this code the resolver itself is handling the idProxyAddress, which determines the pointer for the document map.

We can utilize the pattern here instead:

https://github.com/aavegotchi/aavegotchi-contracts/blob/a9fbff896f7c0cb701f422fe0fb891d553262652/contracts/shared/libraries/LibMeta.sol#L26

So the entry point to each resolver is through a function in DID.sol. There the address for the pointer is determined based on the intended resolver.

Then our document storage can do something like this to get the pointer, and send it to the resolver.