CIP-???? | Web-Wallet Bridge - Extensive Light Wallet Standard #620
Conversation
| Implementors: [] | ||
| Discussions: | ||
| - https://github.com/cardano-foundation/cips/pulls/620 | ||
| - [Cardano Working Groups Discord server](https://discord.gg/XFjAzsQyaM) |
There was a problem hiding this comment.
| - [Cardano Working Groups Discord server](https://discord.gg/XFjAzsQyaM) | |
| - https://discord.gg/XFjAzsQyaM |
The YAML section here doesn't understand Markdown. The invite link should be OK on its own because people following it will have no trouble finding the #wallet-standard channel.
There was a problem hiding this comment.
This is a very interesting proposal and something I am very keen to follow the development on. 😎
This has spurred me on to continue working on #619, I think that CPS and this proposal will work well being developed side-by-side.
I have added a couple editorial comments.
A few larger questions I have:
- Does this need to extend CIP-30?
- What was the motivation to use the CIP30 extension mechanism?
- As to me this is close to making CIP30 unneeded, so I think we could consider alternate routes to extending CIP30, such as CIP90.
- Is it really the wallet's role to be able to query many aspects of Cardano? id argue no
- To me it makes more sense to split the large
.queryendpoint into separate standards so wallets can choose what things they support querying, if this is pursued.
- To me it makes more sense to split the large
| @@ -0,0 +1,230 @@ | |||
| --- | |||
| CIP: ? | |||
| Title: Extensive Light Wallet Standard | |||
There was a problem hiding this comment.
| Title: Extensive Light Wallet Standard | |
| Title: Web-Wallet Bridge - Extensive Light Wallet Standard |
For CIP-30 extensions we have been enforcing the prefix of "Web-Wallet Bridge -".
There was a problem hiding this comment.
Also, I think this shouldn't be constrained by light wallets - why not just any wallet?
There was a problem hiding this comment.
There may be even a better designation than "light" because the incorporation of a query layer could make the wallet quite a bit heavier. 🤔
There was a problem hiding this comment.
As per Discord there are better terms evolving for the different classes of wallets: https://discord.com/channels/971785110770831360/992011119872970762/1176547955919044680
(not quoting here yet since these terms are still in flux according to "Workshop" on wallet interfaces scheduled in the coming day... if finalised @klntsky @Ryun1 @mkazlauskas we should copy them here)
There was a problem hiding this comment.
... copying these operating definitions here for public consideration in the meantime, since haven't seen it transcribed anywhere else on GitHub or changed yet (thanks to @yHSJ for the formulation):
- Zero Data Wallet: This wallet has no notion of the blockchain, it is simply an interface for cryptographic operations
- Personal Data Wallet: This wallet does provide some data from the blockchain, but it is limited to only the data that is relevant to the key pairs controlled by the wallet
- Full Data Wallet: This wallet has complete view of the blockchain and can do any querying that a dApp would do
| - A transaction is passed for signing, but the wallet does not yet know about the UTxOs it spends, and thus refuses to sign it | ||
| - A transaction is sent to the network via the dApp backend (bypassing CIP-30 submit method) and is confirmed there, but the wallet still does not know about its consumed inputs, and thus returns outdated data. | ||
|
|
||
| ### Principles of this CIP |
There was a problem hiding this comment.
I think this text could better fit in the Rationale section, as it is giving context to why the specification is designed the way it is.
|
|
||
| ## Specification | ||
|
|
||
| ### Query layer |
There was a problem hiding this comment.
Should wallets be treated as a all-knowing query layer for Cardano?
Do wallet providers want to support this? - could it be expensive for them?
There was a problem hiding this comment.
💯, maybe part of the query layer that allows querying arbitrary (not just user's wallet-related) data such as any utxo or transaction could be a separate extension/cip. Not sure how to define the boundary here.
There was a problem hiding this comment.
Should wallets be treated as a all-knowing query layer for Cardano?
Standardizing the query layers would allow wallets to be free from the burden of running their own infrastructure. Thus it would not be a problem to force the wallets to provide query layers - they will be just passing data from JS to query layer provider's HTTP interface, which does not require any infra.
Ryun1
changed the title
| * Plutus Script | ||
| * PubKey | ||
|
|
||
| ### JsonTx API |
There was a problem hiding this comment.
It would be great to specify this as a separate CIP, so that it could be maintained independently of dapp connector and other CIPs could reference it. @KtorZ seems to have done some work on this already https://github.com/CardanoSolutions/cardanonical
klntsky
changed the title
No, there's no technical requirement.
I didn't know about CIP-90 at the time. If the APIs are compatible with CIP-30, then it's better to switch to referencing CIP-90 instead, because it would free us from CIP-30 as dependency. |
|
Let's put this on hold until we figure out the dependencies - at least as draft CIPs outlining scope. |
|
@klntsky reflecting your #620 (comment) I'm finally marking this But the dependencies you mention above are mostly merged... I would rather continue active review than close it or leave it as a |
rphair
added
the
State: Waiting for Author
|
@klntsky this "draft" has been open for nearly a year so I believe it could be effectively abandoned in its current form. If not, please do something to finalise this draft for review or withdraw it by closing this PR. As I recall the community was responsive to this idea so personally I hope you will continue work on it. |
rphair
added
State: Likely Abandoned
This PR adds a new CIP that describes a webpage-based communication bridge allowing dApps to interface with Cardano wallets. This interface extends CIP-30. Improvements over the original standard are:
Context: https://cardano.ideascale.com/c/idea/103857
Discussion: https://discord.gg/XFjAzsQyaM
Rendered Proposal on fork