feat: blob implementation #1342
Conversation
vasco-santos
force-pushed
the
feat/blob-implementation
branch
2 times, most recently
from
d3c09d2
to
7660794
Compare
vasco-santos
force-pushed
the
feat/blob-implementation
branch
from
7660794
to
52cf8fe
Compare
vasco-santos
force-pushed
the
feat/blob-implementation
branch
from
52cf8fe
to
02584d7
Compare
vasco-santos
force-pushed
the
feat/blob-implementation
branch
3 times, most recently
from
472a097
to
9624c8a
Compare
vasco-santos
force-pushed
the
feat/blob-implementation
branch
10 times, most recently
from
6178240
to
a78c3ea
Compare
vasco-santos
force-pushed
the
feat/blob-implementation
branch
3 times, most recently
from
a36b64d
to
5c6b000
Compare
There was a problem hiding this comment.
This is an amazing progress, I'm blown away. I did provide some feedback here and there only thing I'd call out is that we really should capture dependencies across tasks and we'd have to define those in capability schemas also otherwise they will be ignored during encode.
Other than that I was also thinking when writing spec that it would be a good idea to have separate internal invocations when space usage is increased / decreased so that billing could more simply tap into that without having to make guesses if allocate resulted in more space use or not. Relatedly there had been various other cases where we want to do batch operations that billing would have trouble with, however it could be also addressed if we had simple internal ops that increase / decreate usage. This is definitely something we need @alanshaw feedback on
| if (hasBlob.ok) { | ||
| return { | ||
| ok: { size: blob.size }, | ||
| } | ||
| } | ||
|
|
||
| return { | ||
| ok: { | ||
| size: blob.size, | ||
| address: { | ||
| url: createUploadUrl.ok.url.toString(), | ||
| headers: createUploadUrl.ok.headers, | ||
| }, | ||
| }, | ||
| } | ||
| }) |
There was a problem hiding this comment.
I would expect allocation to produce same result regardless of whether we have a blob or not, it's just if we do have a blob already we would succeed put without awaiting on user to perform upload and consequently succeed blob/add as well.
There was a problem hiding this comment.
I am following the spec, which makes address optional for this reason? https://github.com/web3-storage/specs/blob/feat/http-put/w3-blob.md#allocate-blob-receipt-schema
In the meantime, latest implementation of blob dd should actually do what you say
vasco-santos
force-pushed
the
feat/blob-implementation
branch
3 times, most recently
from
6f1b921
to
0668957
Compare
vasco-santos
force-pushed
the
feat/blob-implementation
branch
from
adfb56f
to
15d732c
Compare
🤖 I have created a release *beep* *boop* --- ## [13.3.0](capabilities-v13.2.1...capabilities-v13.3.0) (2024-04-12) ### Features * blob, web3.storage and ucan conclude capabilities together with api handlers ([#1342](#1342)) ([00735a8](00735a8)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please).
🤖 I have created a release *beep* *boop* --- ## [9.1.0](upload-api-v9.0.1...upload-api-v9.1.0) (2024-04-12) ### Features * blob, web3.storage and ucan conclude capabilities together with api handlers ([#1342](#1342)) ([00735a8](00735a8)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). Co-authored-by: Vasco Santos <santos.vasco10@gmail.com>
Adds implementation of
blob/*,web3.storage/*anducan/concludehandlers and capabilities.Also upgrades to latest ucanto all over the place