Support for retention challenges

[decentralgabe]

Fix #74

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 52.63158% with 9 lines in your changes are missing coverage. Please review.

Project coverage is 51.70%. Comparing base (14c8f76) to head (f236b7e).

Files	Patch %	Lines
impl/internal/did/pow.go	52.63%	6 Missing and 3 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #219      +/-   ##
==========================================
+ Coverage   51.62%   51.70%   +0.07%     
==========================================
  Files          32       32              
  Lines        2774     2791      +17     
==========================================
+ Hits         1432     1443      +11     
- Misses       1199     1203       +4     
- Partials      143      145       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[decentralgabe]

ready for preliminary review. I still have to add a few more pieces of text around

• additional requests refersh the timeout
• new api for finding other gateways
• returning status for full

[KendallWeihe]

nice, I think it's good to avoid conflating the usage of proof across the two use cases:

1. cryptographic provenance using private keys
2. evidence of expending energy (AKA PoW)

yeah I think we'd be wise to consolidate our usage of that word for (1) and not for (2)

also sets us up if we ever introduces a spam preventing mechanism other-than PoW

[KendallWeihe]

why wouldn't an invalid retention solution be a 400?

[decentralgabe]

agree, updating

[decentralgabe]

Ready for final review! I will handle exposing other gateways in a follow-up

[frankhinek]

@decentralgabe in examining the currently registered properties returned in didResolutionMetadata and didDocumentMetadata, it seems like perhaps expiry would be more appropriately included in DID Document Metadata.

Perhaps types should be as well?

Rationale:

The DID Core spec states the following about DID Resolution Metadata:

A metadata structure consisting of values relating to the results of the DID resolution process which typically changes between invocations of the resolve and resolveRepresentation functions, as it represents data about the resolution process itself.

and the following about DID Document Metadata:

This structure contains metadata about the DID document contained in the didDocument property. This metadata typically does not change between invocations of the resolve and resolveRepresentation functions unless the DID document changes, as it represents metadata about the DID document.

Neither types nor expiry are data "about the resolution process itself." IMHO they would be more appropriately classified as data about the DID & its DID Document.

Additionally, these values "typically [do] not change between invocations of the resolve functions unless the DID document changes." In other words, a DID controller would have to submit a new request to a Gateway in order to change the types property or to submit a new Retention Solution to extend the expiry.

[decentralgabe]

@frankhinek thanks this is a good callout and I agree with your reasoning, I will update this PR

[decentralgabe]

• updated to move expiry and types to DID Doc Metadata
• updated language on creating a DID to be clearer for the id key
• added a hash_source property and corresponding section in the registry

[decentralgabe]

merging for agility - feel free to leave additional comments if you have them I can address in a follow-up