feat: add HTTP header invocation and retrieval specs#139
Conversation
volmedo
left a comment
volmedo
left a comment
There was a problem hiding this comment.
PTAL at some comments.
Regarding egress tracking, I think all the data we need is included in the original invocation. The only contentious point is the byte range, if it can be different from the one requested (see https://github.com/storacha/specs/pull/139/files#r2288087511). Other than that, I'll write an RFC to discuss the egress tracker implementation, but it looks like we are covered for now.
|
giving the retrieval spec a second look while working in the egress tracking spec, I think we might need to add a |
Co-authored-by: Vicente Olmedo <vicente@storacha.network>
frrist
left a comment
frrist
left a comment
There was a problem hiding this comment.
LGTM, I've left a couple of questions, but I suspect we can tease them out during implementation.
UCAN has nonce already! |
I know, but the spec says they are optional, so I assumed their inclusion is something that must be specified on a per-use-case basis. Are they always present in the implementations we use? |
No you use them as you need them. I'll add words to the spec... |
volmedo
left a comment
volmedo
left a comment
There was a problem hiding this comment.
LGTM!
I left one more, non-blocking question.
| "digest": { "/": { "bytes": "mEi...sfKg" } } | ||
| }, | ||
| // byte range to extract from the blob - start and end byte (both inclusive) | ||
| "range": [2097152, 2098788] |
There was a problem hiding this comment.
one more question, sorry: can range be non-present to signal we want to retrieve the full thing?
There was a problem hiding this comment.
In this case we'd have to include the range in the receipt...
There was a problem hiding this comment.
just to confirm my understanding, is it so so that we can then know the size in bytes when accounting for egress?
Anyway, I'm ok with having to set "range": [0, (size-1)]. Does the client always know the size of a blob it wants to retrieve?
There was a problem hiding this comment.
Funny you should say that. storacha/piri#229
In the case of upload data you do because you retrieve bytes based off of the data in the index. However you make a request for the full index first, which you only know the range of if the location commitment includes that information.
|
@volmedo @frrist please take a look at the latest tweaks. Hopefully they incorporate all the needed feedback. Amongst changes based on your feedback:
|
…thub.com:storacha/specs into ash/feat/add-http-header-inv-and-retrieval-specs
alanshaw
deleted the
ash/feat/add-http-header-inv-and-retrieval-specs
branch
3 participants
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
📚 Preview UCAN invocations over HTTP headers spec
📚 Preview Retrieval spec
resolves storacha/project-tracking#504