The Resolver<T> used within trustchain-http is currently wrapping another Resolver<T>, both implementing TrustchainResolver. As a result, trustchain_resolve() is called twice and verification methods from CAS keys are added multiple times. Two proposed revisions:
Revise the Resolver<T> in trustchain-http to wrap an ION DIDResolver not a TrustchainResolver
Include a check when adding verification methods that a given verification method is not already present
Since including an IPFSClient within Resolver<T>, it will no longer be possible to call verify() on mobile as the IPFSClient cannot be used. One solution is to use the type state pattern as for the IONVerifier and use a trustchain-http endpoint for resolution within the mobile. A more complete refactor removing the Resolver<T> completely from the API in favour of generics that impl TrustchainResolver but this may be better considered in more detail in a further issue.
Resolver<T>used withintrustchain-httpis currently wrapping anotherResolver<T>, both implementingTrustchainResolver. As a result,trustchain_resolve()is called twice and verification methods from CAS keys are added multiple times. Two proposed revisions:Resolver<T>intrustchain-httpto wrap an IONDIDResolvernot aTrustchainResolverIPFSClientwithinResolver<T>, it will no longer be possible to callverify()on mobile as theIPFSClientcannot be used. One solution is to use the type state pattern as for theIONVerifierand use atrustchain-httpendpoint for resolution within the mobile. A more complete refactor removing theResolver<T>completely from the API in favour of generics thatimpl TrustchainResolverbut this may be better considered in more detail in a further issue.