-
Notifications
You must be signed in to change notification settings - Fork 42
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
Migrate connect to RPC based APIs #399
Comments
The minimum would be a UI where users can choose the Wallet from when getAddresses is called. It would be nice to have a consistent UX across all apps. |
@friedger we have this in Leather now |
@markmhendrickson My request is about choosing the wallet provider (leather, xverse, asigna, ...) not the account, sorry. Arkadiko is showing this screen: |
How can I open it and what do I get back? The result should be stored by the app and reused for the rpc calls. |
I presume the |
showConnect shows the dialog AND calls authenticate (with wrapping in JWT). Connect does not use rpc calls as far as I can see. |
I missed the ongoing work here: #403 |
Yes, to make it easier to switch we'll have a version of connect which is almost the same as the JWT flow for most apps. Let me know if there's an open-source app you have that I can update to test if everything works as expected, happy to add those changes in a PR. For the raw request flow, connect will also have helpers which are like a "ui request" call where we first pick a wallet if non is selected before the request is routed to the wallet. Will update the .md files in the mentioned PR today. |
@janniks This one is the most used: sendstx.com: https://github.com/friedger/stacks-send-many |
@stacks/connect
continues to wrap the JWT-based calls used by Leather, Xverse etc.These wallets now support RPC specs for Bitcoin requests, and the direction proposed in @janniks SIP is that Stacks follows suit stacksgov/sips#166
Developers are finding it difficult to migrate to the new APIs, and would rather continue to use
@stacks/connect
. This is easier than interacting with wallets directly via their injected provider.It should be considered what is involved to upgrade
@stacks/connect
to the new RPC-based APIs. Perhaps it's best to just push a new breaking version, and prompt developers to update their apps. Another option would be to run both in parallel during, so that developers can incrementally opt-in during the transitionary phase.This change would also be a motivating factor for wallets to prioritise the new Stacks APIs.
The text was updated successfully, but these errors were encountered: