Create CheqdSdkDidResolver in AFJ

[TimoGlastra]

Create a CheqdSdkDidResolver that implements the DidResolver interface from AFJ.

Code Example

import { Agent } from '@aries-framework/core` 
import { agentDependencies } from '@aries-framework/node'

const agent = new Agent({
  config: {},
  dependencies: agentDependencies, 
  modules: {
    dids: new DidsModule({
       resolvers: [CheqdSdkDidResolver]
    })
  }
)

await agent.initialize()
await agent.dids.resolve('did:cheqd:mainnet:xxx')

Todo

• Create CheqdSdkDidResolver class and export it from a custom cheqd package
• Make sure it works in React Native!

Questions

• Should all cheqd sdk related items be added to a single package (something @aries-framework/cheqd-sdk) or should we group it by feature (something like @aries-framework/cheqd-sdk-did-provider that exports the did resolver + registrar)?
  • Advantage of the first one is less packages, advantage of the second one means you're not adding unneeded dependecnies (e.g. we're also going to implement the CheqdSdkAnonCredsResource, which will depend on the anoncreds package for afj)
• How do we configure the did resolver with the right rpc urls? We have configuration for modules, but as this is added as a class (not instance) to the DidsModule.resolvers class. I see a few solutions:
  • Add a cheqd module that you can provide the config to that the cheqd sdk did resolver will pick up under the hood (it will inject the CheqdSdkModuleConfig -- or whatever it will be called) and extract the config from it.
  • Instaed of providing the class to the resolvers array, provide an instance to the resolvers array. Instead of using constuctor dependency injection in the resolver service, we can inject the needed dependencies from the agentContext every time the resolve method on the resolver is called (I think this has my preference).

Configuration options:

import { Agent } from '@aries-framework/core` 
import { agentDependencies } from '@aries-framework/node'

const agent = new Agent({
  config: {},
  dependencies: agentDependencies, 
  modules: {
    dids: new DidsModule({
       resolvers: [CheqdSdkDidResolver]
    }),
    // Doesn't expose a public api and thus won't be exposed on the agent modules (already possible)
    _cheqd: new CheqdSdkModule({
        resolver: {
           rpcUrls: ['https://rpc.cheqd.net'], 
         }
    })
  }
)

await agent.initialize()
await agent.dids.resolve('did:cheqd:mainnet:xxx')

import { Agent } from '@aries-framework/core` 
import { agentDependencies } from '@aries-framework/node'

const cheqdSdkResolver = new CheqdSdkDidResolver({
  rpcUrls: ['https://rpc.cheqd.net']
})

const agent = new Agent({
  config: {},
  dependencies: agentDependencies, 
  modules: {
    dids: new DidsModule({
       resolvers: [cheqdSdkResolver]
    })
  }
)

await agent.initialize()
await agent.dids.resolve('did:cheqd:mainnet:xxx')

[genaris]

• Should all cheqd sdk related items be added to a single package (something @aries-framework/cheqd-sdk) or should we group it by feature (something like @aries-framework/cheqd-sdk-did-provider that exports the did resolver + registrar)?

Apart from resolver and registrar, what are the other cheqd-specific packages you can foresee? I think that at least the resolver package should be separated from the rest, as I imagine it will be the one imported by most projects . BTW I'm curious about the 'cheqd-sdk' prefix on these packages: wouldn't it suffice with 'cheqd-*'?

• How do we configure the did resolver with the right rpc urls? We have configuration for modules, but as this is added as a class (not instance) to the DidsModule.resolvers class. I see a few solutions:

I think the second approach is a lot better. Several resolvers would need to be parameterized and in my opinion passing the instance will be easier for most developers. Probably there are more elegant solutions by using dependency injection magic as well, but not everyone is familiarized with this concept and would complicate the things a bit more.

[genaris]

Not sure about React Native but this has been implemented in #1334