-
Notifications
You must be signed in to change notification settings - Fork 107
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
Wishlist for Mobile Wallet Adapter post-v1.0 #328
Comments
Brace yourself, wall of text incoming! This is not necessarily wallet adapter specification, but more of a utility component that could/should be shipped along with other components like Currently we can rely Standard case when we only have a frontend application is fully covered with SMS. Installing wallet adapter libraries includes the A bit rarer case when we have a full stack application is not quite supported out of the box. For example, if our backend stores some data or logic, we would need to authenticate our users (wallets) server-side. The only correct approach there is the following:
In those cases, we want users to click the "Connect" button which connects the wallet, fills in the This is an issue on mobile because the There are 2 possible solutions:
Here is what I did, and something similar can be raised as a PR to the
Effectively, I believe that we should improve the Honorable mentions: |
Hey @josip-volarevic. Thanks for all of these thoughts! You've echoed a lot of what I and others have been struggling with regarding
My initial thought on how to proceed is to unbundle functionality from the UI libraries rather than to increase their complexity (via middleware, for instance). For instance, someone can already build what you've described using Some further, random thoughts.
I'm going to stop there for your thoughts, because this has already become an omnibus rant about too many things! |
Jokes aside, I'm happy that you guys are already familiar with all those issues and have solutions in sight. What you're suggesting is to bare with the current library and use my Is there any room for me to raise PRs, create issues, test stuff or do I just let you guys do your job? |
Here are a few features I would like to see integrated within future versions of the wallet adapter. I will update this comment with specific issues and more details later.
|
It would be nice if we could have a method to retrieve the connected wallet identity (name, icon, URI). I would benefit from this as a dApp developer so I add custom handling for connected wallet(s). e.g. if wallet A is having issues last few days with some functionality I could show a toast/banner with error colors displaying "wallet A is experiencing issues with X, please note that the app might not function properly unless you switch to another wallet" |
I think this is an anti-goal. We want dApps to discriminate against wallets on the basis of their capabilities and not their brand. Brand-discrimination gave us the User-Agent wars of the early 2000s, when what we should have been doing on the web was feature detection. This is what the If a wallet isn't fulfilling their duty to perform those capabilities, that's probably best to be left between them and their users, who should vote by putting pressure on them to be better or lose a customer. |
When you put it that way... you're 100% right 😅 My thoughts were mostly innocent and towards the classic warning notification "Service x is having higher traffic at the moment and users may experience issues" "...unless you switch to another wallet" was an unnecessary part of the sentence and should be discarded |
@sdlaver This conversation has taken a turn towards JS stuff. Could you rename this ticket to be JS related, and start a new ticket for Android? That way we can discuss Java/Kotlin ideas in a separate place. |
I'd love to keep all the brainstorming and feature suggestion in one place. When collection is complete, we can break it out into actionable issues. |
EDIT: I guess we can retire this feature request. I've discussed this on discord with a few Solana Mobile lads so far and they convinced me that the current handling of address selector (and not having a cluster selector) is per good design. This piece of documentation explains how MWA supports multi-pubkey authorization and a selection of a specific key to use: In this GH issue we can also see it's been implemented: #44 A few questions before I go with my feature request/proposal (no actual need to answer them, I think I know the answers already):
Now to my proposal:
new SolanaMobileWalletAdapter({
addressSelector: createDefaultAddressSelector(),
clusterSelector: createDefaultClusterSelector(),
appIdentity: {
name: 'My app',
uri: 'https://myapp.io',
icon: 'relative/path/to/icon.png',
},
authorizationResultCache: createDefaultAuthorizationResultCache(),
onWalletNotFound: createDefaultWalletNotFoundHandler(),
}); With that, when firing requests to sign a message or a transaction we can, not only send the parameter of which address we wish to execute the action with, but also the selectedCluster. The use case which we have is: in our mobile dApp we want to give users the ability to use multiple addresses and multiple clusters ( A lot of my confusion comes from not understanding the If it's not your priority to pursue #44 ATM, I'd like to potentially investigate the issue myself, while paired with another dev or two which would handle the native side of stuff for me. I'm only fluent with web stuff :D TODO:
In conclusion, I expect that this is the state of this feature: Overall, a single auth token for multiple addresses AND clusters, on explicit users approval. cc: @steveluscher @sdlaver curious about your thoughts. No rush if you're busy with the Saga launch! :) |
Please comment on this issue and list what you want to see added or changed in Mobile Wallet Adapter in a post-v1.0 future. Bonus points if you file a detailed issue describing the feature and add a link to it here!
The text was updated successfully, but these errors were encountered: