Estuary on FEVM (estuary.sol)

[alvin-reyes]

Idea/Proposal: Estuary on FEVM

Contributors	@alvin-reyes
Status	Draft
Revision

Proposal/Overview

Create a estuary.sol that wraps some functions of estuary. This idea might not be the best way but still worth trying.

The design is to allow solidity developers to pin cids and record their request on chain via a standard estuary abstract contract and a estuaryfevm specific js to launch external compute service that will run the pinning / estuary process.

Components:

• estuary.sol
• estuaryfevm.js
• wasm whypfs-code (node on browser)

The clear assumption here is that we cannot pass a file to solidity but we can pass a CID that we pinned from an WHYPFS node (cid).

HL steps of implementation:

1. we create a compute (docker image) to process requests. This can be a docker image or a process that can accept args and it has a whypfs-node on it.
2. estuary.sol will have functions like pinToEstuary, makeDealsForCid etc but it'll only use the IPFS hash of the compute docker image to pass the CID.
3. when a client calls a contract function (pinToEstuary(cid)), it calls the IPFS hash of the compute docker image, passes the CID to the compute docker image and perform the "centralized service" to pin the CID. The IPFS instance can be a WASM compiled component that can run on a browser (on the DAPP).

function pinToEstuary(string memory cid) estuaryFevmRequest // make our own interface for this {
     //baseURI of the docker image
     return baseURI + "?cidToPin=" + cid;
}

We will have to force the user to use estuaryfevm.js. the JS file checks the ABI to see the tagged function estuaryFevmRequest

4. when the user calls the contract using fevmestuary.js from a web app, it needs an whypfs instance on the browser. The compute docker image does the pinning and communication with Estuary but the transaction itself is persisted on FEVM.

[alvin-reyes]

Open to any discussion if this idea is viable or worth doing. Its a good way to learn solidity and how we can integrate whypfs.

[jimmylee]

estuary.sol will have functions like pinToEstuary, makeDealsForCid etc but it'll only use the IPFS hash of the compute docker image to pass the CID.

pinToEstuary makeDealsForCid

are a good start, what do you think about for renewing deals? since real renewal doesn't exist, making new deals is still acceptable.

[alvin-reyes]

For this, we can add a renew(to date) payable function. We can create a struct inside the contract to store the date when the deal will expire, deposit the pay to a dev address. The job then gets the renewal request from a public function which Estuary will call a function similar to/pinning/pins to renew the deal for the CID. (we will need to add an end date).