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: propose admin/upload/inspect and admin/store/inspect capabilities #77

Merged
merged 6 commits into from
Sep 13, 2023
Merged
Show file tree
Hide file tree
Changes from 4 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
1 change: 1 addition & 0 deletions .github/workflows/words-to-ignore.txt
Original file line number Diff line number Diff line change
@@ -1,4 +1,5 @@
CIDs
CID's
Hardt
Holmgren
JSON
Expand Down
43 changes: 43 additions & 0 deletions w3-admin.md
Original file line number Diff line number Diff line change
Expand Up @@ -20,6 +20,8 @@ to administrative users by creating delegations signed with the service signer's
- [`consumer/get`](#consumerget)
- [`customer/get`](#customerget)
- [`subscription/get`](#subscriptionget)
- [`trace/upload/get`](#traceuploadget)
- [`trace/store/get`](#tracestoreget)

## Language

Expand Down Expand Up @@ -148,3 +150,44 @@ export const get = capability({
},
})
```

### `trace/upload/get`
Copy link
Collaborator

Choose a reason for hiding this comment

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

I have suggested trace/upload/add so it corresponds to upload/add, meaning it's a capability to "trace upload/add" operation. Although I realize now it goes against established add, get, list, remove pattern used in other capabilities.

However trace/upload/get also feels counter intuitive to me even though I get the logic. On one hand it would make sense to have upload/trace and store/trace, but that goes against prefix defining the ownership.

How about console/upload/inspect and console/store/inspect instead ? Alternatively it could be admin/upload/inspect or system/upload/inspect. I suppose trace/upload/inspect works too.

Copy link
Member Author

Choose a reason for hiding this comment

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

chatted offline and agreed to go with admin/{upload|store}/inspect


Get information about a content CID. This does not return the actual data identified by the CID, just metadata our
system tracks, e.g. the spaces the content identified by a given CID has been uploaded to and the dates the uploads happened.

#### inputs

`root: CID`

#### returns

The `uploads` property will be a list of spaces the given root CID's content has been uploaded to, along
with the date it was uploaded.

```typescript
{
uploads: Array<{space: SpaceDID, insertedAt: Date}>
}
```

### `trace/store/get`

Get information about a shard (i.e., a CAR that contains part of an upload) CID. This
does not return the actual data identified by the CID, just metadata our system tracks,
e.g. the spaces the CAR identified by a given CID has been stored in and the date it was stored.

#### inputs

`link: CID`

#### returns

The `stores` property will be a list of spaces the specified shard was stored in, along with the date on
which it was stored.

```typescript
{
stores: Array<{space: SpaceDID, insertedAt: Date}>
}
```