From 505ce4d81e6a44d9c58c4c70559a8775d3937dd4 Mon Sep 17 00:00:00 2001 From: Yash Jagtap Date: Wed, 19 Feb 2025 10:53:03 +0530 Subject: [PATCH] fix: typos --- src/pages/concepts/content-addressing.md | 2 +- src/pages/concepts/ucan.md | 4 ++-- src/pages/go-w3up.mdx | 2 +- src/pages/how-to/ci.mdx | 10 +++++----- src/pages/how-to/http-bridge.mdx | 4 ++-- 5 files changed, 11 insertions(+), 11 deletions(-) diff --git a/src/pages/concepts/content-addressing.md b/src/pages/concepts/content-addressing.md index e04b58a..fe6ec1e 100644 --- a/src/pages/concepts/content-addressing.md +++ b/src/pages/concepts/content-addressing.md @@ -1,6 +1,6 @@ # Content addressing -Storacha's decentralized file storage relies on _content addressing_ to find, reference, and retrieve your files on the network. Content addressing is a technique for organizing and locating data in a system in which the key used to locate content is derived from the content itself, rather than its location. While you don't need to understand content addressing to be able to incorporate sSoracha in your apps and services, if you're curious about what's going on under the hood, read on. +Storacha's decentralized file storage relies on _content addressing_ to find, reference, and retrieve your files on the network. Content addressing is a technique for organizing and locating data in a system in which the key used to locate content is derived from the content itself, rather than its location. While you don't need to understand content addressing to be able to incorporate Storacha in your apps and services, if you're curious about what's going on under the hood, read on. ## The basic problem diff --git a/src/pages/concepts/ucan.md b/src/pages/concepts/ucan.md index a934769..298f105 100644 --- a/src/pages/concepts/ucan.md +++ b/src/pages/concepts/ucan.md @@ -148,7 +148,7 @@ async function getDIDFromRequest (request) { } ``` -When the frontend recieves the delegation from your service, they can call [`addProof`][reference-client#addproof] on their `w3up-client` instance and pass in the bytes of the delegation object. They will also need to call `client.setCurrentSpace(spaceDID)`, passing in the DID for the space that you delegated access to. Once that's done, they should be able to use the `uploadFile` and `uploadDirectory` client methods to send data to your Storacha space. +When the frontend receives the delegation from your service, they can call [`addProof`][reference-client#addproof] on their `w3up-client` instance and pass in the bytes of the delegation object. They will also need to call `client.setCurrentSpace(spaceDID)`, passing in the DID for the space that you delegated access to. Once that's done, they should be able to use the `uploadFile` and `uploadDirectory` client methods to send data to your Storacha space. Note that in our example above, we granted a limited set of capabilities, so that our user can upload but not access any other functionality related to the space. If you want to delegate all permissions, use the `'*'` ability in your delegation, and use the client's [`addSpace` method][reference-client#addspace] instead of `addProof`. @@ -284,7 +284,7 @@ Replace `SPACE_DID` with the space DID you just copied. If you run `w3 space ls` Now that your second agent has access to the space created by the first, you can use `w3 up` in your second terminal window to upload whatever you like. -Note that the `w3 delegation create` command we used in step 5 delegates the `'*'` or "top" capability by default, so the second agent will have full access to the space. You can restrict the set of delegated capabilites using the `--can` flag. Try running `w3 delegation create --help` to see more options. +Note that the `w3 delegation create` command we used in step 5 delegates the `'*'` or "top" capability by default, so the second agent will have full access to the space. You can restrict the set of delegated capabilities using the `--can` flag. Try running `w3 delegation create --help` to see more options. ## Wrapping up diff --git a/src/pages/go-w3up.mdx b/src/pages/go-w3up.mdx index 951443a..ac5e7f3 100644 --- a/src/pages/go-w3up.mdx +++ b/src/pages/go-w3up.mdx @@ -14,7 +14,7 @@ In this guide, we'll walk through the following steps: 1. [Installing the client library](#install) 2. [Generating a DID](#generate-a-did) 3. [Obtaining proofs](#obtain-proofs) -4. [Loading your private key and proofs](#load-priviate-key-and-proofs) +4. [Loading your private key and proofs](#load-private-key-and-proofs) 5. [Uploading a CAR file](#upload-a-car) ## Install diff --git a/src/pages/how-to/ci.mdx b/src/pages/how-to/ci.mdx index ab4f4bc..f5e5630 100644 --- a/src/pages/how-to/ci.mdx +++ b/src/pages/how-to/ci.mdx @@ -32,7 +32,7 @@ $ w3 key create --json > ci-key.json # Extract the did as $AUDIENCE $ AUDIENCE=$(jq -r .did ci-key.json) -# Create a signed proof that you delegate capabilties to that key. +# Create a signed proof that you delegate capabilities to that key. $ w3 delegation create $AUDIENCE -c space/blob/add -c space/index/add -c filecoin/offer -c upload/add --base64 mAYIEAP8OEaJlcm9vdHOAZ3ZlcnNpb24BwwUBcRIg+oHTbzShh1WzBo9ISkonCW+KAcy/+zW8Zb... @@ -84,11 +84,11 @@ $ w3 key create --json Keep the `key` safe. It will be used by CI to sign requests to Storacha. -The `did` from the command above is the public decentalised identifier for that private `key`. +The `did` from the command above is the public decentralised identifier for that private `key`. ## Create a proof -On your local machine, use [w3cli][] to delegate capabilties to upload to our space to the public DID for the signing key we created. +On your local machine, use [w3cli][] to delegate capabilities to upload to our space to the public DID for the signing key we created. Our CI environment doesn't need to list our uploads or change our billing plan so we only delegate the `space/blob/add`, `space/index/add`, `filecoin/offer` and `upload/add` capabilities to it. @@ -116,7 +116,7 @@ $ npm i --global @web3-storage/w3cli ## Import the signing key -Set `W3_PRINCIPAL=` in the CI environment. The `w3` commmand will use the value as the signing key to use. see: https://github.com/storacha/w3cli?tab=readme-ov-file#w3\_principal +Set `W3_PRINCIPAL=` in the CI environment. The `w3` command will use the value as the signing key to use. see: https://github.com/storacha/w3cli?tab=readme-ov-file#w3\_principal The value is the `key` we created above with `w3 key create`. The `key` must be the one for the `did` that was used to create the proof. @@ -140,7 +140,7 @@ $ w3 up that path might be the `dist` or `output` directory of a previous step that built your static website or collected some stats from a job. -Once that command returns succesfully, you are done, your files are content addressed and available over IPFS. +Once that command returns successfully, you are done, your files are content addressed and available over IPFS. If you want to capture the CID for your uploads pass the `--json` flag and use `jq` to extract it diff --git a/src/pages/how-to/http-bridge.mdx b/src/pages/how-to/http-bridge.mdx index 7256327..ad0fd31 100644 --- a/src/pages/how-to/http-bridge.mdx +++ b/src/pages/how-to/http-bridge.mdx @@ -19,7 +19,7 @@ The instructions below are oriented toward capabilities invoked on spaces. These `upload/list`, `upload/remove` and `usage/report`. Other capabilities are invoked on other entities. They are supported by the bridge, but -you will need to generate auth tokens that are targetted at different DIDs and may not +you will need to generate auth tokens that are targeted at different DIDs and may not be well supported by our tools - please let us know if you are interested in this functionality so we can better support your use cases! @@ -253,7 +253,7 @@ finish "uploading" your file to Storacha you'll need to register your upload as ## Registering Uploads To support arbitrarily large file uploads, our upload service requires large files to be sharded into multiple CARs, each -of which is uploaded seperately according to the instructions in the "Storing Files" section above. +of which is uploaded separately according to the instructions in the "Storing Files" section above. Once the files have been uploaded, create a file (in this example we'll name it `upload.json`) with the following contents, replacing `did:key:z6Mkabc123` with the DID of the space you used to generate auth headers above: