General purpose NFT contract about sway-applications

[nfurfaro]

A few things that I'd like to see in an NFT contract to help keep it useful and flexible:

• the contract should represent a collection of NFTs, not just a single token
• every token minted should have a unique, immutable token id
• there should be a way to find the owner of any token given its id.
• access control for minting - the contract should store an Identity as the minter, which allows for either an address or a minter contract to be set as the entity with minting rights

[nfurfaro]

Plus one on the use of erc165!
I think using the Identity type in storage, ie: as the minter, owner, token owner, etc will help to make things a bit more interoperable between EOAs and Contracts.l, but there's likely more we can do on that front.

[nfurfaro]

A good next step for this would be to pin down what the abi looks like.

The specific implementation can follow, and will probably be able to benefit from some cool new functionality in Sway (ie: vec, improved storage interface).

[nfurfaro]

Something along the lines of this as a start (may not be complete yet):

library nft;

use std::identity::Identity;


abi NFT {
    fn mint(to: Identity, amount: u64) ;
    fn burn(token_id: b256) ;
    fn owner_of(token_id: b256) -> Option<Identity>;
    fn balance_of(owner: Identity) -> u64;
    fn transferFrom(from: Identity, to: Identity, token_id: b256)
}

And then some supporting internal functions, ie:

• fn generate_token_id()
• register_new_token()
  etc...

[nfurfaro]

Eventually, we'll want to add event logging to this as well.
This is a good reference to get some ideas: https://eips.ethereum.org/EIPS/eip-721

I don't know about the safeTransfer stuff yet, need to think on that some more.
pinging @adlerjohn @SilentCicero for input.

[adlerjohn]

cc @simonr0204 and @pixelcircuits for input

[nfurfaro]

A separate (but related) issue is token standards, ie: Following existing standards, or creating a new one.
I'm most familiar with ERC721 and ERC1155 (batch transfers are definitely nice to have) myself.
But probably out of scope for this issue.

[pixelcircuits]

We need to also make sure it's just as easy for contracts to hold NFTs as it is for EOAs. This will be necessary for cross domain bridging in the future. I also like how ERC165 allows for interface detection and we should definitely mirror that process to make for easy data crawling for marketplaces, etc.

[Braqzen]

A few things that I'd like to see in an NFT contract to help keep it useful and flexible:

• the contract should represent a collection of NFTs, not just a single token
• every token minted should have a unique, immutable token id
• there should be a way to find the owner of any token given its id.
• access control for minting - the contract should store an Identity as the minter, which allows for either an address or a minter contract to be set as the entity with minting rights

@bitzoic can you move this checklist into the description above so that GitHub does some nice tracking similar to #1 ?
Could you also add some labels to the issue?

[bitzoic]

This issue's tests are currently blocked by FuelLabs/fuels-rs#326