Closed TimoGlastra closed 1 year ago
For storage issue see https://github.com/hyperledger/aries-framework-javascript/issues/1164
Initially I thought on make these anoncreds-rs-based services part of a package called @aries-framework/anoncreds (especially considering that th NPM package is called simply 'anoncreds'). However, as this package name is taken for the generic AnonCreds interfaces, I guess it should be called @aries-framework/anoncreds-rs
and the services would be called AnonCredsRsHolderService
, AnonCredsRsIssuerService
, etc. Are you OK with this naming or do you think it could it become a bit confusing for developers non used to work with Rust libraries?
It would be nice if we can use AnonCreds without Askar by just pluging in a different storage service
I think this is a must. Let's get #1164 implemented soon!
I think AnonCreds RS is now 'the name', so it's fine by me. Indeed the general anoncreds is taken for the non-implementation specific logic.
It's still private so if you have suggestions and would like to use anoncreds thats also possible.
On the records and making it agnostic of aries, i would like to pick this up next sprint, as it's becoming a blocker for both the anoncreds rs impl and the indy->askar migration script
hard part about this is what to do with storage. If we want to keep the storage aligned with indy-sdk (and allow for migration from indy-sdk to askar later on) we need to keep the storage exactly as is with indy so we can migrate on an encrypted database. Problem with this is that we need to make the AnonCreds RS implementation of the Issuer / Holder / Verifier directly based on Aries Askar instead of the Storage Service. It would be nice if we can use AnonCreds without Askar by just pluging in a different storage service