Unlimited NEP-11 token ID
roman-khimov opened this issue · comments
Currently NEP-11 only restricts the type of tokenId in that it should be a ByteString, but ByteString can be up to MaxItemSize bytes long which is 1M at the moment. Then NEP-11 tracker (neo-project/neo-modules#671) will create 1M+ long key and store it in the DB. It should work, but likely it'll be quite slow and clients might have issues displaying these long IDs.
The proposal is to set some limit for valid NEP-11 IDs (like MaxStorageKeySize that is 64 bytes at the moment) which will allow clients (and NEP-11 tracker) to ignore invalid ones.
I think that you are right, 64 it's enough for me
What if you wanted to store an actual encoded NFT in the tokenId? This proposal might be removing a valid use case.
What if you wanted to store an actual encoded NFT in the tokenId
I think that is not a good design
What if you wanted to store an actual encoded NFT in the tokenId
I think that is not a good design
I completely disagree. It can be a valid use case.
@jastez If you have an NFT, and wanted to use it as a key for another NFT, you're implying a relationship which has other, more standard solutions. For example, you could simply change the properties of the parent with a pointer attribute to the childID. The tokenId is generally expected to be unique and immutable which constrains the structure you indicated to a 1-1 relationship.
If you really need to have a more explicit reference, it would be a lot more resource efficient to use hash(parentNFT) as the tokenID. Just be aware that a very common pattern for NFTs is to run code like this:
properties = []
for i in range(TOTAL_SUPPLY):
p = contract.properties(i)
properties.append(p)to pull properties out of the contracts since the typical architecture is to use an iterator for tokenId
The proposal is to set some limit for valid NEP-11 IDs (like MaxStorageKeySize that is 64 bytes at the moment) which will allow clients (and NEP-11 tracker) to ignore invalid ones.
Agree. Can you create a pull request?