ipfs

A few weeks ago when the Safe frontend was compromised, there were a lot of conversations about how IPFS could have solved the issue, but also some potential failure points. One of those was IPFS Gateways. These are hosted IPFS nodes that retrieve content and return it to the person using the gateway, and a weakness is the possibility of someone compromising the gateway and returning ContentXYZ instead of the requested ContentABC. This made me wonder: what if we could prove the CID? 

I'm still in the early exploration phases of this project, but the idea is to run a ZK proof of the CID with the content that is retrieved from IPFS to generate a proof that can be verified by the client. Currently using SP1 by Succinct and it seems to be working 👀 Would love any comments or ideas on this! Repo linked below: 

https://github.com/stevedylandev/cid_proof

DX Engineer | Head of Developer Relations at /pinata | Building orbiter.host | stevedylan.dev/links

Simply to keep the EVM compatibility that's included with SP1, but honestly don't think it will be needed so might adjust that

Decentralize your frontend, securely.
https://earthfast.com/

editor https://lowercase.cards/ curator /lowercase

Could you do this but on @earthfast  instead of IPFS?

Auditoooor at ChainSecurity
—
EPFL Cybersec MSc.
—
CTF player w/ 0rganizers
—
Hacker & Cypherpunk
—
🌸

Yup exactly! The file contents (the actual data) are provided as a private input to the proof generation. This means the content itself doesn't need to be revealed to verify the proof.  The CID components (the `cid_bytes`, `cid_bytes_remainder`, and `cid_length`) are the public outputs that are committed to within the proof.

So the file contents are a private input?   (I'm rusty on SP1) And the CID is a public output?

I only understand half of it, but sounds exciting!