This PR creates stores and wires up new upload-api running blob/add, web3.storage/blob/allocate, web3.storage/blob/accept and ucan/conclude capabilities. Tests are also imported from upload-api implementation and run here.
As agreed on https://github.com/web3-storage/w3up/issues/1343 , there won't be any deduping between old world and new world. Therefore, we have new allocations table, and use different key schema in carpark. We are writing blobs keyed as base58btc as previously discussed as ${base58btcEncodedMultihash}/${base58btcEncodedMultihash}.blob. I added .blob suffix but I am happy to other suggestions. Depending on how we progress with the reads side, we can consider creating a new bucket to fully isolate new content?
Integration tests are in progress in branch https://github.com/web3-storage/w3infra/tree/feat/add-blob-protocol-to-service-integration-test. They currently run in my local dev setup, and have full functionality from blob/add, followed by HTTP PUT to bucket and ucan/conclude containing the receipt of the put. This makes scheduled blob/accept run and a receipt with a location claim being available. You can see the tests in branch, on file test/blob.test.js. I want to only add them here once we can rely on the client to do the manual hack I did here
This PR creates stores and wires up new
upload-api
runningblob/add
,web3.storage/blob/allocate
,web3.storage/blob/accept
anducan/conclude
capabilities. Tests are also imported fromupload-api
implementation and run here.As agreed on https://github.com/web3-storage/w3up/issues/1343 , there won't be any deduping between old world and new world. Therefore, we have new
allocations
table, and use different key schema incarpark
. We are writing blobs keyed asbase58btc
as previously discussed as${base58btcEncodedMultihash}/${base58btcEncodedMultihash}.blob
. I added.blob
suffix but I am happy to other suggestions. Depending on how we progress with the reads side, we can consider creating a new bucket to fully isolate new content?The
receipts
andtasks
storage end up being more complicated as they need to follow https://github.com/web3-storage/w3infra/blob/main/docs/ucan-invocation-stream.md#buckets, and is essentially the same as what happens on https://github.com/web3-storage/w3infra/blob/main/upload-api/ucan-invocation.js#L66 but at a different level as this is a proactive write of tasks and receipts.Integration tests are in progress in branch https://github.com/web3-storage/w3infra/tree/feat/add-blob-protocol-to-service-integration-test. They currently run in my local dev setup, and have full functionality from
blob/add
, followed by HTTP PUT to bucket anducan/conclude
containing the receipt of the put. This makes scheduledblob/accept
run and a receipt with a location claim being available. You can see the tests in branch, on filetest/blob.test.js
. I want to only add them here once we can rely on the client to do the manual hack I did here