How can I make use of dynamic metadata for tokens?

Question

Let's say I have a contract which has in-contract, evolutive, metadata for NFTs. This means:

• The image of the NFT can change, subject to the NFT's evolution.
• The name of the NFT may be changed.
• The description of the NFT may be changed.
• The arbitrary data of the NFT can change, subject to the NFT's evolution.

While this is not the case for regular NFTs which link to images or external assets like music, it might be the case for assets that can evolve over the time (and thus have an increased market value!). But the current state of the art for ERC-1155 contracts is that they provide URIs for external assets (NOT direct metadata!).

This is a problem for me: The data has to live in an external service, and the core of the problem is: who publishes the data?. I can think about some approaches:

Approach 1: A server of my own will serve the asset data.

Although making a Python or NodeJS service (using web3 library) to consult the data is totally feasible, it is still an external source the users... have to trust. It is not an on-chain or decentralized solution, particularly important topic if I want to advertise a game as decentralized instead of, in practice, owned by a third party.

Approach 2: The metadata files are hosted in IPFS.

This approach suggests that I track the token's metadata files into a mapping, like this:

metadata[1] = "QmYCvbfNbCwFR45HiNP45rwJgvatpiW38D961L5qAhUM5Y"

Its URI would then become: "ipfs://QmYCvbfNbCwFR45HiNP45rwJgvatpiW38D961L5qAhUM5Y". There is a problem here: Who creates and uploads the file?. Ideally, the game itself should be the one to update the metadata, like this:

1. A relevant field is updated.
2. An event like MetadataMustUpdate(uint256 tokenId) is triggered.
3. Such event is listened by an external worker I own.
4. By calling a lot of methods in the contract, the data is assembled into a JSON Metadata file and then uploaded to IPFS. Its cid is retrieved.
5. The same worker has some sort of high permission in the contract to replace the metadata file with the new one (later being accessed like ipfs://newAssignedCIDForTokenID=1).
6. Optionally, a new event MetadataWasUpdated(uint256 tokenId, string cid) will be triggered for public purpose.

But, although now the metadata is pinned into IPFS (let's say public, well-known, pinning services are used)... still it is my server the one who will upload the data.

My question is: How can I find a decentralized solution for this? I want to perform this update in a decentralized way (i.e. not want to expect users to trust me), or find a STANDARD way to provide ERC-1155 metadata to markets like OpenSea for an evolving NFT, without using external URIs.

Answer 1

Let's build from your 2nd approach:

Can you create an erc-1155 that points to an IPNS directory and references a particular IPFS file within? If so, you could update a metadata file which dictates name, image, description, etc, and design the erc-1155 contract to reference the newest IPFS file.

As for the distributed updating of that metadata, a simple approach would be allowing a vote. Assume the contract has a function proposeVote, which allows users to set a json file into a matrix. Another function, castVote, allows users with sufficient reputation to choose the json file that will be uploaded. Every N blocks, the 1155 could look for an object that's been stored within itself and push an update to IPFS that requires signature by the contract. I haven't brainstormed a way to ensure access by only that smart contract, but I'm sure it's possible.