Aligned with New CIP-30 Extension Scheme #15
Conversation
Ryun1
force-pushed
the
cip-62-extension-rewrite
branch
from
9d30c5d
to
ff868fd
Compare
CIP-0062/README.md
Outdated
| #### api.getVotingPurposes(): Promise\<VotingPurpose>[] | ||
|
|
||
| Errors: [`APIError`](#extended-apierror) | ||
|
|
||
| This is a chance for dApps to ask wallets what `VotingPurpose`s the user wishes to allow the dApp access to. It is up to wallet implementors if they deem it necessary to prompt the user for their permission to share supported Purposes. |
There was a problem hiding this comment.
As this is just defined as an endpoint to fetch supported purposes by the wallet, there is no access request needed.
Else endpoint would need to be redefined as enableVotingPurposes(purpose: VotingPurpose[]) that takes a list of purposes to enable just like previous catalyst.enable(purpose: VotingPurpose[]) call.
But I dont see this as needed, I happy with wallet just returning a list of purposes it support. Its enough that the user ask for CIP62 permission once, when calling CIP30 enable(). Else it will result in a bad UX.
So text here should be updated to remove info about extra access request.
|
unrelated to this PR but I think there is an inconsistency in how
However this is the current definition of the
I guess the |
| 1. **dApp Dialogue** - User indicates to the dApp intention of wallet connection, the user selects their chosen wallet from a list of supported ones offered by the dApp. | ||
| 2. **Connection** - Using the name of the selected wallet the dApp can call [CIP-30's enable](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0030#cardanowalletnameenable-extensions-extension----promiseapi) passing in this CIPs identifier: `cardano.{walletName}.enable([{"cip": 62 }])`. This should cause the wallet to ask the user to grant permission for the dApp connecting and using the CIP-62 API Extension. | ||
| 3. **Purpose** - Once connection is established the dApp will want to establish the supported wallet's `VotingPurpose`s, this is achieved via `.getVotingPurposes()`. By knowing the supported purposes the dApp can correctly choose which ones to use when calling `.signVotes()` and `.submitDelegation()`. | ||
|
|
||
| #### Delegation | ||
|
|
||
| Recall from [CIP-36](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0036) a registration is a self-delegation, allocating one's voting power to one's own voting key. | ||
|
|
||
| 1. **Get Voting Key** - dApp calls the method `api.getVotingCredentials()` to return the connected wallet account's public `voteKey`. |
There was a problem hiding this comment.
not related to this PR, but I was just polishing HW wallet support when I realized that only Ledger HW wallet will be able to return the voting key. So this call would fail for a Trezor user even though they may want just to delegate their voting rights and for that usecase it's sufficient to get the staking key. One solution I can think of is to split this call into two, so each piece of information is available independently, i.e. getVotingKey and getStakingKey - what do you think @Ryun1 ?
Alternatively, we may make the votingKey in the returned value optional though that may not lead to good UX as it may no longer be clear why the votingKey wasn't returned as there would be no error code/message to indicate that
There was a problem hiding this comment.
for the record, as we discussed that offline - it seems that the stakingKeyPub may not need to be exposed at all as the wallet can handle it internally. For the sake of constructing the delegation transaction, it's enough for the wallet to receive the staking address in the DelegatedCertficate structure and it can map it back to the respective public key - wallets need to do much heavier reverse mapping under the hood already anyway to support signing Cardano transactions with hardware wallets as hw wallets expect derivation paths, not raw addresses/keys.
If we suppose that a wallet has a single staking key, not even the staking address would be needed, but it seems to be more future proof and consistent with CIP-30 to include it as the CIP-30 API itself exposes the reward (i.e. staking) addresses as an array: https://github.com/cardano-foundation/CIPs/blob/master/CIP-0030/README.md?plain=1#L305
So to sum it up - unless there's some usecase I'm missing, I think the stakingKeyPub can be dropped from the getVotingCredentials() call altogether in which case it probably makes sense to rename the call back to getVotingKey() and the submitDelegation() call's parameter could reference just the stakingAddress which can be retrieved from the CIP-30 getRewardAddresses() call. This would also solve the problem raised in the comment above
Co-authored-by: Rafael Korbaš <rafael.korbas@gmail.com>
Context
Changes
Removed initial API components:
cardano.{walletName}.catalyst.apiVersioncardano.{walletName}.catalyst.enable(purpose: VotingPurpose[])Added:
api.getVotingPurposes()Prose:
Examples of Message Flows and Processes.Examples of Message Flows and Processes.Rendered Version