Indy and Sov DIDs are not resolving -> Empty Pool Config

[dennisn00]

I set up the Resolver locally in a Docker container and ran curl -X GET http://localhost:8080/1.0/identifiers/did:indy:idunion:BDrEcHc8Tb4Lb2VyQZWEDE which is the example for Indy given in the Readme. This took over a minute and returned Resolve problem for did:indy:idunion:BDrEcHc8Tb4Lb2VyQZWEDE: A value must be provided for the 'pool' parameter

The same happened for the Sov DID example. I tried a few other DID Methods and they worked fine. I checked the logs of the driver-did-indy container and it seemed like the environment variable poolConfig was indeed not set. I saw that in the docker-compose.yml, the poolConfig Environment variable seems to be overwritten with an empty/undefined value. I removed all those lines as shown below, and restarted the containers.

driver-did-indy:
    image: universalresolver/driver-did-indy:latest  
    #environment:
    #  uniresolver_driver_did_indy_libIndyPath: ${uniresolver_driver_did_indy_libIndyPath}  
    #  uniresolver_driver_did_indy_poolConfigs: ${uniresolver_driver_did_indy_poolConfigs}  
    #  uniresolver_driver_did_indy_poolVersions: ${uniresolver_driver_did_indy_poolVersions}  
    #  uniresolver_driver_did_indy_walletNames: ${uniresolver_driver_did_indy_walletNames}  
    #  uniresolver_driver_did_indy_submitterDidSeeds: ${uniresolver_driver_did_indy_submitterDidSeeds}  
    ports:  
      - "8128:8080"  

This time, the poolConfig was indeed set to the value given in the Driver's Dockerfile. I ran the same curl request and got a Driver: No resolve result for did:indy:idunion:BDrEcHc8Tb4Lb2VyQZWEDE. I tried the same DID on https://dev.uniresolver.io/ and received the same result, so I believe this DID might not exist anymore. I then took the first DID I could find in the Indy Tx Explorer, did:indy:idunion:BNrX6yZzHkKbBGv5aX6PR4, and it successfully resolved on both, my local instance and https://dev.uniresolver.io/.

I would suggest to remove the lines from docker-compose.yml as shown above unless there is any reason to keep them and update the Readme with a working did:indy: example.

[dennisn00]

Another solution would be to include the values for the environment variables in .env. I am not sure whether this would have any advantages, but it seems like this is how it is solved for the Sov Driver

[peacekeeper]

Hello, thanks for your detailed report!

You're right that entries were missing in .env, I just added them in https://github.com/decentralized-identity/universal-resolver/commit/c690f14f4a40ddd9533a40469dde214df4b7b4cd

I also just updated the example in the README in https://github.com/decentralized-identity/universal-resolver/commit/774106829b2032977357aaa1103cd53d9c99f229.

With regard to the sovrin pool, we will investigate this separately, see also my comment in https://github.com/decentralized-identity/uni-resolver-driver-did-indy/issues/3.

[peacekeeper]

@dennisn00 could you try again if it works now and if this issue is resolved?

[dennisn00]

Thanks for you response @peacekeeper. I tested with the sov and indy DIDs provided in the ReadMe. In both cases I got a Error Cannot create Pool Config 'staging'. I removed the staging/sovrin:staging entries in the .env for indy and sov and now both examples are resolving. Both are still taking 10 to 60 seconds for resolving (however, subsequent requests to the same DID method but with a different DID are a lot faster). From the logs it seems like all wallets and all Pools are opened on the first request. Is that intentional?

[peacekeeper]

I removed the staging/sovrin:staging entries in the .env for indy and sov

Hi, I just renamed "staging" to "test" in .env, I think this should work: https://github.com/decentralized-identity/universal-resolver/commit/4e554e567f3512817d47b9cbcc874272aee51058

From the logs it seems like all wallets and all Pools are opened on the first request. Is that intentional?

Yes that's how we implemented it for now. Perhaps it would make more sense to open the wallets and pools only for a network once it's requests, or maybe all wallets and pools should be opened when the driver starts (before the first request). Or maybe they could all be opened simultaneously in parallel threads, not sure. There's definitely room for improvement.

[dennisn00]

Yes, it seems to work now. Maybe I will have some time in the next days to try to speed up the wallet and pool opening.

[peacekeeper]

try to speed up the wallet and pool opening

That would be very welcome of course. This part of the code is mostly in another repo: https://github.com/danubetech/libindy-common-java

[dennisn00]

Opening Indy connections is now done in parallel and on startup, not on the first resolve request