I’ve personally built this a few times for a few different services, and yes, it would be awesome to standardize it. There is a bit of a conundrum around if you want the deposit addresses to be deterministic or private. Or deterministically private? Or rotate? If we defined the derivation and it would be fairly simple to write the component to manage it all.
Announcing "Token Standard" as topic of the first meeting of the Ledger & Tokenization Working Group
Looks like I’m the only one on the call today so I’m going to drop off. Hopefully, we can get a bit more organized in next couple of weeks. Timo’s idea is interesting and we could tackle that.
Thanks!
So if I want to make a draft I just pick any ICRC number that isn’t used by any of the existing issues? Or are there numbers reserved already that don’t appear in the issues?
Just create an issue with an indication of what you want to use it for and then the number is yours.(the issue number assigned)
The best is, as Austin mentioned, to create an issue here: Issues · dfinity/ICRC · GitHub
The issue number x you receive is your ICRC number.
Then you can create a subdirectory icrc-x in the ICRCs directory of the https://github.com/dfinity/ICRC repository with your initial or empty draft if you want to develop it in public.
There is some tooling available to generate a Candid file from a standard specification and lint it if you use the according markup to annotate your Candid type and method definitions. See, e.g., ICRC-7 as example. The tooling is not deployed in the ICRC repo at this point.
Hope that helps!
Does anyone have suggestions for the WG call tomorrow, May 14?
We could talk about ICRC-2: It is practically impossible for users to manage allowances · Issue #186 · dfinity/ICRC-1 · GitHub and potential solutions to this. The only problem is that I’m not sure I’ll be able to join as I have another meeting overlapping. I’ll see if I can move the other meeting so that I can join.
1 Like
@mariop This is a great idea, but only makes sense if you can join. Would be great if you could move your other meeting. Thanks!
I will be in the WG today, the other meeting was moved. I proposed we discuss about the problem and a potential solution and its implications. I’ll prepare the slides and drive the conversation.
We cut the meeting short this afternoon and have the following agenda for the meeting in 2 weeks:
- The issue ICRC-2: It is practically impossible for users to manage allowances · Issue #186 · dfinity/ICRC-1 · GitHub and potential solutions to this. @mariop is preparing the content and ideally already a concrete proposal to discuss.
1 Like
In tomorrow’s WG meeting we will be discussing proposed improvements to ICRC-2. See ICRC-2: It is practically impossible for users to manage allowances · Issue #186 · dfinity/ICRC-1 · GitHub. @bogwar will be leading the session and making a proposal.
Hope to see many of you in the meeting tomorrow!
1 Like
Can’t find a link to the WG meeting, any suggestions where I can find it? Don’t see any zoom link in the agenda.
Hi @sea-snake, only seeing this now after the meeting. There is a Google Calendar link in the top of the topic.
The Zoom link is in the calendar. As it may change, please import the calendar and always use the most recent link there. The current one is this.
If any proposal was presented in the session, is there any link I can check? The earlier issue link only describes the issue but doesn’t have any links to a proposal yet.
Regarding the topic, since a wallet already needs to keep track of allowances anyway (to check if a transfer_from is allowed). I don’t see why there can’t be a method to return these allowances. In ICRC-37 there’s also methods to get a list of approvals for similar use cases.
Relying on the index canister only seems logical for historical state, but as far as I understand, allowances are an ongoing state until they expire or reach 0, they’re used and needed within the canister to do a transfer_from.
Yes, a proposal was presented, @bogwar will post the slides shortly here for reference. We can continue the discussion on the forum.
Here’s the slides I’ve used for the discussion.
1 Like
My suggestion was to grab a new ICRC Number and update the function to something like the following to follow the emerging pagination standards in ICRC 7,etc.
icrc84_list_allowances(filter: opt Account, prev: opt Allowance, take: opt nat);
There was some discussion about needing to add this to ICRC37, but as you pointed out, I think we already have icrc37_get_token_approvals and collection approval that would let a service check for approvals on owned NFTs which may be sufficient.
Tomorrow, June 11, we will continue the discussion of the most recent Working Group meeting. See here for a link to the recording of the meeting, minutes are not available for this meeting.
The proposal for the discussion for the WG meeting this afternoon is to have a look at how standards can be “extended”. There is currently a concrete example available that would require an extension that is merely a clarification, but not adding new / different normative parts to the standard.