CIP-0158? | Cardano URIs - Browse Authority

[Crypto2099]

This CIP seeks to define the browse authority for web+cardano URIs. The intent here being to easily enable deep-linking capabilities for Cardano mobile wallets to launch their native embedded browser to the specified application or URL. This should be particularly useful in things like point-of-sale systems and for sharing applications in the wild versus the current process which can be rather clunky requiring users to:

1. Open the wallet
2. Find the wallet's application browser
3. Search or manually type a URL to the application

Note: Due to personal time constraints I did use some AI assistance in drafting some of the language of this pull request but the concept behind the scheme is mine (and inspired by the existing work of @francisluz and Begin Wallet) and all language has been reviewed and edited by myself personally.

View Rendered Document in Branch

[Crypto2099]

Note that this CIP attempts to address some of the concerns in CIP-0016 and

• CIP-0013: Current state of integration and further advancements #836

[rphair]

thanks @Crypto2099 - I like too many things about this proposal to enumerate them all here 😅 so I hope it will suffice to say I will get behind it 100%, though also with care to ensure through peer review that:

• the URL scheme is sufficient to cover any needed parameter passing into targeted applications with no ambiguity;
• any presented scenarios for insecurity, obfuscation of malicious apps, or other abuse are explored & documented (even if they seem trivial at the time).

Looking forward to hearing your introduction of the CIP from the agenda of our next meeting 🚀 https://hackmd.io/@cip-editors/116

[rphair]

Confirmed at yesterday's CIP meeting that this satisfies a clear & present need in the community — especially for moving quickly from presentation to wallet environments, and from desktop to mobile environments — also confirming the additional security motivation I mentioned in #1058 (comment).

Personally I expect to ✅ this after a mental walk-through of some deployment scenarios — somewhat naively since @Crypto2099 I don't have your experience in the targeted environments like conventions and token drops — and hope to do this by the end of this week: especially cross referencing with CIP-0013 family members & #843.

[MadOrkestra]

Just a random thought on the topic of verifying domains: is there an opportunity here to propose a mechanism for enhanced security / automatic whitelisting across multiple wallets? As it stands now, almost all wallets do some kind of individual white-listing for domains or have their own pre-filled catalogue of Cardano dApps, which makes sense to avoid scams, but also is very centralized as it is done on a per wallet basis.

It might be worth thinking about this for a second as this CIP will - while greatly improving the UX - basically open up wallets for all kinds of shenanigans and I can already see the reluctance to implement this.

Ofc this can't be the next centralized registry, but what about an on-chain majority vote multisig for wallets/trusted entities where domains can get verified and whitelisted on chain?

[MadOrkestra]

Otherwise: great job as always by @Crypto2099 - I am working on an Affiliate Platform rn, which will make use of this as soon as we have the first mobile wallet implementing this :)

One thought though: Maybe we go with //launch instead of //browse? This would future proof this for further applications, because I can see use-cases where this could be used to launch other wallet features than the in-app browser without the need of a new CIP?

[rvcas]

yes please

[Crypto2099]

Otherwise: great job as always by @Crypto2099 - I am working on an Affiliate Platform rn, which will make use of this as soon as we have the first mobile wallet implementing this :)

One thought though: Maybe we go with //launch instead of //browse? This would future proof this for further applications, because I can see use-cases where this could be used to launch other wallet features than the in-app browser without the need of a new CIP?

If we decided to change this, how would we indicate that, in our case, we want to launch the built in dApp browser instead of... idk... a built-in "Purchase ADA" function?

[Crypto2099]

Just a random thought on the topic of verifying domains: is there an opportunity here to propose a mechanism for enhanced security / automatic whitelisting across multiple wallets? As it stands now, almost all wallets do some kind of individual white-listing for domains or have their own pre-filled catalogue of Cardano dApps, which makes sense to avoid scams, but also is very centralized as it is done on a per wallet basis.

It might be worth thinking about this for a second as this CIP will - while greatly improving the UX - basically open up wallets for all kinds of shenanigans and I can already see the reluctance to implement this.

Ofc this can't be the next centralized registry, but what about an on-chain majority vote multisig for wallets/trusted entities where domains can get verified and whitelisted on chain?

I have thought about this and I spoke, once upon a time quite some time ago when CIP-88 was first making the rounds, with a few folks at CF who were responsible for the off-chain token registry... This was specifically related to how we would confirm the veracity of smart contract minted tokens but the same concept stands. I wonder if there's something along the lines of CIP-0155 (#1033) in terms of special DNS entries and other security mechanisms that could be implemented to increase trust in a decentralized fashion w/o going full Black Mirror Social Credit dystopia...

[MadOrkestra]

One thought though: Maybe we go with //launch instead of //browse? This would future proof this for further applications, because I can see use-cases where this could be used to launch other wallet features than the in-app browser without the need of a new CIP?

If we decided to change this, how would we indicate that, in our case, we want to launch the built in dApp browser instead of... idk... a built-in "Purchase ADA" function?

On second thought: lets forget about this.

(this is what crossed my mind: I could - as an App developer - kinda go web+cardano://launch/my-btc-protocol-identifier/purchase-bitcoin - but it makes no sense to put this into a standard as multiple wallets would have to agree about this ofc)

[Crypto2099]

One thought though: Maybe we go with //launch instead of //browse? This would future proof this for further applications, because I can see use-cases where this could be used to launch other wallet features than the in-app browser without the need of a new CIP?

If we decided to change this, how would we indicate that, in our case, we want to launch the built in dApp browser instead of... idk... a built-in "Purchase ADA" function?

On second thought: lets forget about this.

(this is what crossed my mind: I could - as an App developer - kinda go web+cardano://launch/my-btc-protocol-identifier/purchase-bitcoin - but it makes no sense to put this into a standard as multiple wallets would have to agree about this ofc)

We can also, of course, just introduce a new standard at that time

[rphair]

@AlexDochioiu since we've integrated all of your suggestions I think this document can be re-reviewed by wallet representatives (and you can double-check the current state of it).

If no objections (cc @MadOrkestra) we can get ready to merge this... though still hoping for reps from other wallets to comment (by CIP editors' invitation) as requested in #1112 (comment).

I've bookmarked on my own calendar to review this at the end of next week & mark for Last Check at the meeting after that if no such objections have been raised.

[Crypto2099]

Sorry it has taken me so long to get back to this one. @AlexDochioiu changes looked mostly good and aligned with what has worked well in past demonstrations/VESPR implementation. I pulled changes and did a bit of cleanup for some sections that were affected by the inline/code review edits and this should be ready to proceed. I will update cardano-uri-parser accordingly to reflect this new method.

[rphair]

Thanks @Crypto2099 for coming back on on this. I do think it's better, all else being equal, to have an ABNF grammar (cc @AlexDochioiu) and I'm happy to have the rest of your updates.

@Ryun1 @perturbing I think it's ready for your commentary in the meanwhile or no-objection at Last Check for next meeting (https://hackmd.io/@cip-editors/129) and please @Scitz0 @refi93 @ashisherc @francisluz also indicate if you have any CIP-0158 or general Cardano URI plans that would require adjustment of this CIP candidate.

[AlexDochioiu]

Everything looks good to me in current state. I have no objections.

[refi93]

please also indicate if you have any CIP-0158 or general Cardano URI plans that would require adjustment of this CIP candidate.

Given that we (NUFI/Adalite) don't have a mobile app at the moment we don't have any plans related to this CIP

I just see that there is already CIP-0013 for the general Cardano URI scheme which I don't see being mentioned here and I think it could make sense for the sake of visibility/ensuring consistency to link it and clarify their relationship

Other than that LGTM

[MadOrkestra]

Looks good to me!

[MarcelKlammer]

We implemented this several months ago and it's live in Eternl. I need review any changes to the CIP made since implementation took place.

[MadOrkestra]

One thing comes to mind reading @refi93 comment: do we need to define how browser extensions handle (or not handle) this url authority? as they listen to the general web+cardano URI scheme?

[rphair]

@refi93 #1058 (comment): I just see that there is already CIP-0013 for the general Cardano URI scheme which I don't see being mentioned here and I think it could make sense for the sake of visibility/ensuring consistency to link it and clarify their relationship

Discussion that took place 2 years ago (about halfway through CIP editors' trying to get wallet developers to look at CIP-0013) put a general overview of the Cardano URI scheme into CPS-0016: of which CIP-0013 is now a particular solution for the 2 oldest protocols (older style payment links + //stake links).

The relationship between the CPS and the Cardano URI CIPs (including the newer protocols, also coming out about 2 years ago) was apparent for anyone actively following Cardano URIs... or even Wallet category CIPs... and will be linked more closely with a general push to pair related CIPs and CPSs, about to be merged soon (cc @Ryun1).

Most current discussion about which wallets implement which of the Cardano URI CIPs is in this issue, and @refi93 @MarcelKlammer @AlexDochioiu your ongoing participation would be welcome here: 🙏

• CIP-0013: Current state of integration and further advancements #836

[Ryun1]

discussions have reached consensus
another great contribution to the CIP process and Cardano 💪

[rphair]

We ran out of time at the CIP meeting today to present Last Check items: although in the interest of progress and avoiding bureaucratic delays I think we can merge this because of the editor quorum already demonstrated (after a full course of online review).

[MadOrkestra]

We ran out of time at the CIP meeting today to present Last Check items: although in the interest of progress and avoiding bureaucratic delays I think we can merge this because of the editor quorum already demonstrated (after a full course of online review).

so close, soooo close :D