support CAR meta in booster-http

[willscott]

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.

When I retrieve content from boost, I would like a response that I can use to tell someone else "this SP gave me the data I asked for.

currently that isn't true because there's no signature or attestation in the response - so there's no way to:

1. correlate the response as accurate for a given request
2. associate that the response has actually come from the specific SP

Describe the solution you'd like

We propose to make use of ipfs/specs#431 - the use of metadata within car responses that is an extension to IPIP-412 that allows for the use of a cbor key-value block to end a booster-http response.

in the final metadata block of a response from boost we propose to include 3 fields:

• len - byte length of the response data (excluding the metadata block)
• b3h - Blake3 hash (checksum) of the response data (excluding the metadata block).
• b3h_sig - A signature over <len><b3h><request> using booster-http's libp2p identity.

Describe alternatives you've considered

• this could be implemented as a trailer at the http transport level, but that limits compatibility with clients
• the response can remain un-attested, or only attested in specific cases, but that makes it too easy for an SP to not return correct data or to only return correct data to retrieval testing systems.

Additional context

No response

[willscott]

The request here has evolved a bit through discussion.

current design thought is a wrapper around the boxo handler in boost-http

• look for signaled request for trailing metadata block, compatible with Opt-in for final metadata block lassie#403
• when present append an additional car block to responses with the error and the authentication fields specified in the initial issue