CIP-0013: Current state of integration and further advancements about cips HOT 12 OPEN

re: future plans for wallets... cc @Crypto2099

@MadOrkestra we had a brief review of some of these topics when I last rewrote CIP-0013 to have more flexibility for future protocols to be added. Additional // schemes were suggested in this period for metadata and other chain queries (see #625 - cc @Ryun1 @klntsky).

I can't personally provide insight about what wallet developers might or should be doing, but I will definitely follow this thread to do whatever I can to make CIP-0013 implementations easier than any proprietary alternatives.

🚫 Payment Scheme for Native Assets

I would expect that including native assets besides Ada in a payment query string would first be discussed similarly to this thread: #86, with some comments & concurrent PRs and issues suggesting:

• the use of asset names is error prone (not unique in the protocol) and therefore URIs should only contain the asset fingerprint... meaning you run out of URI space (vs. 2048 character limit) and therefore they are impractical.
  • I am willing to admit that the collision between short asset names, especially given the huge problem with fake assets, is much more of a problem here than with duplicate stake pool tickers & that resolving short asset names would place a burden on wallet software.
• the use of asset names/fingerprints as keywords... rather than values in a keyword-value array... has been declared "difficult" for programmers to implement and therefore a URI scheme was suggested that would only work for single assets at a time (hence this logic was disqualified: see #65).

So I expect a new payment URI should support payment links like (feel free to substitute asset fingerprints for familiar token names here, and I expect the entire URI query would be case-insensitive):

web+cardano:Ae2tdPwUPEZ76BjmWDTS7poTekAvNqBjgfthF92pSLSDVpRVnLP7meaFhVd?ADA=100&WMT=500

... or, if the query URI values are ruled to be a problem for backward compatibility of already supported payment links:

web+cardano://payment?Ae2tdPwUPEZ76BjmWDTS7poTekAvNqBjgfthF92pSLSDVpRVnLP7meaFhVd&ADA=100&WMT=500"

I would be happy to work these into CIP-0013 as soon as enough discussion can validate the syntax & boundary cases here:

• address formats, as documented in other CIPs
• payment "handles", given potential problems in handle domain resolution as per @SIDANWhatever's #605
• acceptance of the much simpler syntax of asset-names-as-keywords (or asset fingerprints, if you have the space in the URI for it) rather than other longer, more awkward, more restrictive naming conventions for the "payment array"
• outlining an efficient and secure means for wallets to interpret payment URIs using "short asset name" (e.g. WMT rather than its asset fingerprint)... because without these, users might not be incentivised to use these multi-asset payment links.

from cips.

Hey guys, great convo so far from @rphair and @MadOrkestra! I'm excited about this and having talked to both contributors so far, eager to do my part where I can to help advance the overall ecosystem adoption of web+cardano URIs and all of their myriad variations.

We have had a number of other proposals to utilize these URIs such as:

• CIP-99
• A "pointer" scheme from @Quantumplation to point to transactions or blocks
• A new "authentication" CIP I was preparing to write this week

In light of this, I'm happy to also add to my workload a new CIP to iterate above CIP-13 and implement a dedicated "payment" URI scheme where we can work through the metadata, native asset, and potentially the DNS resolution issues. I believe this is a problem that we can solve (within some certain limits).

from cips.

The progress has begun by first defining a "CPS" dedicated to web+cardano: URIs so that hopefully we can create a singular point-of-reference for future implementers that can contain links to the various CIPs as well as software solutions (libraries?) to help aid adoption: #841

from cips.

Maybe a general comment before we dive into details: Looking at the Path to Active for this CIP (https://cips.cardano.org/cip/CIP-13), with BeginWallet implementing payments, IMO all we really need to put this CIP live as is would be implementation of the Stake Pool URIs by one or more wallets.

With Yoroi, Begin and Vespr already having implemented CIP99 the last acceptance criteria (one or more wallets supporting additional URI protocols) seems to be already fulfilled?

So in the spirit of getting things done, this might also be a viable option to move this along and improve on it later.

Just putting this out there for any wallet dev reading this.

from cips.

@MadOrkestra we have an Issues section on our biweekly CIP meeting agenda (normally "time permitting" after CIP pull requests are introduced, reviewed & adopted) so I've put this issue there to help ensure we get as much developer attention as possible for this: https://hackmd.io/@cip-editors/90

There's a also a Cardano wallet developer community active at the corresponding CIP Discord here: https://discord.gg/J8sGdCuKhs

from cips.

@MadOrkestra this is why I think it would be safe enough to use the short asset names... but, not being a wallet implementor or being responsible for wallets misinterpreting payment links in certain boundary cases, I'm not qualified to say how safe (or unsafe).

I think @Crypto2099 would have hashed a lot of this out with CIP-0099 so I'm looking forward to seeing what he has to say about this & about the general subject.

from cips.

As I was saying above (and another reason to get lots more people brainstorming this), the devil is in the details: what if someone has a Cardano native token called MSG? It's another "boundary case" that needs to be accommodated with an exhaustively described syntax for all possibilities and associated rules for disambiguation & conflict resolution. You'd have similar collision risk with any other keyword to clarify the use of payment handles.

True. Probably using a prefix for asset names is the way to go to make this somewhat future-proof for further parameters to be added at a later date and not conflict with asset names, but sure, we need some wallet developers in this discussion first.

So developing a //payment CIP would be justifiable but could still be ineffective unless potential implementors were involved in that discussion: and as collaborators rather than critics. @Crypto2099 @Ryun1 how could one best get that community to engage in this discussion: Discord? A draft CIP?

FWIW: I made the rounds in all Discords and talked to all the wallets listed above (plus Tokeopay, who weren't aware of this CIP at all, so they too have already created their own solution... they were open to implementing however)

Not sure what else can be done. Maybe the way forward will indeed be to push down the current Path to Active, as mentioned, BeginWallet will implement and rollout full CIP13 support. And then get ppl to use it, so it gets the publicity CIP-99 got when Hosky started using it.

from cips.

Thanks @Crypto2099 for pushing onwards, I think this is the way to go and we'll hopefully be able to put CIP13 live once BeginWallet (and hopefully others, still trying to push Yoroi) rolls out full support.

Just leaving this here, so I don't forget for the new Payment Authority CIP: As we are doing this right now, from a UX point of view it'd be great to have a callback URL the wallet hits/visits after the transaction is complete or denied. This would enable further actions on the payment frontend, because other than waiting for the transaction to arrive, there is no way to know if a user actually did scan the QR code / clicked the link and took further action. This has multiple implications again, URL length just being one of them, but I have some ideas on this.

from cips.

• acceptance of the much simpler syntax of asset-names-as-keywords (or asset fingerprints, if you have the space in the URI for it) rather than other longer, more awkward, more restrictive naming conventions for the "payment array"
• outlining an efficient and secure means for wallets to interpret payment URIs using "short asset name" (e.g. WMT rather than its asset fingerprint)... because without these, users might not be incentivised to use these multi-asset payment links.

I have to read up on CIP-0026 for this, you might already know: Couldn't this be at least mitigated to some extend if wallets would validate short asset names against the Cardano token registry? Aren't ticker symbols in there individual without duplicates? Of cause this would only be half a solution as not all assets are in the registry.

from cips.

On the second advancement idea: Adding "metadata" for payment links, I think it could really be as easy as adding a "&msg=whatever" to the URI scheme which gets put into the already available msg field in the tx metadata?

Implementation would need the usual splitting of that URL encoded string if it exceeds 64 characters, but that standard is already defined.

Only limitation would again be the URL-length limit, which is up to the creator of the URL to take care of.

For the use case of matching transactions on the backend of a payment system, this would already be sufficient. All you would do is throw your unique identifier in there. Probably best to keep this simple at this point and if payment systems arise with a more unique metadata requirement, this could/should be an own CIP?

from cips.

could really be as easy as adding a "&msg=whatever" to the URI scheme

As I was saying above (and another reason to get lots more people brainstorming this), the devil is in the details: what if someone has a Cardano native token called MSG? It's another "boundary case" that needs to be accommodated with an exhaustively described syntax for all possibilities and associated rules for disambiguation & conflict resolution. You'd have similar collision risk with any other keyword to clarify the use of payment handles.

I'd suggested in one of our latter CIP-0013 PRs that we should have a //payment authority with a new CIP for it, but going ahead with it now might lead to the same stall we saw after I added the specification for //stake and then nobody adopted it due to lack of commercial interest: not just from wallet developers but pool analytics providers (most of whom had something to lose from easy reassignment of stake from their well-known pools).

So developing a //payment CIP would be justifiable but could still be ineffective unless potential implementors were involved in that discussion: and as collaborators rather than critics. @Crypto2099 @Ryun1 how could one best get that community to engage in this discussion: Discord? A draft CIP?

from cips.

As additional "motivation" — for both this issue participation & related CIPs — it would be helpful to surpass Solana in this aspect: given their facility is completely centralised & ours would be generally decentralised. 🧐 [external news article from today] https://cointelegraph.com/news/new-solana-feature-allows-crypto-transactions-any-website

from cips.