ERC721 Standard Should use felt* instead of felt for tokenURI about snips HOT 6 CLOSED

I agree it's time to have a SIMP to solve this issue otherwise there will be 20 different, slightly incompatible implementations by the end of summer :)

My main concern is that by diverging from the ERC721 spec now we condemn ourselves to supporting two versions of it forever (which is even worse than having a confusing spec for a few months IMHO). I want to avoid the situation 2 years from now where all code needs to check if an NFT was created before or after strings were introduced in Cairo.

My two proposals address this issue in two different ways:

• proposing a string encoding means we can push for starkware to base their string type on our spec. This means that tokenURI return value will be binary compatible with the future string type.
• with a separate method (metadataURI) contracts can simply decide if they want to support old (pre strings) NFTs.

from snips.

If the proposal to return felt* from tokenURI goes forward I propose to include a strict requirement on how strings should be encoded (should that be another SIMP?) into felts to avoid future issues. For example, a string with 94 characters can be serialized in 4 felts but also in 3 depending on the implementation. Also, should strings be zero terminated or not?

from snips.

If the proposal to return felt* from tokenURI goes forward I propose to include a strict requirement on how strings should be encoded (should that be another SIMP?) into felts to avoid future issues. For example, a string with 94 characters can be serialized in 4 felts but also in 3 depending on the implementation. Also, should strings be zero terminated or not?

Agreed that the proposal should be accompanied with a strict standard on the encoding. The nuances can be discussed if this moves ahead. Let me know if there is anything else you would like to see in the encoding standard.

from snips.

Another option is to introduce a new method for StarkNet NFTs (like metadataURI) so that tokens are still ERC721 complaint (by not implementing the optional ERC721Metadata interface). I can see this being very confusing for developers so I don't really like it even if it checks all boxes.

from snips.

Another option is to introduce a new method for StarkNet NFTs (like metadataURI) so that tokens are still ERC721 complaint (by not implementing the optional ERC721Metadata interface). I can see this being very confusing for developers so I don't really like it even if it checks all boxes.

The developer experience of this specialized knowledge on ERC721 encoding is not ideal, but the alternative is complete unusability. Furthermore, this specialized knowledge can be paired with the ERC721 SIMP.

It's better that it gets used by those who know how than be unusable by everyone. Also currently, there is no standard for encoding and without some community alignment, every organisation will have their own which is a worse outcome.

from snips.

There hasn't been any activity on this issue recently, and in order to prioritize active issues, it will be marked as stale.
Please make sure to update to the latest version and check if that solves the issue. Let us know if that works for you by leaving a 👍
Because this issue is marked as stale, it will be closed and locked in 7 days if no further activity occurs.
Thank you for your contributions!

from snips.