[CI] Uniswap Interface decentralized IPFS pin

[badkk]

Is your feature request related to a problem? Please describe.

Encouraged by https://uniswap.org/blog/ipfs-uniswap-interface/, we would like to contribute and provide a decentralized IPFS pin solution for Uniswap Interface, to further increase the availability and decentralization.

Describe the solution you'd like

We have built a standard Github Workflow to pin a website to Crust Network in a decentralized way: https://github.com/crustio/ipfs-crust-pinner. And specifically for Uniswap Interface, we have created a workflow to pin it: https://github.com/crustio/ipfs-crust-pinner/actions/workflows/uniswap-interface.yml.

We suggest a code change after https://github.com/Uniswap/uniswap-interface/blob/main/.github/workflows/release.yaml#L48-L55, to include ipfs-crust-pinner action. It will distribute Uniswap Interface over Crust Network and get 50+ IPFS replicas. We can help prepare a code PR to do it.

Crust Network (https://crust.network/) is a decentralized storage network based on IPFS and Substrate, and it basically provides decentralized IPFS Pin service. Right now Crust is running preview network Maxwell and got 1000+ nodes joined in to provide IPFS storage (https://telemetry.polkadot.io/#list/Crust%20Maxwell). Crust is open source(https://github.com/crustio/crust).

Describe alternatives you've considered

N/A

Additional context

You can contact us at [email protected]. We can help prepare a code PR. The pin service will be free for Uniswap, and you can mail us for necessary seeds to call Crust IPFS Pin service.

[MicahZoltu]

Note: if adding external workflows, care should be taken to use an explicit commit hash rather than a branch or version to protect against supply chain attacks.

[badkk]

Note: if adding external workflows, care should be taken to use an explicit commit hash rather than a branch or version to protect against supply chain attacks.

Sure, we can use the commit id - 8a7788a9c8e18a752264beb988733994187a1d69.

[moodysalem]

I noticed that instead of a hash you pointed to v1.0.8, but I think the risk is minimal given the build is already done and pinned by that step, so it's not possible to introduce a vulnerability into the deployed application at that point.