Skip to content
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

Merged
merged 3 commits into from
Dec 18, 2023
Merged
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
124 changes: 124 additions & 0 deletions w3-store.md
Original file line number Diff line number Diff line change
Expand Up @@ -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)

Expand Down Expand Up @@ -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.
Copy link
Contributor

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:

{ error: { name: "ErrorName", message: "An error message" } }

?

Copy link
Contributor Author

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.

Copy link
Contributor

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?


On success, the response object will have the following shape:
Copy link
Contributor

Choose a reason for hiding this comment

The 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
Expand Down Expand Up @@ -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 data item to remove.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/remove/return/

olizilla marked this conversation as resolved.
Show resolved Hide resolved

| `field` | `value` | `required?` | `context` |
| --------- | --------------------------------- | ----------- | ------------------------------------------------------------- |
| `root` | data CID string, e.g. `bafy...` | | The root CID of the upload to get metadata for |
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

required should be true I think

Copy link
Contributor Author

Choose a reason for hiding this comment

The 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 root is not required in the schema, as folks should be allowed to make a delegation that grants you upload/get on any root. same for store.get. My gut feel is we should make the tables present the ucanto schema rather than the "when used as invocation" form.

Copy link
Contributor Author

Choose a reason for hiding this comment

The 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)

Copy link
Contributor

Choose a reason for hiding this comment

The 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.
Copy link
Contributor

Choose a reason for hiding this comment

The 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.
Expand Down