feat: add initial askar package

[genaris]

Initial implementation of Aries Askar module for AFJ, including interfaces for Storage and Wallet.

The module registers a Storage and a Wallet instance automatically when it registers itself on the dependency manager. If there is already a module that has registered a Storage or a Wallet, it throws an error.

Features already implemented:

• Wallet creation, deletion and key rotation using both SQLite and PosgreSQL backends
• Record Get/Update/Save including WQL queries
• DIDComm V1 packing (basic Connection + BasicMessage exchange flow tested briefly in askar-aries-e2e-wallet-subject.test.ts)
• Key creation, sign and verify, using custom SigningProvider if key type is not supported by Askar (however, once feat(js): add Bls12381G1G2 to supported key algos askar#85 is merged I think all current key types are covered natively).

Features missing to match 1:1 with Indy SDK:

• Wallet Import/Export: not currently provided by Askar, so it should be developed (either in Askar as suggested by Add support for export and import that is functionally equivalent to Indy SDK askar#82, or in AFJ)

There are several FIXMEs and TODOs in the code. Most of them are related to either fixes or new features to be added to aries-askar JS Wrapper, so this module will need to be adapted accordingly. Unfortunately, a problem related to JavaScript GC/memory issues (openwallet-foundation/askar#76) prevents E2E tests using Askar wallets to properly run in CI, so they are currently skipped.

Some more TODOs for a further PR:

• Update README con information about module contents and usage
• Improve modeling of JweEnvelope and support/test different scenarios
• Add more advanced tests

[codecov-commenter]

Codecov Report

Merging #1211 (fd0dff8) into main (7f65ba9) will decrease coverage by 0.51%.
The diff coverage is 67.74%.

@@            Coverage Diff             @@
##             main    #1211      +/-   ##
==========================================
- Coverage   87.10%   86.59%   -0.51%     
==========================================
  Files         776      788      +12     
  Lines       18463    18957     +494     
  Branches     3133     3248     +115     
==========================================
+ Hits        16082    16416     +334     
- Misses       2374     2534     +160     
  Partials        7        7              

Impacted Files	Coverage Δ
packages/core/src/types.ts	100.00% <ø> (ø)
packages/node/src/NodeFileSystem.ts	35.13% <0.00%> (-2.01%)	⬇️
packages/askar/src/AskarModule.ts	22.22% <22.22%> (ø)
packages/askar/src/utils/askarWalletConfig.ts	42.50% <42.50%> (ø)
packages/askar/src/wallet/AskarWallet.ts	60.78% <60.78%> (ø)
packages/askar/src/utils/assertAskarWallet.ts	66.66% <66.66%> (ø)
packages/askar/src/storage/AskarStorageService.ts	77.50% <77.50%> (ø)
packages/askar/src/storage/utils.ts	97.87% <97.87%> (ø)
packages/askar/src/storage/index.ts	100.00% <100.00%> (ø)
packages/askar/src/utils/askarError.ts	100.00% <100.00%> (ø)
... and 6 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[genaris]

For some reason, ESLint is failing in packages/askar/src/wallet/AskarWallet.ts but I don't find a way to fix it:

Error: 37:1 error There should be no empty line within import group import/order

Any advice will be welcome!

[TimoGlastra]

This is great @genaris. Overall looks good and very clean. Like the extensive tests.

We should still look at how we're going to register the storage and wallet. Is the AskarModule going to register them, or do we need to provide them to the storage and wallet modules? Something to solve in a later PR ofc.

[TimoGlastra]

It seems Askar also just returns not found if the record wasn't found:

        try:
            item = await self._session.handle.fetch(
                record_type, record_id, for_update=for_update
            )
        except AskarError as err:
            raise StorageError("Error when fetching storage record") from err
        if not item:
            raise StorageNotFoundError(f"Record not found: {record_type}/{record_id}")

Will it sometimes throw an error instead of not returning a record?

[genaris]

Not 100% sure but I'd say that it always sends the error.code Custom (100). Let's analyze on Askar side to see where the problem is.

[TimoGlastra]

Isn't this something we can fix in the wrapper? So the wrapper should jus allow a null pointer as return value? Maybe @blu3beri knows

[berendsliedrecht]

Yeah if that is the intended behaviour we can fix that in the wrapper.

[genaris]

I've added openwallet-foundation/askar#77 to follow this issue. I'm not absolutely sure that is a specific problem for JS, as a preliminar quick-debugging I've done showed me that the wrapper is getting an Error Code: 0 in those cases so it tries to create an EntryList from a null pointer (and that's why it shows that custom error).

[TimoGlastra]

Annoying we need to create the directory ourselves for Askar. I would like to use the file system as little as possible, oh wel...

[TimoGlastra]

Could you create tickets for the outstanding tasks so we have insights in what still needs to happen (and we can prioritize what is important for now)

[genaris]

We should still look at how we're going to register the storage and wallet. Is the AskarModule going to register them, or do we need to provide them to the storage and wallet modules? Something to solve in a later PR ofc.

Absolutely. I created #1235 to discuss how can we implement it.

[genaris]

Could you create tickets for the outstanding tasks so we have insights in what still needs to happen (and we can prioritize what is important for now)

Sure. I've created a few in AFJ and others in aries-askar. I think for this particular PR to be merged in a meaningful way we'll need two main things:

• Solve [JS wrapper] Performance issues when used intensively askar#76, as currently it is quite hard to get test suites to pass in CI: this GC overhead affects not only Askar tests but also others like the ones for BBS Signatures
• Have an initial release of @hyperledger/aries-askar-shared / @hyperledger/aries-askar-nodejs. Not absolutely mandatory but, as we are very close to release them, it would be nice to merge into main the module linked to the actual packages and not the test ones

Once we get this, I think we can adapt the module to the fixes in aries-askar and the Wallet API changes that will be introduced when Indy is removed from the Core.

[TimoGlastra]

👍 nice. We could probably improve this at some point by detecting the env and loading packages based on that. I think it could succeed in requireing the nodejs package even though we're in a RN env?

[genaris]

I'm not convinced about this way of importing it but I wanted to left it consistent with the way we are using other shared components. And it's nice that it attempts to make life easier to developers using the framework.. unless they import nodejs package when on react native environment 😮 . Would be nice to investigate if there is a reliable way to get the JS environment nowadays.

[TimoGlastra]

Agreed. Also not 100% convinced yet. I think it's just another thing the user needs to provide to the agent config, while we could just infer it. Maybe we only try to import it if it's not provided yet? This way it 'works' out of the box. but you can also manually configure it