Closed Nanosync closed 2 months ago
Hi @Nanosync
Thanks for reaching out. I think you're referring to a bug that was recently introduced and subsequently fixed in the latest version (0.23), where when a dapp made a request to the wallet and the wallet was locked, unlocking it brought you to the homepage instead of going to the action that the dapp requested.
This should be fixed if you update your installation. Could you please update and check if your user story now passes the acceptance criteria?
If I misunderstood your user story, please let me know 🙏
Thanks 🙂
Hi @victorkirov , thank you for the quick response. I can confirm scenario 1 is working now!
However for the 2nd scenario, I'm not sure if this is the right repo to post this, but is it possible to expose some API in sats-connect to determine what addresses are available (e.g. getAddresses
which gets the address list if permissions are already granted otherwise throw an error, or requestAddresses
which prompts for user permissions)?
Great, thanks for confirming that 1 is resolved 🎉
For #2, we recommend saving the addresses into localstate on connect and restoring from there on load. Our approach is slightly different to some other wallets in that we want the users to confirm any comms between the wallet and the dapp if there is sensitive info being passed between them.
For instance, if the user switches addresses in their wallet, we would want them to reconfirm the getAddress request again and not allow the dapp to freely request potentially sensitive info that the user might not want to give up.
@victorkirov Noted that the addresses can be saved into local state and restored, but how would the dapp know that the user had switched addresses in their wallet (or if the wallet is unavailable)? Is there some event that is exposed that the dapp can listen to?
There is no event, no. The dapp sends through the address that they are working with via sats-connect for address specific commands in case of a change. We are considering adding an address changed event in the next version. If you have a strong use case for it, please let me know and it would help to increase the likelihood of it being added.
For wallet availability, you can check if the provider was injected into the window object (window.XverseProviders). If that is undefined, that means that the wallet is not available. Just note that the extension in-page scripts run at the end of the page load, so you may have to sleep and/or retry for a second or two before it is loaded. This is another thing we want to add to sats-connect to make this detection process a little less manual.
Story
As a dapp
I want to be able to connect to the xverse wallet instead of seeing the xverse wallet homepage after unlocking the wallet, and monitor whether I am still connected to the xverse wallet (if it's locked, I should not be connected, otherwise I should be able to know I am connected, and if I am not, I can request to invoke the wallet popup or do nothing) so that I can connect to the wallet without closing the wallet and restarting the auth flow.
Acceptance Criteria
The user should be able to connect to the wallet without restarting the auth flow.
Prerequisite
Scenario
1
Given I am not connected to the xverse wallet When I try to connect to the wallet while it's locked Then I should be able continue connecting to my app after it's unlocked without restarting the auth flow
Scenario
2
Given I am not connected to the xverse wallet When I check if I am connected to the wallet Then I should be able to know whether I am connected or not, and be able to request to connect to the wallet