HTTP Daemon

[hannahhoward]

What

I should be able to run lassie server

This should start an API listening on a default port. (which I should be able to change with a CLI arg/env variable)

I should be able to issue a request to GET /ipfs/{cid} with an Accept request header with the value application/vnd.ipld.car and receive back a valid CARv1 file containing the root CID specified as well as the remaining blocks of the DAG. The result should be equivalent (but does not need to be byte identifical) to the same request made the Kubo HTTP Gateway API .

Response codes:

For this ticket, we should support 200, 404, and 500, where:
200 = success
404 = not found in the indexer or able to retrieve from a provider
500 = any processing errors

Acceptance criteria

I can CURL a retrievable CID and get a valid CAR file back containing the blocks needed to verify the DAG. I can verify response headers.

I can CURL a non existent CID and get a 404.

Suggested Implementation

DO NOT ADD A BIG BLOCKSTORE TO LASSIE

Complete #33 on top of filecoin-project/go-data-transfer#362

• For each request, open a CarV2 read/write blockstore to a temporary file and pass to retrieve
• For first iteration just write the whole file, then send the Response and delete the file. (we'll work on streaming as well in subsequent ticket)

Out of scope

Range requests
Path requests (subsequent tickets)
Any other path gateway spec behavior (some things tackled in subsequent tickets)

[rvagg]

throw everything in a giant FlatFS blockstore

And push the burden of a "GetAsync" implementation on users? Seems unfortunate and suboptimal since lassie has easier access to the "block is here" trigger.

[willscott]

• need to talk about semantics of query path resolution
• want some way to configure how much data should be fetched in response to a query