[Draft] [ICRC X] Content type for consent message #215
Conversation
baolongt
commented
Oct 25, 2024
baolongt
commented
- This specification inherited functionalities from ICRC_21 standard
- This specification return the consent message based on request and support by the canister
|
Dear @baolongt, In order to potentially merge your code in this open-source repository and therefore proceed with your contribution, we need to have your approval on DFINITY's CLA. If you decide to agree with it, please visit this issue and read the instructions there. Once you have signed it, re-trigger the workflow on this PR to see if your code can be merged. — The DFINITY Foundation |
baolongt
changed the title
|
Would be interested to hear the use cases of the content type added in this ICRC-21 extension. The main purpose of the ICRC-21 standard is to "Return a human-readable consent message for the given canister call" e.g. transfer 10 ICP to XYZ. In the standard, this message can be returned as either rich markdown (browser wallet) or plain text for line displays (e.g. HW wallet). How does content type relate here? I see in your MR an example with a JSON structure that contains both a plain text message and the transaction details. For the common use case of an (ICRC standardized) token transfer you wouldn't need ICRC-21 to get the transaction details, instead you could decode the candid arguments if the method name is recognized as e.g. icrc1_transfer. Just to clarify, the ICRC-21 standard is primarily meant to generate consent messages for canister calls that are not standardized ICRC contract calls like e.g. icrc1_transfer. This enables for e.g. HW wallets to approve any canister call even if the call is not a standardized call like e.g. icrc1_transfer. If you have time, also consider joining us in the bi-weekly Identity & Wallet Standards WG meetings. The agenda with zoom links can be found here: https://calendar.google.com/calendar/u/0/[email protected]&ctz=Europe/Zurich |
You're right. I just want to extend the ICRC-21 but didn't have any vision about what should schema it so I just put all the stuff in consentMassge |
|
But in my case, I really need a similar things to consent message but showing what asset user need to send and what it is will return. I think it's best fit with JSON and thinking about content_type for ICRC_21 |
Could you clarify this further, possibly with an example with how this would be used? |
You can see in the image |
MarkdownFirstly wanted to clarify that text in combination with tables is possible with (extended) markdown. Keep in mind that the signer is responsible for rendering the markdown, so details like the table widths being equal and rounded corners might vary between signers. Design 1**You will receive**
| | Amount |
| :---- | --------: |
| Asset | 1 ICP |
| Asset | 15 ckUSDC |
| Asset | 100 BOOP |
**You will send**
| | Amount |
| :-------------------- | ---------: |
| Network fee ($0.0008) | 0.0001 ICP |
| Total fees ($0.0008) | 0.0001 ICP |You will receive
You will send
Design 2| Swap | |
| :------- | ------------: |
| USD Coin | +1,00053 USDC |
| Solana | -0,005272 SOL |
| Fees | |
| :------------ | ----------: |
| Mang luoi | Solana |
| Phi mang luoi | 0,00013 SOL |
Data instead of message?As far as I understand, this PR returns a JSON structure (data) instead of Markdown (message). The given wallet is expected to interpret the JSON structure and render an interface . Besides the question whether this should be done by adding an asset type or another device type besides the The main question I have here, is how would a signer know how to render said JSON (data) to the screen? Keep in mind that the signer does not know what kind of call it's supposed to be rendering on the screen. The signer could receive for example a call to: transfer ICP, swap tokens, delete an account, sign up for an account, etc. In the given two examples above there's already two different transaction types with different designs. As far as I can see from the design, the first one shows multiple assets being received while the second design is a swap. The main purpose of ICRC-21 is to receive a consent message (in human language) that the signer can render "as is" without prior knowledge of the type of canister call that's being made. In case of JSON (data), the signer would need to know all the various possible JSON structures and implement an interface for each one. Which extends on my earlier question, how would a signer maintain and keep adding support for this growing list of JSON structures? ICRC canister callsIn case of canisters calls that follow the ICRC standards, a signer could add a custom implementation for a given standard e.g. ICRC-1. This custom implementation would recognize that a call is an ICRC-1 transfer and as a result decode the candid arguments and use these arguments to render a custom interface directly. An example of decoding ICRC-1 transfer arguments can be found here. The purpose of ICRC-21 is to primarily handle all the canister calls that are not standardized, and thus the signer does not have a decode and custom interface implementation for. Standardizing swaps and other related common transactions in ICRC standard(s) would enable signers to add support for decoding their arguments and rendering a custom interface. TL;DR
|
The ICRC21 is programable for consent message. So the JSON returns will be a public schema for all develop integrate with the canister. I think this will lead to another topic that how should the schema is.
Do you think we should define a JSON for general purpose? Can we define a ICRC for a JSON schema? |
Isn't that what the candid definition of a canister is meant for? The candid definition of a canister is basically a public schema of the canister and all of it's calls and arguments.
Why not define a ICRC standard for the candid definition of said canisters(s) like ICRC-1 and other ICRC standards do? The added benefit of this more common standardization approach is that it also documents the canister calls themselves for other canisters besides signers. Just to clarify the purpose of ICRC-21 is to return a consent message, something a signer can always display without any prior knowledge of any other ICRC standards. If ICRC-21 returns something other than a consent message, for example a JSON schema. Then I'm not sure if this is still within the scope of ICRC-21, since it's no longer a generic message that can be rendered without prior knowledge. Also in case of a swap platform, it probably won't need ICRC-21 since it could use ICRC-34 delegations to avoid the need of going through the signer when calling its own platform canister(s). So above swap examples will be able to show a well designed confirmation popup within the dapp itself without any signer approval screens needed. |
|
So this mean my ideal (picture 1) is like just in my dapp problem to show consent message before claim something rather than a general solution for canister communication from signer? |
In practice a swap flow could look something like this:
Only in step 1 the user has to approve in the signer, step 2 and 3 are all within the dapp itself. Ideally you'd only have signer interaction to access the user funds (ledger canisters), for interaction with the dapp itself (dapp own canisters), there's no need for signer interaction. The purpose of ICRC-21 is to have something (a message) to show in case there's no other choice besides signer interaction and the canister call is not ICRC standardized like e.g. an ICRC-1 transfer of ICRC-2 approval. Ideally you'd try to avoid going through the signer for interaction with the dapp itself. |
