Call for Participation: NFT Token Standard Working Group [Status Updated]

Developers
21

During the last WG meeting we decided to remove the is_atomic feature, because this would require the transfer method to be fully synchronous, which limits its use cases (eg. the transfer method might need async checks before performing the transfer).

The specs would be updated accordingly.

2 Likes
22

Can insiders give any update on this?

23

We’ve discussed and decided on almost all issues uncovered during the implementation phase (still a couple of minor issues pending). The final draft for community review will be released in about 2 weeks.

2 Likes
24

Dear NFT WG Members!

In the meeting tomorrow, Tuesday Sep 12, 17:00-18:00 UTC+2 time, we want to discuss the following agenda items:

  • Initiating the voting for ICRC-7
  • Other pending discussions, e.g., regarding the extended token standard

Talk to you tomorrow!

1 Like
25

Can you give us progress update on NFT standards @benji @dieter.sommer ?

Why is it taking DFINITY years to create an NFT standard? What is holding DFINITY back? Does the growth team want us to go to Entrepot for DFINITY endorsed “NFTs”??

If DFINITY fails to address these issues immediately, we will be creating Topics addressing the issue directly, instead of posting in replies.

26

Umm… its been more than 2 years? 35 days since update to be precise

Discussions have started in 2021.

  • July 21
27

The basic NFT standard is very close to completion and some remaining issues need to be addressed that popped up last minute in the community. Once those issues are addressed, the standard can go into WG voting and, once successful, NNS voting. So the WG is very close to finishing the basic NFT standard ICRC-7.

2 Likes
28

Very close to completion is not completion.

How many days does it take DFINITY to build a basic feature that should have been built since the genesis if at all it cared about building World Computer.

The discussions started two years ago. Now NFT ecosystem on ICP is practically dead. Ironic for a Metaverse chain.

Props to the Growth team and state of the art marketing by DFN /s. :rofl:

I’m beginning to think its not a mistake but a deliberate choice made by DFINITY. Creating dependencies and cartel like environment for rugging users and builders

No offense to @benji @dieter.sommer

29

For tomorrow’s WG meeting, the goal is to tie up the loose ends and then go into WG voting as soon as we can. Based on the discussions in the recent WG meeting, please find the update of the draft here (link contains the diff to the previous version discussed in the meeting of Aug 29).

Here’s a laundry list of open issues that need to be tackled, some of them have optimistically been addressed in the draft already.

Hope to see many of you in tomorrow’s meeting!

2 Likes
30

The latest working draft of ICRC-7 with some more updates can be found here:
ICRC-7 draft latest
Diff August 17 <> latest

Talk to you later!

2 Likes
31

Whoa, Ivan is rude…

hey @dieter.sommer how many more drafts until deployment of an NFT standard on Internet Computer?

Hope this helps :+1:

1 Like
32

I did another round of editing over the standard:
Draft

There are some open issues marked with // FIX …

Some main ones we should quickly conclude on:

  • Should we replace the current record-based metadata with one analogous to ICRC-1, where we have a generic map-like structure that can hold any metadata? I think the general agreement was yes, the only drawback is that then the Account for the royalties recipient would need to be encoded as blob which is more tedious to use.
  • Are people fine with the way batch calls are modelled in terms of their return value? The idea is to have a vector or records in the return, where each record contains the token id as first element and the corresponding response or error as variant in the second element.
  • Do we need a QueryError type as part of a potential error response for queries, or can we skip this and use only system errors in the query case, which would greatly simplify the API.

Would be great to get some feedback so we can finalize the document shortly!

1 Like
33

Good Morning Beautiful people of DFINITY

Our team has allocated 15 Hours this week to manage DFINITY OPs and speed up the process of creation of an NFT standard which is 3 years overdue.

Hope everyone had a good vacation and got plenty rest

Progress updates on NFT Standard?

35

Dear WG members!

Tomorrow Oct 10, 2023 we would like to finalize the ICRC-7 draft and start voting on it!

The draft has been substantially refined according to the recent discussions in the WG and additional considerations like, for example, the following:

  • Polishing
  • Making the specification clearer, removing ambiguity
  • Making the use of batch / non-batch methods consistent
  • Unifying the responses according to API patterns

Please find the most recent draft here.

And find a diff to the earlier draft of August 17 here.

The draft still contains a number of items labelled “FIX” that we need to discuss and make a decision on in order to can finalize ICRC-7.

Hope to see many of you in tomorrow’s meeting!

5 Likes
36

Dear Working Group!

The changes agreed in the recent WG meeting have been implemented in the ICRC-7 draft. In our opinion the draft is now stable. It is time now for the WG to have a final look over it and next to start the voting on it.

ICRC-7 current draft
Diff to version of the WG meeting of Oct 10

@skilesare, @sea-snake, @cryptoschindler, Matthew, all, please have a look over the draft and let us know whether you have any remaining comments.

Updates:

  • Minor edit addressing sea-snake’s comment on nat32 for take
  • Readibility edits to break remaining long method signature into multiple lines
5 Likes
37

This is looking pretty good. I’ll raise one issue here that may be worth thinking about(although since the items are all vecs it may not be an issue.

Do we need to review if any of the Value types or Error types need to be opt Value or opt XXX_Error for reasons expressed in this thread: ICDevs.org Voting Incident Report and Stable API Discussion

Are there any places where this would make pseudo-compatibility with an evolution of this standard easier? The result would be that nulls would be returned in place of future Value(ICRC16) or XXX_Error(If we want to add errors in ICRC8 or some other standard) that don’t match the exact variants offered without breaking compatibility. Canisters can choose how to handle unknown nulls.

I may be overthinking this. Perhaps the NNS team can weigh in here with an opinion? cc @sasuki

1 Like
38

some thoughts i had when reading the draft:

  • should we add an entry to the metadata that enumerates the generic errors by a specific implementation? together with a specific endpoint to query for them?
  • should we have endpoint for single token queries? e.g. icrc7_get_approval
  • transaction deduplication section mentions ICRC1
  • icrc7_collection_metadata
    • seems cumbersome, try assembling ICRC7 suggested fields
    • why not follow cap and have (Text,Value) tuple or vec record { text; Value } at the top level
    • do we need to prefix suggested metadata fields with icrc7 as well?
  • icrc7_token_metadata
    • doesnt specify Metadata type
    • what is the behaviour if token id does not exist? will it just not be in the response or will there be an explicit error?
    • should this be compliant with behaviour of icrc7_owner, meaning return a Result
  • icrc7_owner_of
    • says null is returned if token doesnt exist, but lists variant with Err case that contains NonExistingTokenId
  • icrcr7_balance_of
    • why not 0 instead of null
  • icrc7_tokens & icrc7_tokens_of
    • should we add default value for take to metadata and create own method to query? like for batch size and approvals?
  • icrc7_approve_tokens
    • multiple approvals can exist for the same token_id but different spender s and subaccount
      • ^ what does this mean? different spender already suggest difference subaccount?
    • emphasize that spender subaccount is arbitrary as we only check principal when actual transfer happens
    • what error do we throw if the token id doesn’t exist?
    • in what case do we throw TemporarilyUnavailable?
    • expires_at semantic should be explained
  • icrc7_approve_collection
    • text seems wrong, duplicate response text
    • candid method has the wrong name, candid types are missing
  • icrc7_transfer
    • here we say if the token doesn’t exist, we throw Unauthorized. should this be adapted to the above methods where i raised the issue?
    • do we need deduplication? if the token id is transfered, calling transfer should already throw Unauthorized :thinking:
    • we should add the created_at_time hint for the approve methods as well
  • icrc7_revoke_token_approvals
    • mention that only owner can revoke approvals
    • mention what happens when token does not exist
    • why is spender opt?
  • icrc7_revoke_collection_approvals
    • why does this return a vector? should be analaogue to approve_collection, so either add it there as well or remove for both
    • should be called icrc7_revoke_collection_approval instead of approvals
    • candid types are missing
  • icrc7_revoke_all_collection_approvals
  • this should either contain more information in the return type, so that it is clear to which collection wide approval the response belongs (e.g. via from_subaccount and spender) or fail/succeed atomically and only return one result instead of a vector
  • icrc7_is_approved
    • typo in ac
3 Likes
39

Yeah I remember we discussed this in the meeting, I’ve also mentioned it in the PR now.

2 Likes
40

hi can somebody explain to me why Principal : principal; is not included?
is it because of the Account type?

image
image783×433 21.4 KB

1 Like
41

Principals can be easily represented with a blob. I like having a specific type and offering intentionality and suggested ICRC16 which has all candid types, but the group went with simplicity(which is the intent of this first nft standard, so I didn’t push back too hard).

1 Like