Open
Conversation
alanshaw
changed the title
Member
hannahhoward
left a comment
hannahhoward
left a comment
There was a problem hiding this comment.
My biggest question is the format. Given the size limit challenges, should we consider:
- gzipping the archive
- using a thinner archive format than car, like https://github.com/ucan-wg/go-ucan/blob/main/pkg/container/SPEC.md (note: compare perf here -- https://github.com/ucan-wg/go-ucan/tree/main/pkg/container)
Member
Author
|
I'm pretty easy on the format. In my testing this wasn't much more than 1kb using the existing format and less when gzipped (for a typical chain of invocation plus 2x delegation chain). I'm cool with compressing, would be nice to not have to introduce another format...and we can always iterate... |
Member
|
@alanshaw gzip is my priority, if you want to skip the container format I'm not super attached. |
alanshaw
added a commit
to storacha/go-ucanto
that referenced
this pull request
Sep 11, 2025
This PR implements the [RFC here](storacha/RFC#60). It exposes a server and client implementation that allows UCAN authorized retrieval requests via invocations (and receipts) passed in HTTP headers. This leaves the HTTP response body available to be used for retrieved bytes. A retrieval server is very similar to a normal Ucanto server, except it requires invocations to be sent using the `headercar` transport codec. The only other difference is that invocation handlers receive an extra argument - the HTTP request info, and can return and additional value - a HTTP response. The retrieval client is also very similar to a Ucanto client, except that it has the ability to send an invocation in multiple parts, if it does not fit in HTTP headers. Essentially it'll send proofs one by one until the server has all the proofs required to execute the invocation. The server has an LRU cache allowing for this. The PR also includes a transport codec that encodes agent messages into HTTP headers. 🎬 Demo: https://youtu.be/11np-cGTe48?si=kw88R1DAlMSq-b1T resolves #59 --------- Co-authored-by: Forrest <forrest@storacha.network>
alanshaw
added a commit
to storacha/specs
that referenced
this pull request
Sep 12, 2025
Adds specs for UCAN invocations over HTTP headers and the related retrieval spec that uses it. The UCAN invocations over HTTP headers spec is based on storacha/RFC#60 [🎬 Implementation Demo of UCAN invocations over HTTP headers](https://youtu.be/11np-cGTe48?si=kw88R1DAlMSq-b1T) [📚 Preview UCAN invocations over HTTP headers spec](https://github.com/storacha/specs/blob/ash/feat/add-http-header-inv-and-retrieval-specs/http-header-ucan-invocation.md) [📚 Preview Retrieval spec](https://github.com/storacha/specs/blob/ash/feat/add-http-header-inv-and-retrieval-specs/w3-retrieval.md) resolves storacha/project-tracking#504 --------- Co-authored-by: Vicente Olmedo <vicente@storacha.network>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This RFC attempts to define a Ucanto style transport that allows invocations and receipts to be communicated in HTTP headers, leaving the HTTP request/response body usable for alternative purposes.
The idea is to use this proposal to allow us to send a
space/content/retrieveinvocation in the HTTP headers of a HTTP GET request. The response body is subsequently used to return the requested bytes in a single round trip (for the majority of requests), while allowing egress to be accounted for via signed invocations/receipts.📚 Preview
🎬 Implementation Demo