Uploading metadatas should be skipped when metadata didn't change

[notV4l]

Describe the bug

We should only upload the metadata to IPFS if they have changed from the last upload. For which we can store the IPFS hash of metadata in the manifest file, and upload the metdata only if IPFS hash has changed.

[tarrencev]

Good point. One improvement we could is to output the ipfs metadata uris into the manifest files. So unless it changes, we don't upload to ipfs. Another thing we could do, is to embed a local ipfs server in torii, so uploading is super quick. We will still want the contract metadata set during dev, to enable the worlds.dev interface

What do you think @lambda-0x @glihm @Larkooo

[notV4l]

Good point. One improvement we could is to output the ipfs metadata uris into the manifest files. So unless it changes, we don't upload to ipfs. Another thing we could do, is to embed a local ipfs server in torii, so uploading is super quick. We will still want the contract metadata set during dev, to enable the worlds.dev interface

What do you think @lambda-0x @glihm @Larkooo

its skipped when using offline mode and should remain usable, so embed ipfs server seems the way

[Larkooo]

Good point. One improvement we could is to output the ipfs metadata uris into the manifest files. So unless it changes, we don't upload to ipfs. Another thing we could do, is to embed a local ipfs server in torii, so uploading is super quick. We will still want the contract metadata set during dev, to enable the worlds.dev interface

What do you think @lambda-0x @glihm @Larkooo

I think that with the amount of responsibility that torii now has, with the different services under it, like the libp2p server, the different endpoints and everything together; it only makes sense to embed a ipfs server for maximum reliability and to have it standalone. Especially with the libp2p torii-relay as it's basically the same kind of scope as if we were to embed our own ipfs instance. I do think that we should still have the option to specify a specific ipfs server if wanted though.

https://github.com/ipfs-rust/ipfs-embed

The workflow seems quite similar to libp2p-rust in general as it uses it so I think it should be quite straightforward to implement at some point.

[Yogalholic]

I would like to give it a try please

[lambda-0x]

@Yogalholic i have updated the title and description of the issue to give more context of what should be done. Feel free to ask if you have any questions!

[lambda-0x]

@Yogalholic any updates on the issue? if you have any questions feel free to ask.

[Yogalholic]

I am still working on it. I don't have a specific question at the moment, there are a lot of new information to process and the dojo documentation is mostly toward game developers rather than dojo developers.

[Yogalholic]

For which we can store the IPFS hash of metadata in the manifest file

Am I allowed to add a new field in the DeploymentManifest struct in types.rs ? This file is not in the sozo crate but in dojo-world.

[lambda-0x]

For which we can store the IPFS hash of metadata in the manifest file

Am I allowed to add a new field in the DeploymentManifest struct in types.rs ? This file is not in the sozo crate but in dojo-world.

yeah, for sure.

[glihm]

@Yogalholic how are you doing on that? Any progress or blockers?

[Yogalholic]

I will open a draft PR soon

[Yogalholic]

I noticed migrate.rs file got updated while I was working on it. The code no longer handles ArtifactMetadata struct but ResourceMetadata struct

[lambda-0x]

@Yogalholic ResourceMetadata is a wrapper around ArtifactMetadata with name field, so it shouldn't be an issue you can just merge with main branch.

[Yogalholic]

I have opened a draft PR, I want to know if I am on the right track. I am not sure which encryption is used to calculate the IPFS hash