statechannels / boost Goto Github PK

Update boost-http to check if a payment has been made on a channel.

          Looks good.

This prompts me to think that we need some docs to explain to boost users:

• how to enable nitro
• what that means / enables for them.

Perhaps we should make an issue to cover this. I believe the boost maintainers are going to want to see that before considering our work.

Originally posted by @geoknee in #26 (review)

          Yep all good for demo purposes. Over the medium term, let's try and expedite the RPC error handling on the go-nitro side of things.

Originally posted by @geoknee in #3 (comment)

Currently we have enable CORS requests from anywhere to get the demo working. Code here.

Instead of TODO we should work with the filecoin team to implement a more permanent solution.

The boost repository we forked contains a circleCI workflow for running various tests on CI.

We should see if we can easily convert some of that to GH actions, so we can make sure we're not breaking things.

That, or we can enable cirlcleCI.

Right now our nitro-integration modifies the entrypoint for the booster http container, meaning nitro integration is always enabled when using the docker devnet.

We should find a way to enable nitro using an env var or config file, so by default the filecoin devnet works as normal.

Update to latest go-nitro and properly handle errors returned from the rpc API

Originally posted by @geoknee in #17 (comment)

If reasonable we should write a new unit test for booster http that tests the nitro integration. We can probably mock out the nitro server pretty easily.

Figure how how spinning up ledger channels and payment channels occurs as part of the boost demo. Instead of relying on payment channels already be running we should update our demo to handle spinning up channels if needed.

Checklist

• This is not a new feature or an enhancement to the Filecoin protocol. If it is, please open an FIP issue.
• This is not brainstorming ideas. If you have an idea you'd like to discuss, please open a new discussion on the Boost forum and select the category as Ideas.
• I have a specific, actionable, and well motivated feature request to propose.

Boost component

• boost daemon - storage providers
• boost client
• boost UI
• boost data-transfer
• boost index-provider
• Other

What is the motivation behind this feature request? Is your feature request related to a problem? Please describe.

Coupling individual payments with retrievals.

Describe the solution you'd like

A boost client making a retrieval request can embed a payment voucher directly into the request body - tightly coupling the individual payment with the retrieval.

MVP: Boost server should

• parse the voucher
• feed the voucher to its nitro rpc-client (api method incoming - see statechannels/go-nitro#1326)
• read the result, confirm that the voucher represents a payment, and serve the request

This improves the "accounting" for the boost server over current state (essentially: serve requests if the requester has ever paid anything).

Later:

• boost server should have a fee schedule of some sort, and be able to selective honour requests only if they cover the set fee

edit: missed the "open a blank issue" option. Haha.

To allow requesting a file in chunks with micropayments we should look at implementing GET range requests.

          > I guess this panic is justified by "it should never happen"? Perhaps we should warn about the panic in the godoc?

Yup, this should be a "never happen" case. Although it wouldn't be much work to return an error instead and that would be more straightforward.

Originally posted by @lalexgap in #3 (comment)

Right now when nitro is enabled on booster-http it will panic on startup if it can't reach the nitro rpc server. We should handle this slightly more gracefully, similar to how booster-http handles waiting on the lotus/boost rpc endpoint

Currently we rely on spinning up a seperate instance of hardhat for nitro-rpc-client, we're not actually communicating with the filecoin test chain that gets started with a the devnet command.

I'm not sure if the filecoin test chain exposes an EVM-comptable JSON-RPC API, but we should investigate and use it, if it exists.

Add the check from #5 to the car/file endpoint.