SIP-030: Wallet RPC Standards #166
Conversation
|
Great work @janniks. Leather supports this SIP 🖤 |
|
Thanks for the input @m-aboelenein @kyranjamie . Do you think you could do another review with final remarks until ~Tue. 20.02.2024 to wrap this up with bipartisan support? 🙏 |
|
Added methods |
|
@aryzing @kyranjamie I added an update to the encoding (as discussed on last weeks call). Also updated:
Ping me if you disagree with anything -- trying to make the naming more logical and short |
|
CC @pradel would also love to get your feedback on this updated approach to "Connect"/auth -- it's less convoluted, but also more explicit (might need multiple steps for some things, that were just magically done in auth previously , e.g. requesting a gaia token would be it's own step, (although wallets could also add it to something like getAddresses / getAccounts) |
|
@janniks I like this change, less magic on what's going on and the behavior seems to be pretty similar to how ETH is doing things, making it easier for ETH devs to use the API |
|
CC @friedger would also love to get some of your feedback+expertise, since you've worked on this area in the past 🙏 |
|
Also, Thanks for all the feedback everyone! 👏 I feel like we're nearing a good document here. I think we can wrap it up soon 🫡 |
|
Let me know which email-addresses/github-usernames to add to the author list. cc @kyranjamie @m-aboelenein @aryzing |
| Wallets implementing the new standard may maintain the previous system to support legacy applications during a transition period or indefinitely. | ||
| Existing applications using the current Auth system should continue to operate, but immediate changes are recommended once this SIP is ratified. | ||
|
|
||
| ## Reference Implementations |
There was a problem hiding this comment.
Reference implementations are the one of leather and xverse, aren't they?
There was a problem hiding this comment.
if there is one, i think it would be helpful to share that information here rather than solely describing how the implementation should work.
is there an existing implementation of this proposal?
i would argue that most of this section should be moved to the Specifications section, since that's what they appear to be defining: specifications, not implementation details.
There was a problem hiding this comment.
Yeah, let's link to a git tag in these projects so readers can have an example of a compliant artifact to study.
| - Addresses are serialized as Stacks c32-encoded strings. | ||
| - Clarity values, post-conditions, and transactions are serialized to bytes (defined by SIP-005) and used as hex-encoded strings. | ||
|
|
||
| ### Methods |
There was a problem hiding this comment.
Is this part of the specification?
There was a problem hiding this comment.
+1 - made a comment above about this exact thing before seeing you state the same here.
There was a problem hiding this comment.
The method definitions? They are sort of the largest part of the spec. But we can add more on specs for provider discovery and implementation
There was a problem hiding this comment.
yes - i think it's more accurate to have them in the specifications section rather than the implementation section.
the current text doesn't describe or define an implementation of the specification is my reasoning.
i referred to https://github.com/stacksgov/sips/blob/main/sips/sip-000/sip-000-stacks-improvement-proposal-process.md?plain=1#L165-L170 for my reasoning here.
|
|
||
| ### Provider registration | ||
|
|
||
| Wallets can register their aliased provider objects however they see fit. |
There was a problem hiding this comment.
Is this specific enough? Currently, different wallets use different methods and are not working nicely together.
There was a problem hiding this comment.
Yeah, I agree we should add more on provider discovery.
|
|
||
| #### Event `accountChange` | ||
|
|
||
| `listener: (accounts: {}[]) => void` |
There was a problem hiding this comment.
Wondering if this is a privacy issue. A user might only wish to share one particular account details with a given app, but this switcher api implicitly shares all account details, (if a user switches to all accounts).
Instead, perhaps we should return only the account index, such that the app can know the account has changed.
|
I liked the previous title of this standard better because it was easier for a lay person to understand. What do you think about one of these alternatives instead?
|
| #### Method `stx_getAddresses` | ||
|
|
||
| > **Note**: This method can be used similarly to legacy "connect" methods, where the first account selection also acts as an approval of the site/domain. | ||
|
|
||
| Result properties | ||
|
|
||
| - `addresses`: `{}[]` | ||
| - `address`: `string` address, Stacks c32-encoded | ||
| - `publicKey`: `string` hex-encoded |
| - `txid`: `string` hex-encoded | ||
| - `transaction`: `string` hex-encoded raw transaction | ||
|
|
||
| #### Method `stx_transferSip9Nft` |
There was a problem hiding this comment.
stx_transferSip13Sft could be added as well.
|
|
||
| Errors thrown by request methods should match existing JSON-RPC 2.0 error codes. | ||
| This way, the user or an intermediary library can handle them in a standardized way. | ||
| Otherwise, no additional error codes are defined in this SIP. |
There was a problem hiding this comment.
Common errors like "user denied request" should have a defined error code
Leather uses 4001.
|
|
||
| SIP Number: `030` | ||
|
|
||
| Title: Integration of a Modern Stacks Wallet Interface Standard |
There was a problem hiding this comment.
| Title: Integration of a Modern Stacks Wallet Interface Standard | |
| Title: Definition of a Modern Stacks Wallet Interface Standard |
| - Bytes are serialized as hex-encoded strings (without a 0x prefix). | ||
| - Predefined formats from previous SIPs are used where applicable. | ||
| - Addresses are serialized as Stacks c32-encoded strings. | ||
| - Clarity values, post-conditions, and transactions are serialized to bytes (defined by SIP-005) and used as hex-encoded strings. |
There was a problem hiding this comment.
SIP-003 is also relevant here
Co-authored-by: kyranjamie <[email protected]>
Wallet RPC Standards
📓 Read the full SIP-030 on Wallet RPC Standards