Move to new connection handling workflow.

[cvarjao]

Right now, after scanning a QR Code the wallet will wait for either a Credential Offer or Proof Request. We want to support a way for the wallet to simply connect (e.g. messaging) but not necessarily wait for Credential Offer or Proof Request.

In AIP2, there the goal code which can be used to hint the wallet about what to expect next. In AIP1, there is no goal code, and there is not hint about the reason for connecting

[swcurran]

Suggestion for immediate changes. I think we should do at least 1, perhaps 2 and maybe 3 (but the wording is tricky...):

1. As soon as the connection is established, update the screen spinner to display a happy "Connected" image of some kind, and a continue to wait.
2. Add a note at that point, "If you are justing establishing a connection, click the "Return Home Button" (or whatever).
3. When the current message "This is taking a long time..." message comes up and the connection is active, reword the message to take into account that nothing may be happen next. Wording might be tricky (I'm struggling to define it)...

[knguyenBC]

I can think about the user flow to help solve this temporarily until goal codes are implemented.

[swcurran]

I disagree, as it reflects badly on BC Wallet when used with what the community is going to promote as a “getting started” tool. If we leave it as is, the community will suggest using other wallets, which is not a good thing for BC Wallet.

Example quote published on Discord today — the hiccup is the BC Wallet issue with connecting.

Hi Team, first a big congratulation and thank you for this webinar. Great contents and labs are well-organised and easy for follow. And specially thanks for the Stephen you articulated these concepts so clearly. I have been following the SSI since Indy. Then I saw Aries, and now AnonCreds. Also the labs have been evolving: first with python code and a local indy ledger, then Swagger, and now a nice tool Traction and mobile app. What a journey and a big community effort! The only hiccup I encountered in the lab was the unstable connection establishment (sometimes stuck in response). Nevertheless, I reinstalled the mobile app and I can complete the lab.

[esune]

What is the issue with taking the user back to the home screen as soon as the connection is completed, without forcing them to take action, like other mobile wallets seem to do? If a proof-request or credential offer are sent to the wallet they will receive a notification in the home screen either way, and be able to take action from there. Forcing the user on this pattern without reason (and without telling them) seems backwards.

This is an issue with the default configuration in Bifold, by the way (see https://github.com/hyperledger/aries-mobile-agent-react-native/issues/367#issuecomment-1184660875). In my opinion "massaging" the workflow in the BC Wallet would be a patch, the real fix should likely be pushed to Bifold otherwise we'll have incompatibility issues in BC Wallet that will need fixing once the change is finally pushed upstream.

[cvarjao]

@esune, this is a UX approach. We wanted to make it easy and less steps for our users. This was one of the complains from lawyers using another wallet. They scan a QR code than needs to wait and hunt/tap for notifications. It was felt disconnected, and also cause problems as a few people thought that when they say that "Connection Stablished" message as a signal of the end of the task.

@knguyenBC is working on a new approach.

[knguyenBC]

Is this flow okay? Wireframes to represent the flow of a connected credential offer: https://xd.adobe.com/view/fe5e4410-43b4-4658-9cb4-129822d8c321-ab0d/.

[esune]

@knguyenBC I think this looks much better, as it handles the scenario that is currently causing confusion.

What I wonder, however, is how we would distinguish between the connected yes/no state: without a connection it is impossible to send a proof-request, so I think the state will always be connected (exception made for errors). Using a timeout to see whether we should expect something in addition to the connection or not seems like it might lead to further problems (what if the connection is slow and the timeout expires, but we receive an offer or proof?).

[knguyenBC]

I believe the wallet doesn't timeout. After 10 seconds, there's a message that states "this is taking longer than usual..." and people are suggested to go back to the Home screen. So if the connection is slow and the user goes back to home, they will receive a proof request when it arrives and be available in their notifications. If nothing arrives then they'll at least be out of the waiting screen and if they want to check if a connection is made, they'll go to their Contacts list.

[cvarjao]

@knguyenBC , I've started your flow diagram as a markdown file, we can update this ticket with it once we have reviewed: https://hackmd.io/@wrf54Y6BSmWpzuBx9yJg_Q/HJi5kN8vh

[knguyenBC]

That diagram looks good to me @cvarjao

[jleach]

@cvarjao Although I get an goal_code (GC) can be added to any DIDComm message, I think AFJ only exposes the GC in the invitation. This will probably be fine for what we discuss above as I can use it to understand what the purpose of the invitation. By invitation I mean whatever is in a QR code - at least that's what I think I mean for now.

[cvarjao]

@jleach , that is correct. The goalCode is defined in the invitation QR Code.

[knguyenBC]

Behaves as expected. tested on iOS and Android build 1075.