initial implementation

[gravityblast]

a simple implementation of the pinata API that we can use in our local environment to avoid using the real API and being able to use it offline.

It's implemented in to have it simple and with just a couple dependencies.
Also, I don't think we will need to develop on top of it but it's just to have a service running from docker compose in our grants stack local dev env.

check the readme file for more info.

[boudra]

if I wanted to persist the uploaded files between restarts, would i have to mount a volume here? maybe a VOLUME directive would be a good idea here

[gravityblast]

@boudra you should be able to do it anyway when you start the container right?
but I didn't set it as our standard way to do it just because we don't have a way to persist the full state of the system including the blockchain state until anvil doesn't dump events foundry-rs/foundry#5906

[vacekj]

Can you elaborate on the go choice here? Are we planning on using the ipfs go libs more than the hash type? There was probably a discussion that I wasn't part of when i was out sick.

[gravityblast]

Can you elaborate on the go choice here? Are we planning on using the ipfs go libs more than the hash type? There was probably a discussion that I wasn't part of when i was out sick.

@vacekj this is just the local service I use in development and since I notice everyone is using the real pinata service for development I decided to share it. I don't think we need to add features, it's just a development service we can use in local.

Are we planning on using the ipfs go libs more than the hash type?

the only sub packages included are go-multicodec and go-multihash just to have the real CID instead of a simple hash, nothing else from the ipfs library is included. did you want to use more things?

[vacekj]

@gravityblast re: first part - sounds good to me.

re: second part - I misread the code - nothing I would like to add personally, @bard asked about "forking the chain"-like funcitonality with real pinata, but personally I don't have a need for that.

[bard]

@gravityblast re: first part - sounds good to me.

re: second part - I misread the code - nothing I would like to add personally, @bard asked about "forking the chain"-like funcitonality with real pinata, but personally I don't have a need for that.

I was referring to IPFS in general, i.e. wondering if at any point we're going to need IPFS resources outside of what is uploaded as part of a test setup, as it might be the case when trying to reproduce locally a production bug.

[boudra]

@gravityblast re: first part - sounds good to me.
re: second part - I misread the code - nothing I would like to add personally, @bard asked about "forking the chain"-like funcitonality with real pinata, but personally I don't have a need for that.

I was referring to IPFS in general, i.e. wondering if at any point we're going to need IPFS resources outside of what is uploaded as part of a test setup, as it might be the case when trying to reproduce locally a production bug.

This is a good point, there's also the indexer to consider, how does the forking work with eth_getLogs? I would assume that the indexer would get events for the rounds in the forked chain, right? This means that the IPFS service should also serve those metadatas.

We could have the indexer start from the forked block, but there are other cases we might not consider so it would make sense to have this service behave the same as the node and "fork" Pinata.

Another option could be just having the development environment not fork anything, so a pure offline set up.

[gravityblast]

I imagine the fork scenario with a different config.

• development with one .env for local only services
• staging like what we have now, with testnets and staging envs
• fork as a mix, running anvil forking in local but using the real pinata to get real data

I don't think we will need a mixed environment but I'm happy to talk about it if you guys have any scenario in mind.

This is a good point, there's also the indexer to consider, how does the forking work with eth_getLogs? I would assume that the indexer would get events for the rounds in the forked chain, right? This means that the IPFS service should also serve those metadata.

yes it will need to get logs from the local chain, and files from past rounds/projects would be available in pinata.

Another option could be just having the development environment not fork anything, so a pure offline set up.

yes this is the current idea, but we can continue thinking about the forking scenario for specific tests we want to reproduce, but not really for development