You can indeed not create an approval for a token you don’t own. When a token is sent, all token level approvals for that token will also be revoked.
The collection wide approval was intended for approvals that persists even when a token is transferred and for any tokens you haven’t yet received.
So yeah, I think we’re fine here as is.
I’d agree that we should be fine for ICRC-37 as is.
Regarding the comment on ICRC-37 on GitHub, we discussed this again in the ICRC-1 WG meeting and came to the conclusion that we do not need to have a method to expose ICRC-37 metadata in ICRC-37, but that the ICRC-37-specific metadata (e.g., icrc37:max_approvals_per_token_or_collection and icrc37:max_revoke_approvals) is returned by the metadata method icrc7_collection_metadata of the base standard (ICRC-7 here). This makes it easier for implementers as they only need to call one method to get all the metadata. With the prefixes of metadata items (e.g., icrc37:max_approvals_per_token_or_collection), it is clear to which standard implemented in a system this metadata item applies. So we don’t loose anything from not having the separate method. However, we think that the methods for accessing the individual metadata items should be in ICRC-37, e.g., icrc37_max_approvals_per_token_or_collection and icrc37_max_revoke_approvals should be there in ICRC-37.
This approach would be suitable to be established as a best practice for ICRC so that not every project needs to rediscuss this.
We also discussed that it makes sense to add the following new metadata as advanced generic ledger implementations can benefit from knowing those metadata attributes:
I’ll implement those changes this afternoon unless hearing back negative opinions related to those ideas. Those changes are within the scope of what the WG has voted on and do not invalidate the votes.
ICRC-7 and ICRC-37 next steps
As the ICRC-7 and ICRC-37 are considered final now, perhaps modulo some small / editorial changes if we see issues, the next step is to present it in one of the upcoming Global R&D meetings, ideally, the public one, and then go for an NNS vote.
New topics for the NFT WG
We also need a new topic to continue work on. This is, most probably, the full NFT standard with integrated marketplace that @skilesare has already made a draft for. Any other suggestions for our next topic?
@skilesare, @benji , @sea-snake, @kayicp, all
I’m thinking can we discuss on the transactions/block log/archive? or do we have to wait until ICRC-3 (ICRC-1 transactions log) is finalized?
I would also like to start discussion about metadata, would be nice to see one or multiple standards for concepts like images/media per NFT, attributes etc.
oh looks like icrc-3 will take a long time.
I think we need to use ICRC-3, otherwise we have too many different standards around. As you mentioned, ICRC-3 will take some more time. Maybe going with a stop-gap solution until ICRC-3 is ready would make most sense.
Noted, we are adding this to our work backlog. Currently we have the following on the backlog:
Please see below for a possible modification to make things a bit simpler for us all:
Also, looks like ICRC3 will have slight modifications, so we need to update the standard.
I have meanwhile updated ICRC-7 and ICRC37 to be compliant with the recent changes to ICRC-3. Another update concerned to already use ICRC-61.
In the context of the discussions regarding dynamic NFTs, I would like to bring up the question of reading parts of very large metadata to overcome the message size limit of 2MB for very large metadata. This limitation may currently prevent certain use cases with large metadata or require that certain metadata elements be moved out into an on-chain file system. This has also been discussed earlier and I would like to bring it up again because it may be important for adoption. This is probably a controversial proposal to make now.
In the spirit of a simple, yet powerful ICRC-7, partial metadata queries would allow to overcome the 2MB limits by allowing to query arbitrary parts of a Value. The idea is essentially a very lightweight and readily available variant of functionality that is expected to become available in the context of the upcoming standards for metadata and is not thought of a replacement thereof, but rather to give the basic standard enough functionality to be applicable to a wide range of use cases.
The proposal is to either extend ICRC-7 with a simple mechanism to achieve partial metadata queries of define a new ICRC standard that extends ICRC-7 with this functionality. The core part of such extension or proposal is a language for referring to parts of a Value and definition of a method for partial metadata queries.
A canonical way to refer to a part of a metadata Value is to refer to the sequence of Variants or fields one needs to traverse from the top-level Value to the target element.
Canonical solution: Use /path/to/target/element to traverse through the tree implied by the Value until the target element is reached.
Example:
Consider an NFT for an in-game item that has an item_info array of properties that can change during gameplay, assuming the metadata is structured as proposed here for dynamic metadata.
/Map/dynamic/Value/Map/item_info/Value/Array[1] could refer to the second array element contained in the dynamic element item_info contained in the Map of the Value in the dynamic part of the NFT metadata. The root / corresponds to the Value instance being addressed, the following Map being the variant thereof.
Value/Map/dynamic would give us the full dynamic metadata element in the form of a Value.
/ is the whole Value
/Map would not be valid as it would not return a Value, but a vec record
The batch interface of the method for querying partial metadata is defined as follow, where a list of token_ids is given and for each token_id a list of vpaths (value paths) to query in its metadata. The interface is positional as usual for ICRC-7 in that the i-th response element is the response to the i-th request element.
icrc7_partial_metadata(vec token_id, vec vec vpath) -> vec vec Value
Allowing a vector of queries per request is likely good enough for capturing a large number of use cases and it is still simple. Further extensions to make it more powerful, more towards what XPath offers, is likely not really important for most use cases, but a discussion is required here.
Without this method for accessing parts of the metadata of an NFT, the overall NFT metadata size is constrained to the maximum response size of the ICP, 2 MB. This partial read allows for large metadata Values to be defined and then only parts to be read in one go. Hashing large metadata for ICRC-3 is possible without issues, even if various metadata items are stored in different canisters, as the overall hash is computed by combining hashes of its constituents in a well-defined manner. Thus, adding this method would make the current standard applicable to a wider range of use cases without a big effort.
Having this extension available would allow ledgers to spread their metadata over multiple canisters as they want and allow for arbitrarily large metadata structures. They need to make sure that each “node” of the Value of the metadata be smaller than 2MB. This does not impose undue constraints and can be accomplished by a design that puts all large assets in their own nodes that can be retrieved individually.
This is a strictly additive change and does not invalidate parts that have been implemented already in the various ongoing implementations, thus it should be fine to add in the current late stage to ICRC-7. It would add value in terms of overcoming the 2MB message size limit without adding much complexity. With such extension and solving the dynamic metadata issue, the NFT standard could be considered complete, yet still very simple.
What do others think about this? Any (strong) reason to not add this extension to ICRC-7 or define an extension standard?
Let me propose the below agenda for the WG meeting tomorrow, March 12.
Agenda
tx field containing the tx-specific fields (as before)icrc61_supported_standards method once and for all ICRCsmemo at the top-level used for? Can we remove it? It may be a left over from an older version and not needed any more. There is now a memo field defined in the tx record.Very happy to see here, I am working on the SFT (Semi-Fungible Token) for ICPanda Badges system, which will implement the ICRC-7 and ICRC-37 standards.
Thanks for your post above, this is great to hear, @zensh! SFTs on ICP is something I am really interested in and I think is in need for many asset tokenization projects in the future. Would be really interested in learning more about your project!
Also, you might want to consider joining the NFT Working Group!
Just as a reminder, here is the calendar link with all the working groups. The NFT working group is taking place every other Tuesday 17:00-18:00 UTC+1 (or UTC+2 in summer time).
Summarizing the main decisions of the meeting:
ICRC-1 is one of the returned supported standards, then the standard implementing ICRC-61 (ICRC-1 in that case) needs to also implement icrc1_supported_standards. This is important for making sure that standards that aim to implement ICRC-1 do not accidentally drop support for ICRC-1’s own icrc1_supported_standards method.ICRC-61 must always be returned as one of the supported standards by a standard that implements ICRC-61.memo in the ICRC-3 block definition of ICRC-37 can be removed.7update field for updates of NFTs / their metadata.These open questions after the WG meeting this afternoon remain:
7update that allows to encode the nature of the update, e.g., what triggered it. This could be done with a separate field (transform in ICRC-60) or by using the memo that is already defined.7update block needs either the content that has changed or a hash thereof.
7update method essentially a metadata update or a more general update method?Thanks for your feedback!
There’s one open item to be addressed.
See here, and below (emphasis is mine).
type field of the block MUST be set to "7mint"tx field
tid: Natfrom: Accountto: Accountmeta: ValueNote that tid refers to the token id. The size of the meta field expressing the token metadata must be less than the maximum size permitted for inter-canister calls. If the metadata is sufficiently small, it is recommended to add the full metadata into the meta field, if the metadata is too large, it is recommended to add a hash of the metadata to the meta field. // FIX best practices for modeling metadata or hash
Do we want to recommend that the plaintext metadata be added to the block in case it is small and a hash otherwise? The further may be a bit underspec’d (e.g., how to encode it, the obvious would be the canonical encoding of the Value).
Opinions welcome.
@sea-snake, @skilesare, @benji, @kayicp, @ all
The NFT standards have been updated to reflect the recent changes to ICRC-3.
What remains is to copy the Candid definitions into the respective .did files and deciding on the fix mentioned in the above post.
Yes to include metadata or hash. Yes to having the hash be the canonical rep-indy-hash of the Value.
If the metadata were a #Blob(image bytes) or something like that it might get confusing to assume that a blob here is a hash or a file. Maybe different fields with an ‘or’ requirement.