https//:Mydomain.com/tokens/0
for exemple is pointing to what exactly? the metadata but how does it get passed. My test consisted on using PHP to return data.
So my URI would be a get param left empty like;
I have moved this question to a new topic. I recommend creating a new topic per question as it makes it easier for community members to answer, (and for future readers to find answers).
With the EIP-721 optional metadata extension, each tokenID can have a tokenURI which points to a JSON file with name, description and image for the given token ID.
For testing purposes you could do what I did and use my-json-server.typicode.com to point to a single file in a GitHub repository to use for your token metadata. You could then move to your own server for further testing.
My data file is here:
You can view my NFT on OpenSea:
Using the preset ERC721PresetMinterPauserAutoId we get lower cost minting as we only need to store a single baseURI and then when we look up the tokenURI for each token we concatenate the baseURI and the tokenID (as a string) together.
In your example you would need your baseURI to be https://mydomain.com/meta.php?nftid= and then the tokenURI for tokenID would be https://mydomain.com/meta.php?nftid=0 and this should return the JSON metadata for tokenID 0.
Instead of centralized metadata (that you could change at any time) you could use IPFS.
There would be increased minting costs as you would need to store the IPFS hash for each tokenID but it would be more decentralized.
If I recall correctly OpenSea supports providing an IPFS hash for metadata.
[SOLVED] Hey @abcoathup, I have to hijack this post (sorry ). How did you managed to make your contract appearing as "My NFT" in OpenSea? We have an issue with ERC1155, that these contracts will be displayed as "Unidentified Contract". Is there anything that you did additionally in order to help OpenSea to understand the contract much better?
You will not use baseURI for dynamically minted token sets, which utilize ipfs. If each metadata you're pointing to has nonidentical content, each token will have a unique ipfs hash, i.e., the full URI is ipfs://<content hash> with no tokenId path parameter appended at the end (there's a way to make one with ipfs folders, but it won't solve your base uri problem). So again, each tokenURI call will return a content generated hash mapped per tokenId but that id won't be interpolated into the URI. At best, you can use baseURI = "ipfs://" to at least provide the redundant protocol prefix.