-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: add store/get
& upload/get
capabilities
#82
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -22,11 +22,13 @@ The protocol is modeled as a set of capabilities which can be fulfilled by a [pr | |
- [`store/` namespace](#store-namespace) | ||
- [`store/*`](#store) | ||
- [`store/add`](#storeadd) | ||
- [`store/get`](#storeget) | ||
- [`store/remove`](#storeremove) | ||
- [`store/list`](#storelist) | ||
- [`upload/` namespace](#upload-namespace) | ||
- [`upload/*`](#upload) | ||
- [`upload/add`](#uploadadd) | ||
- [`upload/get`](#uploadget) | ||
- [`upload/remove`](#uploadremove) | ||
- [`upload/list`](#uploadlist) | ||
|
||
|
@@ -143,6 +145,66 @@ If `status == 'upload'`, the response will include additional fields containing | |
|
||
The client should then make an HTTP `PUT` request to the `url` specified in the response, attaching all the included `headers`. The body of the request MUST be CAR data, whose size exactly equals the size specified in the `store/add` invocation's `size` caveat. Additionally, the CID of the uploaded CAR must match the invocation's `link` caveat. In other words, attempting to upload any data other than that authorized by the `store/add` invocation will fail. | ||
|
||
### `store/get` | ||
|
||
> Get metadata about a CAR shard from a space | ||
|
||
The `store/get` capability can be invoked to get metadata about a CAR from a [space](#spaces). | ||
|
||
This may be used to check for inclusion, or to get the `size` and `origin` properties for a shard. | ||
|
||
#### Derivations | ||
|
||
`store/get` can be derived from a [`store/*`](#store) or [`*`][ucan-spec-top] capability with a matching `with` field. | ||
|
||
#### Caveats | ||
|
||
When invoking `store/get`, the `link` caveat must be set to the CID of the CAR file to get metadata for. | ||
|
||
If a delegation contains a `link` caveat, an invocation derived from it must have the same CAR CID in its `link` field. A delegation without a `link` caveat may be invoked with any `link` value. | ||
|
||
| `field` | `value` | `required?` | `context` | | ||
| --------- | --------------------------------- | ----------- | --------------------------------------------- | | ||
| `link` | CAR CID string, e.g. `bag...` | | The CID of the CAR to get metadata for | | ||
|
||
#### Invocation | ||
|
||
```js | ||
{ | ||
can: "store/get", | ||
with: "did:key:abc...", | ||
nb: { | ||
link: "bag...", | ||
} | ||
} | ||
``` | ||
|
||
#### Responses | ||
|
||
*Note*: This section is non-normative and subject to change, pending the [formalization of receipts and invocations][invocation-spec-pr]. | ||
|
||
Executing a `store/get` invocation with a service provider should return a response object. | ||
|
||
If a failure occurs, the response will have an `error` field with a value of `true`, and a `message` string field with details about the error. | ||
|
||
On success, the response object will have the following shape: | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. and similarly, I think the response will look like: { ok: {link: "bagy...", size: 42, insertedAt: "2023-01-01T01:01:01" } } |
||
|
||
```ts | ||
interface StoreListItem { | ||
/** CID of the stored CAR. */ | ||
link: string | ||
|
||
/** Size in bytes of the stored CAR */ | ||
size: number | ||
|
||
/** Link to a related CAR, used for sharded uploads */ | ||
origin?: string, | ||
|
||
/** ISO-8601 timestamp when CAR was added to the space */ | ||
insertedAt: string, | ||
} | ||
``` | ||
|
||
### `store/remove` | ||
|
||
> Remove a stored CAR from a space | ||
|
@@ -340,6 +402,68 @@ interface UploadAddResponse { | |
} | ||
``` | ||
|
||
### `upload/get` | ||
|
||
> Get metadata about a upload from a space | ||
|
||
The `upload/get` capability can be invoked to get metadata about an upload from a [space](#spaces). | ||
|
||
This may be used to check for inclusion, or to get the set of CAR shards associated with a root CID. | ||
|
||
The `with` resource URI must be set to the DID of the space to get the upload metadata from. | ||
|
||
#### Derivations | ||
|
||
`upload/get` can be derived from an [`upload/*`](#upload) or [`*`][ucan-spec-top] capability with a matching `with` resource URI. | ||
|
||
#### Caveats | ||
|
||
The `root` caveat must contain the root CID of the item to get metadata for. | ||
|
||
| `field` | `value` | `required?` | `context` | | ||
| --------- | --------------------------------- | ----------- | ------------------------------------------------------------- | | ||
| `root` | data CID string, e.g. `bafy...` | | The root CID of the upload to get metadata for | | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. required should be true I think There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. yep, but i think we need to make it clearer that these tables are referring to "when used as an invocation", as the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. (yep, as i deliberately differed from the other items in this spec where they have marked an optional field as required) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. ahhhh got it, I agree re: presenting ucanto schema!! |
||
|
||
#### Invocation | ||
|
||
To invoke `upload/get`, an agent prepares a UCAN with the following shape: | ||
|
||
```js | ||
{ | ||
can: "upload/get", | ||
with: "did:key:abc...", | ||
nb: { | ||
root: "bafyabc..." | ||
} | ||
} | ||
``` | ||
|
||
#### Responses | ||
|
||
*Note*: This section is non-normative and subject to change, pending the [formalization of receipts and invocations][invocation-spec-pr]. | ||
|
||
Executing an `upload/get` invocation with a service provider should return a response object. | ||
|
||
If a failure occurs, the response will have an `error` field with a value of `true`, and a `message` string field with details about the error. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. ditto re: response formats in this section |
||
|
||
On success, the response object will have the following shape: | ||
|
||
```ts | ||
interface UploadListItem { | ||
/** Root CID of the uploaded data item. */ | ||
root: string | ||
|
||
/** CIDs of CARs that contain the complete DAG for the uploaded data item. */ | ||
shards: string[] | ||
|
||
/** ISO-8601 timestamp when the upload was added to the space. */ | ||
insertedAt: string, | ||
|
||
/** ISO-8601 timestamp when the upload entry was last modified. */ | ||
updatedAt: string, | ||
} | ||
``` | ||
|
||
### `upload/remove` | ||
|
||
> Remove an upload from a space. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe I'm misunderstanding this, but won't the error response look like:
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah yes you right. I was blending this in with the rest of this spec, but things have changed!
I can't find a place in our other specs where we document the expected output shapes which seems odd too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeaaaa I agree, I think it's a hole in our specs that we haven't documented the input/return types across the board, maybe even a DX issue worth fixing asap?