CIP-0158? | Cardano URIs - Browse Authority #1058
Conversation
…ano and deep-link capabilities for application support.
|
Note that this CIP attempts to address some of the concerns in CIP-0016 and |
rphair
added
Category: Wallets
rphair
changed the title
There was a problem hiding this comment.
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
Co-authored-by: Robert Phair <[email protected]>
rphair
changed the title
There was a problem hiding this comment.
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.
|
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? |
|
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? |
|
yes please |
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? |
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... |
Co-authored-by: Robert Phair <[email protected]>
Co-authored-by: Ryan <[email protected]>
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 |
- Introduce versioning to URI scheme - Clean up some grammatical errors - Add explanation of security benefits and considerations section to the motivation - Update some parts of implementation plan that have been completed.
rphair
added
State: Confirmed
| ``` | ||
| web+cardano://browse/<version>/<scheme>/<namespaced_domain>/<app-specific-path>?<parameters> | ||
| ``` | ||
|
|
||
| * **Authority (REQUIRED):** `browse` | ||
| * **Version (REQUIRED):** `v1` | ||
| * **Scheme (REQUIRED):** `https`, `http`, `ipfs`, etc. | ||
| * **Namespaced domain (REQUIRED):** reverse domain name (e.g., `fi.sundae.app`) | ||
| * **App-specific path (OPTIONAL):** full, url-encoded path within the app | ||
| * **Query parameters (OPTIONAL):** optional, url-encoded query parameters passed | ||
| as-is to the app |
There was a problem hiding this comment.
Hey @MadOrkestra @Crypto2099 This is not ideal, and doesn't actually work on some android devices.
For the following:
web+cardano://browse/v1/https/store.jpg/listing/22978160
Multiple android devices just do not like what's being parsed and remove the / after http:
There was a problem hiding this comment.
We do not plan to integrate it as such since it's not working reliably on all devices/platforms and is not technically the correct way to include URLs in a deep link. We'll instead implement the following for VESPR:
web+cardano://browse/v1?uri=https%3A%2F%2Fjpg.store%2Flisting%2F22978160
Where:
- Scheme (REQUIRED):
web+cardano - Authority (REQUIRED):
browse - Version (REQUIRED):
v1 - Query parameter
uri(REQUIRED): percent-encoded uri to open in the app
If URI query param has no scheme, https is assumed
Note: We do not plan to support anything other than http or https at the moment. And I don't think this CIP should allow it?
Note 2: We also don't plan to namespace the domain. Not sure what the reasoning behind this was?
There was a problem hiding this comment.
Hey Alex, good catch, I wasn't aware of this errr lets call it "feature" (I guess https://domain.com/https/something wouldn't work as a QR code either then?) - this needs to be mitigated for sure.
(Just FYI: there is no RFC forbidding protocol names in webserver paths, but if Android can't handle this, it doesn't really matter)
As for protocols I absolutely believe this CIP should support allow other protocols besides http and https. This is web3, seems very likely at some point in the future we'll have pages running on IPFS or whatever other decentralized protocols come around in the next years?
There was a problem hiding this comment.
I am fine with the simpler web+cardano://browse/v1?uri=https%3A%2F%2Fjpg.store%2Flisting%2F22978160 url encoded implementation btw - we could use versioning for the protocols and just do http & https in v1 for now as IPFS is gateway only anyways?
I think the namespacing was meant to make whitelisting easier on the wallet end? @Crypto2099
(doesn't make a huge difference though, not that hard to extract a domain from an URL...)
There was a problem hiding this comment.
I don't think namespacing changes much for how easy it is to whitelist or blacklist 🤔
Regarding http/https scheme: Supporting by default any scheme is not technically possible, cause everything needs explicit handling:
- http/https scheme: needs loading directly in webview
- ipfs scheme: needs a gateway to resolve, plus some conditions/restrictions on what type of ipfs things we support: websites only? what about images? videos? pdfs? etc?
- other scheme: we cannot possibly know what needs to be done
My suggestion: Let's keep this http/https only so that we can have a clear implementation that covers 99.9% of the use-cases
Adding other scheme support should be a separate CIP, but we don't need to explicitly mark it as v2, since it's not a breaking change (this way we maintain backwards compatibility for http/https scheme)
There was a problem hiding this comment.
As promised / expected this is a tentatively positive review for this proposal after a more detailed read: in my understanding it doesn't lack anything in detail or proposed usage.
@Crypto2099 as also expected I believe the editors will have to wait until responses like that of @AlexDochioiu's #1058 (comment) are accommodated: probably through a convergence process between in-progress implementations and the proposed ideal. Will keep following those revisions and certainly ✅ and move this forward as soon as those details are settled somehow.
| * Parse and validate version, scheme, and domain. | ||
| * Forward the entire app-specific path and query string to the app. | ||
| * Apply allowlist/blocklist and security policies: | ||
|
|
||
| * Warn on `http` and `localhost`. | ||
| * Allow `https` by default. | ||
| * Resolve `ipfs` via trusted gateway or native resolver. |
There was a problem hiding this comment.
| * Parse and validate version, scheme, and domain. | |
| * Forward the entire app-specific path and query string to the app. | |
| * Apply allowlist/blocklist and security policies: | |
| * Warn on `http` and `localhost`. | |
| * Allow `https` by default. | |
| * Resolve `ipfs` via trusted gateway or native resolver. | |
| * Parse and validate version, scheme, and domain. | |
| * Forward the entire app-specific path and query string to the app. | |
| * Apply allowlist/blocklist and security policies: | |
| * Warn on `http` and `localhost`. | |
| * Allow `https` by default. | |
| * Resolve `ipfs` via trusted gateway or native resolver. |
I think the double- or 1½-spacing anomaly on GitHub markdown rendering is due to this extra blank line in the middle (it makes the line pitch of this list different than the others in the document).
| - [ ] At least one major Cardano wallet implements support for the browse | ||
| authority in web+cardano URIs, including launching its embedded browser with | ||
| the specified path. | ||
| - [ ] At least one dApp publishes deep links or QR codes using the browse scheme | ||
| that work reliably across supported wallets. |
There was a problem hiding this comment.
It could be that @Ryun1 as in earlier cases will demand 2 implementations (each: for both browser & browsed) but unless he or @perturbing posts as such I would accept it as written... mainly because the first demonstration of such a process, especially when validated on the mobile platform as mentioned further below, is likely to gain notoriety quickly and encourage imitation from other wallets/apps almost immediately: effectively bringing it out of the Proposed condition even before those newer implementations go live.
6 participants
This CIP seeks to define the
browseauthority forweb+cardanoURIs. 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: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