From 4d10a09eaa26bc90ecc9fae3430ec2547c6230de Mon Sep 17 00:00:00 2001 From: Robert Phair Date: Tue, 17 Jan 2023 12:58:19 +0530 Subject: [PATCH] CIP-0013 | Adjust preamble and structure w.r.t CIP-0001 (#429) * fixed 3 broken anchors + add Categories link * update for new CIP-0001 compliance, headers, links, clarity * undoing changes that somehow snuck in from #411 * added H1 title, changed status on top level README * proofreading: markdown URL syntax corrections --- CIP-0013/README.md | 94 +++++++++++++++++++++++++++++----------------- README.md | 2 +- 2 files changed, 61 insertions(+), 35 deletions(-) diff --git a/CIP-0013/README.md b/CIP-0013/README.md index 67c92d209..33422dd4a 100644 --- a/CIP-0013/README.md +++ b/CIP-0013/README.md @@ -1,33 +1,39 @@ --- CIP: 13 Title: Cardano URI Scheme -Authors: Sebastien Guillemot , Vicente Almonacid , Robert Phair -Comments-URI: -- https://github.com/Emurgo/EmIPs/pull/2 -- https://forum.cardano.org/t/cip-cardano-payment-uri-scheme/41457 -- https://github.com/cardano-foundation/CIPs/pull/25 -- https://github.com/cardano-foundation/CIPs/pull/61 -- https://github.com/cardano-foundation/CIPs/pull/86 -- https://forum.cardano.org/t/cip-stake-uri-scheme-for-pools-delegation-portfolios/40594 -Status: Draft -Type: Informational +Status: Proposed +Category: Wallets +Authors: + - Sebastien Guillemot + - Vicente Almonacid + - Robert Phair +Implementors: N/A +Discussions: + - https://github.com/Emurgo/EmIPs/pull/2 + - https://forum.cardano.org/t/cip-cardano-payment-uri-scheme/41457 + - https://github.com/cardano-foundation/CIPs/pull/25 + - https://github.com/cardano-foundation/CIPs/pull/61 + - https://github.com/cardano-foundation/CIPs/pull/86 + - https://forum.cardano.org/t/cip-stake-uri-scheme-for-pools-delegation-portfolios/40594 Created: 2020-09-22 License: CC-BY-4.0 --- -# Abstract +# CIP-0013: Cardano URI Scheme + +## Abstract This proposal describes a basic URI scheme to handle Ada transfers and links to single stake pools or weighted lists of multiple pools. -# Motivation +## Motivation: why is this CIP necessary? -#### For payment URIs: +### For payment URIs: Users who create community content often want donations as a financial incentive. However, forcing users to open their wallet and copy-paste an address lowers the amount of people likely to send tokens (especially if they have to sync their wallet first). If donating was as simple as clicking a link that opens a light wallet with pre-populated fields, users may be more willing to send tokens. URI schemes would enable users to easily make payments by simply clicking links on webpages or scanning QR Codes. -#### For stake pool URIs: +### For stake pool URIs: Centralised sources of information have led a growing amount of stake to be disproportionately assigned to pools pushed near & beyond the saturation point. @@ -41,7 +47,7 @@ Pool links allow for interfaces to initiate delegation transactions without requ URIs for weighted stake pool lists provide alternatives to using a JSON file to implement *delegation portfolios* in a way that may better suit certain platforms, applications, or social contexts. -# Specification +## Specification The core implementation should follow the [BIP-21](https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki) standard (with `bitcoin:` replaced with `web+cardano:`) @@ -57,13 +63,13 @@ Examples: Choose our least saturated pool ``` -## Considerations +### Considerations 1. BIP-21 is limited to only features Bitcoin supports. A similar feature for Ethereum would, for example, also support gas as an extra parameter. BIP-21 is easily extensible but we have to take precaution to avoid different wallets having different implementations of these features as they become available on Cardano. To get an idea of some extra features that could be added, consider this (still under discussion) proposal for Ethereum: [EIP-681](https://eips.ethereum.org/EIPS/eip-681) -2. Depending on the protocol registration method (see next section), browsers generally enforce a `web+` or `ext+` prefix for non-whitelisted protocols (note: `bitcoin:` was whitelisted). The prefix `ext+` is recommended for extensions, but not mandatory. +2. Depending on the protocol registration method (see next section), browsers generally enforce a `web+` or `ext+` prefix for non-whitelisted protocols (note: `bitcoin:` was whitelisted; see [registerProtocolHandler > Permitted schemes](https://developer.mozilla.org/en-US/docs/Web/API/Navigator/registerProtocolHandler#permitted_schemes)). The prefix `ext+` is recommended for extensions, but not mandatory (see [protocol_handlers](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/protocol_handlers)). -## ABNF Grammar (Proposal) +### ABNF Grammar (Proposal) This is an initial, simplified protocol definition for fast implementation; it only requires: @@ -90,17 +96,22 @@ poolticker = 3*5UNICODE proportion = *digit [ "." *digit ] ``` -### Payment URI queries +For grammar reference, see: + + - [Wikipedia > Augmented Backus–Naur form](https://en.wikipedia.org/wiki/Augmented_Backus%E2%80%93Naur_form) + - [Unicode in ABNF](https://tools.ietf.org/html/draft-seantek-unicode-in-abnf-00) + +#### Payment URI queries The amount parameter must follow the [same rules](https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki#transfer-amountsize) described in BIP-21, namely, it must be specified in decimal ADA, without commas and using the period (.) decimal separator. -### Stake pool URI queries +#### Stake pool URI queries For brevity, essential in many Internet contexts, `poolticker` must be supported here in addition to the unambiguous `poolhexid`. When there is more than one pool registered with any of the specified `poolticker` parameters (whether for pool groups which have the same ticker for all pools, or for separate pools using the same ticker), the choice to which pool(s) to finally delegate is left to the user through the wallet UI. -#### Interpretation of `proportion`: +##### Interpretation of `proportion`: * If only one stake pool is specified, any proportion is meaningless and ignored. * If all stake pools have a numerical proportion, each component of the resulting stake distribution will have the same ratio as the provided `proportion` to the sum of all the propotions. @@ -116,38 +127,53 @@ If, during a wallet or other application's development process, it is still only * any value for the first URI query argument; * any URI query argument beyond the first. -## Security Considerations +### Security Considerations 1. For payment links, we cannot prompt the user to send the funds right away as they may not be fully aware of the URI they clicked or were redirected to. Instead, it may be better to simply pre-populate fields in a transaction. 2. For either payment or staking links, we should be wary of people who disguise links as actually opening up a phishing website that LOOKS like that corresponding part of the wallet UI. 3. If wallets *create* stake pool links, the actual ada or lovelace balance should not be used literally as the `proportion` figure, to avoid revealing the identity of the wallet owner who is creating the portfolio (e.g. the proportions could be scaled to normalise the largest to `1`). -# Rationale +## Rationale: how does this CIP achieve its goals? -## Why not use Universal links, deep links and other non-protocol-based Solution +### Why not use Universal links, deep links or other non-protocol-based Solution? An alternative solution to the original problem described above is to use standard URL links in combination with a routing backend system. The routing system is used to redirect to the app's URI. The advantage of this scheme is that it allows to provide a fallback mechanism to handle the case when no application implementing the protocol is installed (for instance, by redirecting to the App Store or Google Play). This is the approach behind iOS Universal Links and Android App Links. In general, it provides a better user experience but requires a centralized system which makes it unsuitable for as a multi-app standard. -## How URI delegation portfolio links supplement use of JSON files for the same purpose +For background, see + + - [Android Developer Docs > Add intent filters for incoming links](https://developer.android.com/training/app-links/deep-linking#adding-filters) + - [Apple Developer Docs > Defining a custom URL scheme for your app](https://developer.apple.com/documentation/xcode/defining-a-custom-url-scheme-for-your-app) + - [React Native > Linking](https://reactnative.dev/docs/linking.html) + +### How URI delegation portfolio links supplement use of JSON files for the same purpose? URIs facilitate the "social element" of delegated staking and pool promotion through a socially familiar, easily accessible, and less centralised convention for sharing stake pool references and potential delegation portfolios without having to construct or host a JSON file. The processing of a JSON file delivered by a web server will depend highly on a user's platform and might not even be seen by the wallet application at all. With a properly associated `web+cardano:` protocol, developers and users have another option available in case JSON files are not delivered properly to the wallet application. -## Read More +For a CIP based on this principle, see [CIP-0017](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0017). + +## Path to Active + +### Acceptance Criteria -https://developer.mozilla.org/en-US/docs/Web/API/Navigator/registerProtocolHandler +- [x] There exist one or more wallets supporting Payment URIs. + - [x] Yoroi +- [x] There exist one or more wallets supporting Stake Pool URIs. + - [ ] TBD -https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/protocol_handlers +### Implementation Plan -https://developer.android.com/training/app-links/deep-linking#adding-filters +Survey contemporary wallet developers to suggest adoption of both feature sets, since they are likely to be considered separately: -https://facebook.github.io/react-native/docs/linking.html +- Payment URIs +- Stake Pool URIs -https://developer.apple.com/documentation/uikit/core_app/allowing_apps_and_websites_to_link_to_your_content/defining_a_custom_url_scheme_for_your_app +This survey can be conducted and/or advocated by either (ideally both): -https://en.wikipedia.org/wiki/Augmented_Backus%E2%80%93Naur_form +- Cardano sponsoring companies +- Community advocates -https://tools.ietf.org/html/draft-seantek-unicode-in-abnf-00 +## Copyright -https://github.com/cardano-foundation/CIPs/pull/82 +This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode). diff --git a/README.md b/README.md index d26a08791..b6dfd9421 100644 --- a/README.md +++ b/README.md @@ -38,7 +38,7 @@ CIP Editors meetings are public, recorded, and [published on Youtube](https://ww | 10 | [Transaction Metadata Label Registry](./CIP-0010/) | Active | | 11 | [Staking key chain for HD wallets](./CIP-0011/) | Active | | 12 | [On-chain stake pool operator to delegates communication](./CIP-0012/) | Draft | -| 13 | [Cardano URI Scheme](./CIP-0013/) | Draft | +| 13 | [Cardano URI Scheme](./CIP-0013/) | Proposed | | 14 | [User-Facing Asset Fingerprint](./CIP-0014/) | Active | | 15 | [Catalyst Registration Transaction Metadata Format](./CIP-0015/) | Active | | 16 | [Cryptographic Key Serialisation Formats](./CIP-0016/) | Active |