feat: revamp store & upload specs #114
Merged
Conversation
This file contains 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
vasco-santos
approved these changes
Mar 19, 2024
|
|
||
| #### Derivations | ||
| > ⚠️ Behavior of calling `upload/add` with a same `root` and different `shards` is not specified by the protocol. w3up reference implementation allows such invocations and updates `shards` to union of all shards across invocations. |
There was a problem hiding this comment.
maybe worth adding a note that there may exist limit of shards at implementation level?
vasco-santos
requested changes
Mar 19, 2024
There was a problem hiding this comment.
actually this is required to be added.
We used allocated for billing and it is important because it can either be:
- size of the bytes of new upload in the space
- size of the bytes of new upload already existing in other space (not uploaded, but should be accounted for space bill)
- 0 if already stored in space
Gozala
commented
Mar 19, 2024
Gozala
commented
Mar 19, 2024
Co-authored-by: Vasco Santos <santos.vasco10@gmail.com>
…/store-api-revamp
vasco-santos
approved these changes
Mar 20, 2024
Gozala
added a commit
that referenced
this pull request
Mar 22, 2024
Based on #114. PR is written with UCAN 1.0 format and assuming storacha/RFC#12 however in terms of immediate implementation I suggest that we instead 1. Use `blob/add` instead of `/space/content/add/blob` 2. Use `web3.storage/blob/*` in place of `/service/blob/` I suggest above because I think it would make more sense to transition to storacha/RFC#12 once we have UCAN@1.0 implemented, because I suspect links to tasks vs invocations are going to be a pain to deal with otherwise. This will give us cleaner break. In terms of implementing `/service/blob/accept` and specifically how does client signal that they've completed upload I suggest that we do whichever is easiest option from following two: 1. Make client sent second `blob/add` invocation after they've done upload so we can perform a lookup. 2. Add another temp capability with empty output either very specific like `blob/add/poll` or very general like `invocation/wake { task: CID } `. --------- Co-authored-by: Vasco Santos <santos.vasco10@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Updates store and upload specs so they are more like other specs as opposed to been more like documentation.