Investigate timing issues when connecting to BC Wallet

[esune]

When connecting to BC Wallet, it appears that the new connection is always very slow to be instantiated or, at the very least, to be detected by the BC Wallet - in Traction/ACA-Py the connection results active almost immediately.

Acceptance Criteria:

• Investigate and troubleshoot the behaviour, and log findings/action items as needed.
• Use AnonCreds instance for troubleshooting. Instance can be decommissioned when done.

[esune]

Based on input from @amanji and as confirmed by the BC Wallet team, it appears that the BC Wallet will sit, by design, on the spinner screen after a connection until another interaction (credential offer, proof request) is detected.

[swcurran]

Discussed with the BC Wallet team. This is intended behaviour (kind of). There should be a goal code with the invitation that tells the Wallet what to do when creating a connection. Without that, the Wallet defaults to waiting on the screen for a presentation request or a credential offer. This makes the combination of protocols appear to the user as a single event — which is desirable. We need to use a (possibly not yet formally defined) “Connect” goal code that is used when all you are doing is connecting. An alternate goal code name we could use is “Just Because”.

To do:

• Figure out what Aries RFCs have today related to Goal Codes — is there a “connect” goal code already?
  • @swcurran volunteered to look into that, and propose a PR to address whatever is missing.
• Decide what to do about RFC 0160 Connections which doesn’t have goal codes at all?
  • Need to discuss this as a group and solve this.
• Update the various services that add the “Connect” Goal Code where appropriate. For BC Gov, that’s at least Traction and the Mobile Verifier feature in BC Wallet itself.

[swcurran]

@cvarjao @knguyenBC @jleach — given the lack of Goal Code in RFC 0160, what about this as a compromise. If we are using RFC 0160, when we get to the timeout (where we currently put the “This is taking longer…” message), we check if the connection is active, and if so, we just happily return to main? That way, only when it is an Offer/Request and it actually takes a long time do we get undesired (but not bad) behaviour. The “Connect” use case is a little slower, but not painful — and fixed when we transition to RFC 0023 DID Exchange.

[esune]

@swcurran I am inclined to either close this issue and log action items elsewhere (aries-rfcs, aca-py) or - at least transfer the issue to the DITP repo and re-assign it, since it is not Traction-related. Thoughts/objections?

[swcurran]

One thought — we could put an instruction in Traction about what to expect if using BC Wallet. Could be helpful for some.