Erc1155 is meant to substitute Erc721 standard in the future?

Question

I'm asking this question because when deploying a contract for example for collectibles, the most used standard is erc721 but erc1155 offers new feautures. One basic feature to understand the difference between them is that erc721 has unique items for each token id, and erc1155 has the possibility to have several repetitions of a same item. That is useful for games, where there could be a unique sword with certain characteristics, but it can be issued a several amount of times to several owners.

Then we can conclude that erc1155 is a superset of erc721, meaning that if you want to just have one instance of each unique item and not several, you can still use erc1155 setting the count for each minted item to 1.

So my question is, is it a good practice to develop only erc1155 contracts from now on, since it has all erc721 functionalities? Meaning that it is planned to fully substitute erc721 in the future?

Or both are planned to coexist and erc721 will still be widely used? For example, OpenSea is compatible with erc721 and erc1155 as well. But what would be the best practice, to use erc1155 since is newer and as said, a superset of erc721? Is there then a reason to still develop a erc721 contract?

It seems like an unnecesary question, but let me examplify it with my use case:

I want to make a contract for a set of collectibles that will have as usual, metadata described in the json standard, and I want to have that metadata hosted in a descentralized way using ipfs.

Erc721, receives a tokenUri that you can programatically assign each time you mint a token. So I can easily upload each json to ipfs each time.

function mint(
           address _to,
           uint256 _tokenId,
           string memory tokenURI_...

Otherwise erc1155 asks for a general url that we must set in the constructor, meaning that we won't be able to change it or add more json files in the future.

constructor() ERC1155("https://myurl.com/{id}.json") {...

constructor() ERC1155("https://ipfs.io/ipfs/QmZ...(this would be the CID of the folder)...2hn/{id}.json") {...

Making erc1155 unuseful for pointing your metadata to ipfs locations. Am I wrong and there is a way where erc1155 can be used practically with an url set in ipfs?

Answer 1

EDIT: Just came across a blog post by Aurelien Pellisier with a clear approach. Works very well. He also responded to a similar question here. All the credits goes to him :)

I'm tackling the very same problem right now.

The best answer I came across so far is a post by Soenke Bartling. I'm still trying to implement it properly in my contract, apologies for not giving a complete answer at this time.

The idea is to use _tokenId as a proxy for the IPFS URI, with the base URI is set to ipfs://f0{id}. Now, the v0 implementation of IPFS doesn't allow for a nice working token Id (since it uses base58 for the encoded hash), but, luckily, v1 has many different formats.

First, we encode our NFTMetadata.json file using IPFS v1 and blake2b-208 hasher (using anything bigger than blake2b-208 gave me overflow errors):

ipfs add --cid-version 1 --hash blake2b-208 NFTMetadata.json
// bafkzvzacdlvsm4huo35sx6yypjslwvvxxshag2viqd4nexqsznya

Then, we convert our CID to base16 hex:

ipfs cid format -v 1 -b base16 bafkzvzacdlvsm4huo35sx6yypjslwvvxxshag2viqd4nexqsznya
// f01559ae4021aeb2670f476fb2bfb187a64bb56b7bc8e036aa880f8d25e12cb70

We can then remove the leading "f" and use the rest as the _tokenId. The ERC1155 contract should be updated to reconstruct the IPFS metadata address by concatenating the base URI (ipfs://f0) with the _tokenId, converted from uint to a hex string. Soenke Bartling gives a good example on how to do just that.

Hope this helps. I managed to properly mint a token, but the link to the metadata is still broken. I will keep on investigating, let me know if you make any substantial progress on your end.