CIP-0144? | Wallet Connector API #957
Conversation
Ryun1
added
Category: Wallets
Co-authored-by: Ryan <[email protected]>
Co-authored-by: Ryan <[email protected]>
Co-authored-by: Ryan <[email protected]>
Co-authored-by: Ryan <[email protected]>
rphair
changed the title
rphair
left a comment
rphair
left a comment
There was a problem hiding this comment.
At initial review in the CIP meeting yesterday we agreed this represents long-awaited progress as a wallet API that we have needed for some time. We feel optimistic this will move ahead after some refinement so agreed to accept its CIP candidate status immediately.
@Ryun1 @Crypto2099 @perturbing we should start tagging wallet devs left & right on this, as well as kicking off some activity in the CIP Discord in both the Wallets and Query Layer threads. - Q: is the Wallets Working Group still meeting, and could they start chewing on this there?
In the meantime @nazrhom please rename the containing directory to CIP-0144 and update the link to your proposal in the original posting with the new pathname. 🎉
rphair
added
State: Confirmed
…om/CIPs into nazrhom/full-data-wallet-connector
CIP-0144/README.md
Outdated
| ``` | ||
| { | ||
| "operation": "enable", | ||
| "request": { "$ref": "#/appendix/Extensions" }, |
There was a problem hiding this comment.
just a thought, would there be a usecase where a dApp doesnt request a whole extension?
perhaps a dApp only wants a couple methods, maybe this would just add unneeded complexity
There was a problem hiding this comment.
Discussed in meeting
we can consider this in the future, or when we have more feedback from stakeholders
|
@nazrhom now that the last hour's CIP meeting has confirmed we have a new title taxonomy as @Ryun1 has done here for CIP-0030? 🙏 @Ryun1 @Crypto2099 and other wallet reviewers... I would leave it to your consensus about whether or not "candidate" (not yet merged) CIPs should be included here.
|
| } | ||
| ``` | ||
|
|
||
| Returns true if the dApp is already connected to the user's wallet, or if requesting access would return true without user confirmation (e.g. the dApp is whitelisted), and false otherwise. |
There was a problem hiding this comment.
or if requesting access would return true without user confirmation
I find this problematic:
- This could be an issue to implement for some wallets if they decide to request user confirmation when new extension is requested (e.g. some kind of identity extension, side chain extension)
- Multi-account wallets might want to provide user with an option to connect a different account on each enable
Also I find the operation name isEnabled a little bit misleading here, as it does not necessarily mean that enable was called and resolved successfully.
What are the use cases of this operation?
There was a problem hiding this comment.
This was part was copied verbatim from the current CIP-30. As a general point I have tried to keep the API as close as possible to CIP-30, to make the transition to the new CIP easier. Since we are not backwards compatible with CIP-30 anyway, I could also see the argument for saying we might take this opportunity to make more breaking changes.
I am curious to hear other people's opinions on this: should we strive to be as close as possible to CIP-30 (while still addressing the identified shortcomings cfr. https://github.com/cardano-foundation/CIPs/tree/master/CPS-0010), or should we take this as an opportunity to change the API in other places as well?
I will do some research on the original motivation behind this operation. My guess is that, since the enable call specifies:
The wallet can choose to maintain a whitelist to not necessarily ask the user's permission every time access is requested, but this behavior is up to the wallet and should be transparent to web pages using this API. If a wallet is already connected this function should not request access a second time.
This endpoint is provided so clients can keep track of permissions, should the wallet not already do that.
|
|
||
| While this CIP attempts to define an API in a transport agnostic way, implementations will be forced to pick a specific transport. In the spec we have not given specifics on how to namespace and generally structure the api in an implementation. This is both because details depend on the underlying transport that is chosen to implement the API, but also because we wanted to make backwards compatibility with the original CIP-30 proposal as easy as possible. | ||
|
|
||
| Each transport specific implementation will make a choice on how to namespace access to the operations. In the following we give a description of how this should work for an implementation using an injected javascript object. Support for different transports can be added to this CIP in form of PRs. |
There was a problem hiding this comment.
Support for different transports can be added to this CIP in form of PRs.
Maybe we could keep this CIP transport-agnostic and have separate CIPs for each transport, including Injected Javascript Object 💡
There was a problem hiding this comment.
I think this makes sense, and had thought the same myself. The argument against this would be to avoid opening too many interconnected CIPs, but I am happy to split it if there is consensus around this.
There was a problem hiding this comment.
@mkazlauskas @nazrhom this is a question I would hope to have @Ryun1's insight about.
There was a problem hiding this comment.
The argument against this would be to avoid opening too many interconnected CIPs
i feel that is probably okay
since it would be quite nice if this CIP was transport-agnostic
|
|
||
| ### CPS-10 | ||
|
|
||
| [CPS-0010](https://github.com/Ryun1/CIPs/blob/cps-wallet-connector/CPS-0010/README.md) discusses several limitations of CIP-30. In this CIP we try to solve the issues pointed out in that CPS. There are still some areas to improve on: things like the event listener API are intentionally left out of this CIP to prevent bloat of scope. We welcome future CIPs, or updates to this CIP to refine any limitation that is not tackled in this document. |
There was a problem hiding this comment.
There are still some areas to improve on: things like the event listener API are intentionally left out of this CIP to prevent bloat of scope
I think we should have some primitives for defining events in the base spec/cip. As far as I understand, request has to be a plain object as you can't define callbacks in a JSON schema.
There was a problem hiding this comment.
I would be curious to hear more about your thoughts on the possible event API. The reason it was originally excluded was that I thought it would work better as an extension to this CIP, as it is a completely new API and it requires a discussion around which events we would like, etc. But I would be happy to start the discussion in this CIP and then we can decide if we want to add this in this CIP or keep it for a future one
There was a problem hiding this comment.
I was thinking that extensions:
- would be defining their schemas for base operation payloads (
request/response/error) - probably shouldn't be adding new base operations, as it adds new requirements for transport CIPs/implementations
Given this CIP (and naming of request/response operations), transport specifications would probably imply only a single value resolved from a 'request' - a typical pull-based API structure, e.g. injected javascript object transport implementation would probably map requests/responses into a promise based API like api.cip123.operation(r: Request) => Promise<Response>
If you wanted to add an extension for events, you couldn't really do it by adding an on 'request', because transports would generically expect it to resolve with only a single value like all other requests.
Am I missing something - could you create an extension for events given this base CIP?
CIP-0144/README.md
Outdated
| ``` | ||
| { | ||
| "operation": "enable", | ||
| "request": { "$ref": "#/appendix/Extensions" }, |
There was a problem hiding this comment.
Existing dapps are always in context of a specific network. Could we add chain id in the enable request?
There was a problem hiding this comment.
I think this is a great idea! We should definitely build upon CIP-34 to identify the network. One question that I have is: should a wallet only support a single network at a time, or should it be able to speak to different networks at the same time?
Supporting multiple networks at the same time would complicate the API a bit (we would have to somehow track what network we want to run an operation on) I am not sure if there are use cases for this that would justify the additional complexity, but I would be curious to hear feedback from different stakeholders on this
There was a problem hiding this comment.
i feel that one Cardano network at a time, is probably okay
and matches existing implementations
There was a problem hiding this comment.
Agree, one network should be enough for now. Although it would be interesting to learn about Hydra use cases
There was a problem hiding this comment.
point from CIP editors meeting;
- methods for L2s or state channels are probably better suited as extensions as they may have their own unique constraints
- but it would still make sense to add a
networkfield to the enable call, to allow the dApp to request a given network connection
|
I just posted on Discord in response to query about this proposal's status: You are right that the work stopped in February. Without the author (@nazrhom) being involved in the submission anymore, and nobody to respond to suggestions & questions that came after then (with a few points unresolved at that time), this CIP has been stalled. Normally editors would mark a proposal In my opinion it was mature & likely would be ready for merge after it can be taken up by another advocate, even if outside of MLabs: bringing appropriate experience in the wallet industry & responsibility for some related implementations of this API. Alternatively, if a number of such devs got together to certify this proposal is ready to go "as-is", we might merge it if there are enough confirmations on GitHub... plus answers provided to at least the review points that begin here: #957 (review) |
rphair
added
State: Waiting for Author
|
Just to say 👋 This is a subject I’m super interested in, and really want to help improve both sides of the equation: user UX and dapps capabilities. I would be happy to contribute and help restart the discussions on this subject in a couple months. I’m currently busy on a couple things, but this is super important and will be critical for adoption and retention, both of users and devs. |
|
im also keen to move this along |
|
Hi @Ryun1 @rphair I am sorry for not replying here sooner but have been busy with other work. Good news is I have received approval from MLabs to spend some time pushing this CIP forward: addressing comments, making the required changes, etc. So I am keen to pick this up. I am wrapping up another project but should be able to start making some progress here towards the end of August. @mpizenberg I would be happy to collaborate with you on this! |
|
@mkazlauskas Thank you very much for your feedback on the PR, I am sorry for the incredibly late reply. I will reply to each point in individual comments, but just wanted to thank you for looking into this! |
Co-authored-by: Ryan <[email protected]>
Ryun1
removed
the
State: Waiting for Author
|
Putting this one into Review for CIP Editors meeting # 118 tomorrow💪 https://hackmd.io/@cip-editors/118 |
rphair
added
the
State: Confirmed
|
@Ryun1 where can I find links to join the call (if that’s possible at all)? |
of course! meetings are every other Tuesday at 4pm UTC |
Add extensions table
| - `Refused`: (-3) The request was refused due to lack of access - e.g. wallet disconnects. | ||
| - `AccountChange`: (-4) The account has changed. The dApp should call wallet.enable() to reestablish connection to the new account. The wallet should not ask for confirmation as the user was the one who initiated the account change in the first place. | ||
| - `NotSatisfiable`: (-5) The request is structurally correct, but the wallet can not satisfy it for some reason. | ||
|
|
There was a problem hiding this comment.
would a new error be needed
for the case where a dApp requests a network at enable time
but the wallet is not connected to it?
Co-authored-by: Ryan <[email protected]>
Co-authored-by: Robert Phair <[email protected]>
Add chainId to enable call. Also add new error type if the requested network is not avialable
6 participants
A wallet connector API. The goal of this CIP is to define a connection API that is independent of functionalities provided by wallet extensions. Future CIPs will introduce extensions to gain parity, and eventually surpass the capabilities offered by CIP-30 today.
See CPS-10 for motivation.
(rendered version on fork)