CIP-0144? | Full-data wallet connector

[nazrhom]

A wallet connector for a full-data wallet.

See CPS-10 for motivation.

(rendered version on fork)

[rphair]

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]

Suggested change

	---
	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).

[nazrhom]

I will add the Solution-to: CPS-0010 header, as for CPS-12, maybe we should add the Solution-to tag to #869 ?

[rphair]

yes, thanks: suggested in #869 (comment).

[rphair]

@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.

[Ryun1]

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?

[nazrhom]

Hey @Ryun1 I think that is a fair point. One argument that can be made against it is that we could split this even further. It is something that I was thinking quite a bit about when writing this document, in a way you could argue that the 5 points listed here should all be standalone CIPs.
Having said this, I think it does make sense to have it separate, if you and other reviewers agree on it I am happy to separate them. My initial thought would be to have a CIP which introduces the transport agnostic specification, and use that to define the connection API. Then we could have one (or two?) other CIPs to define the CIP-30 and CIP-139 extensions. What are your thoughts? cc @rphair