fix: typos

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
 

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
 

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

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=<the signing key>` 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=<the signing key>` 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 <path to files>
 
 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
 

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: