Non-Fungible Token standard

[arjanvaneersel]

Discussions-To:

https://forum.aeternity.com/t/aeternity-nft-token-standard/9781/16

Content URL

https://github.com/aeternity/AEXs/blob/master/AEXS/aex-141.md

[mradkov]

Can you update the specification doc to also have a full interface code block for easier readability?

[marc0olo]

thanks for your proposal, @arjanvaneersel!

I agree with @mradkov it's currently a bit hard to read.

suggestions / thoughts from my side for the moment:

• use wording extensions instead of secondary interface
• provide a getter to know what extensions are implemented, see how it is done for the AEX-9 token:
  • https://github.com/aeternity/AEXs/blob/master/AEXS/aex-9.md#aex9_extensions
• I think mintable should also be an extension as there might be cases where minting is not required.
• don't rephrase "Event" in all the events, e.g. use Transfer instead of TransferEvent
• I think the MetaInfo extension should somehow be combined with the TokenData extension
  • I like that you thought about a distinction for the data type but I am not sure if this just complicates things here in the basic NFT interface
• I would like to have an entrypoint that allows to return all tokens of a specific address
• maybe we should also think about a "swappable" extension here like we did for the AEX-9

I think it makes sense to be compliant to ERC-721 for the most common and basic functions. if some things don't make sense we could drop them or if we have other ideas we could add them.

opinions about that?

[arjanvaneersel]

@mradkov @marc0olo Included a full code block of the interfaces in the doc, as well as in this issue.

Thanks for the suggestions.

@marc0olo The idea of MetaInfo is to be similar to the Fungible Token. TokenData is typically for the NFT standard. For that reason I didn't combine them. Also TokenData is an option, not every NFT implementation might need it. Therefore I'm also having some doubts whether it really belongs in MetaInfo if MetaInfo is to be considered a standard by itself and to be similar to the FT. @mradkov, What is your opinion? I implemented an FT compatible MetaInfo based on your suggestion.

I agree with all other suggestions of @marc0olo. I will meanwhile dive into AEX-9 to see how things were done there.

[marc0olo]

personally I am not sure if a NFT (contract/collection) needs a symbol. IMO a name of the collection is sufficient. also saw some discussions about that for ERC-721 back then.

I think it's way more important to think about how we want to deal with the "real" metainfo (properties of the specific NFT ID)

[marc0olo]

we should keep the discussion alive here. will hopefully find some time again to have a deeper look.

@arjanvaneersel are you planning to provide an update or are you waiting for further responses?

@thepiwo maybe you can also share some thoughts here? would appreciate it :)

[marc0olo]

@arjanvaneersel btw I wouldn't recommend to duplicate the proposed interface on various places (issue description, separate file, ...)

we should discuss a proposal which is written in one specific place IMO. the request of @mradkov, when I understood correctly, was about improving the readability of https://github.com/appinesshq/ae-nft/blob/main/AEX-xx.md (@mradkov correct me if I am wrong 😅 )

[arjanvaneersel]

My planning was to start implementing the first batch of ideas from next week. Think everybody then had a reasonable amount of time to share ideas.

…

On Thu, Sep 23, 2021, 16:26 Marco Walz ***@***.***> wrote: we should keep the discussion alive here. will hopefully find some time again to have a deeper look. @arjanvaneersel <https://github.com/arjanvaneersel> are you planning to provide an update or are you waiting for further responses? @thepiwo <https://github.com/thepiwo> maybe you can also share some thoughts here? would appreciate it :) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#141 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABKAWCZLKCWA5FDIRSQAERDUDMTJPANCNFSM5D2RT6XQ> .

[thepiwo]

I'd say to make the code and readme style more inline with other ae contracts and AEXs:

• remove the @param comments
• use // comments instead of ///
• make parameters without leading _
• compare readme formatting with AEX-9 for endpoints
• use MUST/SHOULD descriptions in text (MoSCoW method)
• document events where they are emitted
• alias default types for better readability
• unify duplicate requires in single functions
• minters would be more performant as map(address, bool)
• safe_mint and safe_mint_with_token_data do duplicate require checks
• remove ...Event from event names
• in get_approved either remove the require or force lookup

Whats the reason to have the safe_ methods? Please include an example for onNFTReceived.
Why forbid owner to be removed as minter?
Why default to 0 for balance_of?
Why does burn make the NFT contract owner of the NFT, not actually burn?
Why consider 0 address for approvals?
Why does minting need a id passed?
Can you explain how approvals work and what they are used for?
Tests should cover all functions, requires and edge cases known (for final implementation).

Thats the things I found for now, haven't checked all function calls and checks in detail.

[marc0olo]

thanks @thepiwo! currently you shouldn't care about the actual implementation. we should agree upon the interface before digging deep into the implementation details.

but anyway there are interesting questions.

what's your opinion about having mintable as extension? IMO it shouldn't be part of the default standard

[marc0olo]

@arjanvaneersel any update here from your side? we decided in our workshop that @thepiwo and I want to actively support you here and get this standard and the implementation ready to be reviewed and tested as soon as possible. do you have some time next week to have a call to discuss this? we can do that on discord ;-)

[marc0olo]

Summary (Call between @marc0olo and @thepiwo)

• don't copy Ethereum/Solidity code-style, @thepiwo can help here
• transfer / mint vs. safe_transfer / safe_mint
  • we should probably only define and allow safe transfers to avoid sending tokens to a contract that doesn't support the token standard
  • is there a reason why we need "non-safe" transfers or why we should keep them?
• harmonize / consolidate the naming
  • transfer_single / transfer_all
  • approve_single / approve_all
  • revoke_single / revoke_all
• we could also introduce a batch transfer in our NFT standard
• metadata
  • on collection level:
    • name
    • abbreviation
  • on item:
    • see discussion below, introduce ADT
• define extensions similar to AEX-9:
  • mintable (only owner, ControlledMinting not required from our perspective)
    • do we need to provide an id for minting a new token? what use cases exist here? couldn't we just increment the id for each mint automatically?
  • burnable
    • burn should burn and set the contract as owner like in current state of implementation

Metadata

We definitely need to discuss how to deal with metadata on item level:

• should we use an IPFS hash for the metadata?
• should we point to an URL?
• should we store metadata in the contract directly?
• which format should we use? json like ERC-721?
  • what attributes should the standard define? => can be defined later on, not crucial for the NFT standard implementation

Maybe use an algebraic data type (ADT) for metadata?
Simple example:

@compiler >= 4

contract NFT =

  datatype metadata = Url(string) | Ipfs(string) | Internal(map(string,string))
  type state = map(int, metadata)
  
  entrypoint init(): state = {}

  stateful entrypoint mint(meta : metadata) = put(state{[Map.size(state)] = meta})
  entrypoint get_metadata(id : int): option(metadata) = Map.lookup(id, state)

[marc0olo]

just had some discussion with @omar-saadoun about that. the metadata topic is really interesting.

in the end we both came to the conclusion that it's definitely desired to have following possibilities:

• base_url for the whole collection where the id points to the specific metadata of the token (like known already for the ERC-721)
  • pro:
    • "trust" for people in a common scheme
    • easier to handle ?!
  • cons:
    • the URL can be obsolete at some point of time (maybe not an issue at all as the NFT would probably also obsolete then)
    • data behind the URL can be changed and is thus mutable
• ipfs_hash for each unique token
  • pro:
    • immutable data
    • services consuming the data can use their own (or preferred) IPFS gateway
  • cons:
    • ???

the question is how to ideally reflect this in the contract. maybe we even want to have the possibility to add metadata "internal" in the contract (e.g. stored in a map) like mentioned above. @thepiwo any suggestions here? especially as we want to avoid having a custom URL for each NFT. it totally makes sense for the URI to introduce a baseUrl instead of having a unique URL for each NFT.

@omar-saadoun please edit / comment with additional feedback