Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: break out indy wallet, better indy handling #396

Merged

Conversation

TimoGlastra
Copy link
Contributor

Extracts part of the code in #360.

Main reasons for this are:

  • remove dependency on indy-sdk where it is not strictly required (mainly wallet interface is less indy-specific now)
  • make indy stuff more indy specific
  • other points below

I want to make a browser compatible wallet (already have a working one locally) so we can use the agent in the browser

Break out indy wallet

Fixes #330

It didn't make a lot of sense to me that the indy wallet was handling indy storage and ledger stuff. I think it belongs more in the ledger and storage services. This is also more in line with where we're headed with the shared components libraries

  • Rename LedgerService to IndyLedgerService. It's very indy focussed now.
  • move storage related methods to IndyStorageService
  • move ledger related methods to IndyLedgerService

Better indy message handling

Sometimes you would get very cryptic errors such as CommonInvalidParam without a stack trace or anything that would help you get a sense of what's erroring out. I've wrapped all indy calls with a try catch and added a new IndySdkError. This will take the indy error as input, but with very nice stack tracing so you know exactly where things went wrong, without losing information from the indy error

Signed-off-by: Timo Glastra <timo@animo.id>
Signed-off-by: Timo Glastra <timo@animo.id>
Signed-off-by: Timo Glastra <timo@animo.id>
Signed-off-by: Timo Glastra <timo@animo.id>
Signed-off-by: Timo Glastra <timo@animo.id>
Signed-off-by: Timo Glastra <timo@animo.id>
Signed-off-by: Timo Glastra <timo@animo.id>
@codecov-commenter
Copy link

codecov-commenter commented Jul 20, 2021

Codecov Report

Merging #396 (9578e11) into main (5f2d512) will decrease coverage by 0.33%.
The diff coverage is 73.86%.

Impacted file tree graph

@@            Coverage Diff             @@
##             main     #396      +/-   ##
==========================================
- Coverage   86.64%   86.30%   -0.34%     
==========================================
  Files         248      249       +1     
  Lines        5210     5256      +46     
  Branches      830      784      -46     
==========================================
+ Hits         4514     4536      +22     
- Misses        696      720      +24     
Impacted Files Coverage Δ
packages/core/src/agent/AgentConfig.ts 90.90% <ø> (-0.32%) ⬇️
...ges/core/src/agent/models/InboundMessageContext.ts 91.66% <ø> (ø)
packages/core/src/error/BaseError.ts 50.00% <ø> (ø)
.../core/src/modules/connections/ConnectionsModule.ts 74.02% <0.00%> (ø)
...modules/connections/repository/ConnectionRecord.ts 98.36% <ø> (ø)
...ckages/core/src/modules/routing/RecipientModule.ts 64.00% <0.00%> (ø)
.../src/modules/routing/repository/MediationRecord.ts 91.17% <ø> (ø)
packages/core/src/types.ts 100.00% <ø> (ø)
packages/core/src/utils/indyError.ts 100.00% <ø> (+7.14%) ⬆️
packages/core/src/error/IndySdkError.ts 40.00% <40.00%> (ø)
... and 21 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 5f2d512...9578e11. Read the comment docs.

Signed-off-by: Timo Glastra <timo@animo.id>
@@ -16,14 +17,6 @@ export class MessagePickupService {
this.messageRepository = messageRepository
}

public async batchPickup(inboundConnection: InboundConnection) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Was the batchPickup message removed intentionally?

Copy link
Contributor Author

@TimoGlastra TimoGlastra Jul 21, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It wasn't used because the RecipientModule directly creates a batch pickup message. I choose to remove this method, but it's probably better to use the service method instead. Will update

public async getAll(recordClass: BaseRecordConstructor<T>): Promise<T[]> {
const recordIterator = await this.wallet.search(recordClass.type, {}, IndyStorageService.DEFAULT_QUERY_OPTIONS)
const recordIterator = this.search(recordClass.type, {}, IndyStorageService.DEFAULT_QUERY_OPTIONS)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the search not async any more? Are we missing an await?

Suggested change
const recordIterator = this.search(recordClass.type, {}, IndyStorageService.DEFAULT_QUERY_OPTIONS)
const recordIterator = await this.search(recordClass.type, {}, IndyStorageService.DEFAULT_QUERY_OPTIONS)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this.search returns a generator, which we can use as an async iterator. So the this.search call itself is not async

Copy link
Contributor

@berendsliedrecht berendsliedrecht left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some minor things. Nothing about the functionality but more I think some overlooked things.

Great changes! Love the errors :-)

packages/core/src/agent/Agent.ts Outdated Show resolved Hide resolved
packages/core/src/agent/Agent.ts Outdated Show resolved Hide resolved
packages/core/src/agent/EnvelopeService.ts Outdated Show resolved Hide resolved
await this.create(walletConfig, walletCredentials)
await this.open(walletConfig, walletCredentials)
await this.create(walletConfig)
await this.open(walletConfig)
} else {
throw error
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this not be an AriesFrameworkError or IndySdkError?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this.open already handles this, so we'll always get an aries framework error here

packages/core/src/wallet/IndyWallet.ts Outdated Show resolved Hide resolved
packages/core/src/wallet/IndyWallet.ts Outdated Show resolved Hide resolved
public async verify(signerVerkey: string, data: Buffer, signature: Buffer): Promise<boolean> {
try {
// check signature
const isValid = await this.indy.cryptoVerify(signerVerkey, data, signature)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think in this case isValid adds some useful context to what cryptoVerify (and verify()) returns

Signed-off-by: Timo Glastra <timo@animo.id>
Signed-off-by: Timo Glastra <timo@animo.id>
Signed-off-by: Timo Glastra <timo@animo.id>
Signed-off-by: Timo Glastra <timo@animo.id>
Signed-off-by: Timo Glastra <timo@animo.id>
@TimoGlastra
Copy link
Contributor Author

@jakubkoci could you please take a look at this PR? The slow review process is really slowing me down

packages/core/src/types.ts Outdated Show resolved Hide resolved
packages/core/src/wallet/IndyWallet.ts Outdated Show resolved Hide resolved

import { AriesFrameworkError } from './AriesFrameworkError'

export class IndySdkError extends AriesFrameworkError {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is kind of interesting. I would assume that IndySdk is lower-level detail than framework level error. Therefore, I'm not sure about IndySdkError extending AriesFrameworkError

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The normal IndyError is lower-level detail than the framework level error. However, because the normal error is not very nice in stacktracing/information we've wrapped it with a framework specific error.

To me AriesFrameworkError is the basis for all framework created errors (which is the case if we wrap the original error). I think it can be beneficial to have a single base error that allows to catch all framework errors. Maybe AriesFrameworkError is not the best name as the base error

Signed-off-by: Timo Glastra <timo@animo.id>
Signed-off-by: Timo Glastra <timo@animo.id>
@TimoGlastra TimoGlastra merged commit 9f1a4a7 into openwallet-foundation:main Aug 4, 2021
@TimoGlastra TimoGlastra deleted the refactor/break-out-indy branch August 4, 2021 13:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Extract some method from the wallet interface into other interfaces
5 participants