-
Notifications
You must be signed in to change notification settings - Fork 153
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
feat: Add signTransaction() and signDelegateAction() to BaseWalletBehaviour interface #1213
base: dev
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So far it looks totally pointless. Do you have a proof of concept? We need a dApp with these interfaces used and miniwallet that will handle these operations.
What you also should think about is how dApp will receive the signed transaction from:
-
web wallet - given that currently transaction signing experience redirects dApp user to a different website which redirects them back, so Promise is not going to work well here - we need to consider if we can open a new window instead of a redirect, and how that window will report the signed transaction back
-
mobile wallet on the same device (when Wallet Selector-enabled website is used on the mobile device where I have the wallet app) - it will open a separate app, which somehow should give the control back
-
mobile wallet for a desktop dApp - users are asked to scan a QR code, but again dApp needs to get a response back somehow
-
browser extension
-
Ledger device
/** | ||
* The {Signer} object that assists with signing keys | ||
*/ | ||
signer: Signer; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How do you envision the use of it? Isn't the whole point to use an external wallet as signer? How is it required?
/** | ||
* The Transaction object to sign | ||
*/ | ||
transaction: Tx; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
App developer in most of the cases cannot construct the full transaction since there is no public key and therefore there is no nonce. Also, it is often no account id either.
I cannot think of the use for SignTransactionParams
interface as it is defined right now.
/** | ||
* Tx nonce. | ||
*/ | ||
nonce: bigint; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tx nonce is attached to the public key nonce of the account, it does not make sense to require it from the app developer.
/** | ||
* Public key for the access key used to sign the delegate action | ||
*/ | ||
publicKey: PublicKey; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
App developer does not have the user's public key
/** | ||
* Account ID for the intended signer of the delegate action | ||
*/ | ||
senderId: string; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
App developer does not know the senderId
/** | ||
* Current nonce on the access key used to sign the delegate action | ||
*/ | ||
nonce: bigint; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same problem as with transactions, see above
Description
Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.
Checklist:
Type of change.