CIP-0144? | Full-data wallet connector #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
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. 🎉
CIP-XXXX/README.md
Outdated
| License: CC-BY-4.0 | ||
| Version-Connection-API: 0.0.0 | ||
| Version-CIP-30-Extension: 0.0.0 | ||
| --- |
There was a problem hiding this comment.
| --- | |
| Solution-To: CPS-0010 | |
| Solution-To: CPS-0012 | |
| --- |
On that note, now that we are gradually evolving better mapping between CIP and CPS sets, we should make it official in the header.
@Ryun1 @perturbing @Crypto2099 I think we also need to establish a policy on how these inclusions should be performed in the other direction... I would propose this CIP also modify the target CPS to add the corresponding header line there: which would risk more merge conflicts but provide a more robust CIP repository in the long run (since these mappings would be less likely to get missed if adding one also added the other).
@Crypto2099 mentioned at yesterday's meeting that this could be a solution to more than one CPS: if there are others please by all means add them (also we could remove CPS-0012 if we're not all in agreement that this CIP "solves" that CPS).
There was a problem hiding this comment.
I will add the Solution-to: CPS-0010 header, as for CPS-12, maybe we should add the Solution-to tag to #869 ?
There was a problem hiding this comment.
yes, thanks: suggested in #869 (comment).
There was a problem hiding this comment.
@nazrhom regarding the applicability of this CIP as a solution to CPS-0012: doesn't it provide an answer to the "open question" https://github.com/cardano-foundation/CIPs/tree/master/CPS-0012#how-can-we-encourage-wallet-developers-to-adopt-the-solution ? I would like to hear what you & @Ryun1 @Crypto2099 @perturbing think about how broadly we should be thinking in matching these CIPs to CPSs.
rphair
added
State: Confirmed
…om/CIPs into nazrhom/full-data-wallet-connector
Co-authored-by: Robert Phair <[email protected]>
…om/CIPs into nazrhom/full-data-wallet-connector
|
|
||
| We will use the following schema to define operations: | ||
|
|
||
| ``` |
There was a problem hiding this comment.
| ``` | |
| ```json |
|
|
||
| We will reference several JSON schemas throughout the document, these are: | ||
|
|
||
| - [cip-116](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0116) which provides a JSON encoding of Cardano ledger types. Note that this CIP defines a schema for each ledger era. When referring to a type from this schema we refer to an `anyOf` of all the schemas in which that type is defined. *[Maybe we should only reference the latest era and update the CIP in the future? our current definition requires to be perpetually backward compatible with old ledger types]* |
There was a problem hiding this comment.
| - [cip-116](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0116) which provides a JSON encoding of Cardano ledger types. Note that this CIP defines a schema for each ledger era. When referring to a type from this schema we refer to an `anyOf` of all the schemas in which that type is defined. *[Maybe we should only reference the latest era and update the CIP in the future? our current definition requires to be perpetually backward compatible with old ledger types]* | |
| - [CIP-116 | Standard JSON encoding for Domain Types](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0116) which provides a JSON encoding of Cardano ledger types. Note that this CIP defines a schema for each ledger era. When referring to a type from this schema we refer to an `anyOf` of all the schemas in which that type is defined. *[Maybe we should only reference the latest era and update the CIP in the future? our current definition requires to be perpetually backward compatible with old ledger types]* |
maybe a little nicer for navigation
|
|
||
| ### Versioning | ||
|
|
||
| In this CIP we are defining two different APIs: the connection API for wallets, and the CIP-30 *[maybe this should have another name to prevent confusion?]* extension which enables an own-data wallet. These two are separate components, below there is a table with separate entries for the versions of the connection API and CIP-30 Extension respectively. |
There was a problem hiding this comment.
I know we already have a lot of CIPs/CPSs for this, and i don't want to increase work on this unnecessarily
It may make sense to have this proposal introduce the connection API, as I believe this API is agnostic of type of wallet(?)
AND then a separate proposal which adds the support/extension for the CIP30 functionality
does this sound reasonable?
A wallet connector for a full-data wallet.
See CPS-10 for motivation.
(rendered version on fork)