Skip to content

Commit

Permalink
Removing use of the word 'we' and replacing it with more neutral lang…
Browse files Browse the repository at this point in the history
…uage
  • Loading branch information
jessiemongeon1 committed Oct 30, 2023
1 parent 49debbb commit ac939ba
Show file tree
Hide file tree
Showing 100 changed files with 379 additions and 381 deletions.
2 changes: 1 addition & 1 deletion docs/concepts/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,7 +8,7 @@ You don’t need to know much about the inner workings of the Internet Computer

Knowing a little about the design and architecture of the IC can make it easier for you to realize the benefits that align with your goals and inform the types of applications you develop.

The topics in this section introduce key components and terminology to help you understand the architecture and operation of the IC. You can learn more about [canisters](./canisters-code.md), how and why they allow to build decentralized apps hosted fully on chain, and why we should place our [trust](./trust-in-canisters.md) in them. We can see more about how canisters are powered by [tokens and cycles](tokens-cycles.md) and how the Internet Computer is [governed](./governance.md) and developed in a decentralized manner.
The topics in this section introduce key components and terminology to help you understand the architecture and operation of the IC. You can learn more about [canisters](./canisters-code.md), how and why they allow to build decentralized apps hosted fully on chain, and why you should place your [trust](./trust-in-canisters.md) in them. You can see more about how canisters are powered by [tokens and cycles](tokens-cycles.md) and how the Internet Computer is [governed](./governance.md) and developed in a decentralized manner.

If you want to get right to developing code, though, you can skip this introductory material—key concepts and terminology—and look them up later when you need them either in this category or in the [glossary](/docs/references/glossary.md).

Expand Down
2 changes: 1 addition & 1 deletion docs/concepts/trust-in-canisters.md
Original file line number Diff line number Diff line change
Expand Up @@ -22,7 +22,7 @@ Additionally, developers can utilize the [canister history](/docs/current/develo

Canister smart contracts are deployed and managed by controllers. A controller's level of decentralization can range from being managed by a single person, or team of people up to being managed by the NNS or another kind of on-chain DAO. Among other capabilities, the controllers can change the code for the canisters which they control so canister code is **mutable**, unlike smart contracts on other blockchains. The controllers have complete control over the assets like ICP tokens or Bitcoins held by the canister they manage. This feature brings canisters closer to typical software and makes them suitable for a broad range of applications where software logic can be changed on an as-needed basis.

For critical applications like those used in DeFi, centralized mutability can be dangerous; the controller could change a benign canister into a canister that steals assets. Below we outline some options available to developers on how to verifiably decentralize the control of a canister's mutations.
For critical applications like those used in DeFi, centralized mutability can be dangerous; the controller could change a benign canister into a canister that steals assets. Below are some options available to developers on how to verifiably decentralize the control of a canister's mutations.

:::info
Canister controllers, if not voluntarily decentralized, have complete control over the user assets held by the canister, for example, any ICP Tokens or Bitcoin held by the canister on the user's behalf. The controller, if malicious, can steal all the assets. In other words, as a user, if you interact with a canister that deals with your assets, inspect the canister to know how it handles them. If you determine that the canister is storing the assets in its subaccounts, ensure that the canister controller is decentralized.
Expand Down
14 changes: 7 additions & 7 deletions docs/developer-docs/agents/javascript-intro.md
Original file line number Diff line number Diff line change
Expand Up @@ -17,7 +17,7 @@ The IC supports two types of calls - `queries` and `updates`. Queries are fast a
As a result of the latency for updates, best practices around modeling your application's performance will have you make updates asynchronously and early. If you can make an update ahead of time and have it already "cached" in your canister's memory, your users will have a better experience requesting that data. Similarly, if your application needs to make an update, it is best to avoid blocking interaction while your update is taking place. Use **optimistic rendering** wherever practical, and proceed with your application as if the call has already succeeded.

## Prerequisites
To get started with JavaScript on the Internet Computer, we recommend your development environment includes:
To get started with JavaScript on the Internet Computer, it is recommended your development environment includes:

- [x] IC SDK for canister creation and management.
- [x] Node JS (12, 14, or 16).
Expand All @@ -26,7 +26,7 @@ To get started with JavaScript on the Internet Computer, we recommend your devel
- `dfx new` starter project.
- An example from [dfinity/examples](https://github.com/dfinity/examples).

For this guide, we'll use the project created by the command:
For this guide, use the project created by the command:

```
dfx new hello
Expand Down Expand Up @@ -110,7 +110,7 @@ Let's explore each of these `src/declarations` files a bit more.

#### hello_backend.did

`hello_backend.did` defines your interface, as we saw above.
`hello_backend.did` defines your interface, as seen above.

#### hello.did.d.ts

Expand Down Expand Up @@ -163,11 +163,11 @@ In the `index.js` file, each of the previously explained pieces are pulled toget
}
```
This constructor first creates a `HTTPAgent`, which is wraps the JS `fetch` API and uses it to encode calls through the public API. We also optionally fetch the root key of the replica, for non-mainnet deployments. Finally, we create an actor using the automatically generated interface for the canister we will call, passing it the `canisterId` and the `HTTPAgent` we have initialized.
This constructor first creates a `HTTPAgent`, which is wraps the JS `fetch` API and uses it to encode calls through the public API. This code also optionally fetches the root key of the replica, for non-mainnet deployments. Finally, it creates an actor using the automatically generated interface for the canister will call, passing it the `canisterId` and the `HTTPAgent` that have been initialized.
This `actor` instance is now set up to call all of the service methods as methods. Once this is all set up, like it is by default in the `dfx new` template, you can simply run `dfx generate` whenever you make changes to your canister API, and the full interface will automatically stay in sync in your frontend code.
This `actor` instance is now set up to call all of the service methods as methods. Once this is all set up, you can simply run `dfx generate` whenever you make changes to your canister API, and the full interface will automatically stay in sync in your frontend code.
Since this interface is easily typed, we are able to automatically generate a JavaScript interface, as well as TypeScript declarations, for this application. This can be done in two ways. You can manually generate an interface using the `didc` tool, download it by going to the [releases](https://github.com/dfinity/candid/releases) tab of the `dfinity/candid` repository.
Since this interface is easily typed, you are able to automatically generate a JavaScript interface, as well as TypeScript declarations, for this application. This can be done in two ways. You can manually generate an interface using the `didc` tool, download it by going to the [releases](https://github.com/dfinity/candid/releases) tab of the `dfinity/candid` repository.
## Browser
Expand All @@ -186,7 +186,7 @@ Updates to the IC may feel slow to your users, at around 2-4 seconds. When you a

## Bundlers

We recommend using a bundler to assemble your code for convenience and less troubleshooting. We provide a standard Webpack config, but you may also turn to Rollup, Vite, Parcel, or others. For this pattern, we recommend running a script to generate `.env.development` and `.env.production` environment variable files for your canister ids, which is a fairly standard approach for bundlers, and can be easily supported using [dotenv](https://www.npmjs.com/package/dotenv).
It is recommended to use a bundler to assemble your code for convenience and less troubleshooting. This guide provides a standard Webpack config, but you may also turn to Rollup, Vite, Parcel, or others. For this pattern, it is recommended to run a script to generate `.env.development` and `.env.production` environment variable files for your canister ids, which is a fairly standard approach for bundlers, and can be easily supported using [dotenv](https://www.npmjs.com/package/dotenv).

Here is an example script you can run to map those files:

Expand Down
40 changes: 20 additions & 20 deletions docs/developer-docs/agents/nodejs.md
Original file line number Diff line number Diff line change
Expand Up @@ -10,9 +10,9 @@ This article covers connecting to the IC from Node.js in the server environment.

Node.js is a runtime for JavaScript, so you can use the [JavaScript agent](https://www.npmjs.com/package/@dfinity/agent) with it to interact with a canister. This can be useful to run an oracle, connect an existing Node.js application to the IC, or to introduce a websocket layer to your application.

In this example, we will run a simple Node.js websocket provider, proxying a canister keeping track of a stack of events.
In this example, you will run a simple Node.js websocket provider, proxying a canister keeping track of a stack of events.

First, we need to get started with a project. Let's take the DIP721 example code at https://github.com/Psychedelic/DIP721, and write a node script that will mint a collection of NFTs.
First, you need to get started with a project. Let's take the DIP721 example code at https://github.com/Psychedelic/DIP721, and write a node script that will mint a collection of NFTs.

## Prerequisites

Expand Down Expand Up @@ -51,7 +51,7 @@ git clone https://github.com/Psychedelic/DIP721.git

- #### Step 2: Then, `cd` into `DIP721`.

The project has all of the canister logic already added, so there is only a little more we need to add.
The project has all of the canister logic already added, so there is only a little more that needs to be added.

- #### Step 3: Add a `package.json` file by running the command:

Expand Down Expand Up @@ -125,7 +125,7 @@ To `nft`, add a new configuration for `declarations -> node_compatibility`:

This will optimize the auto-generated JavaScript interface for `node.js` projects.

- #### Step 9: Additionally, we will add a new canister, `asset`, which will be used to host the frontend assets for our NFTs.
- #### Step 9: Additionally, add a new canister, `asset`, which will be used to host the frontend assets for your NFTs.

```
"asset": {
Expand All @@ -139,7 +139,7 @@ This will optimize the auto-generated JavaScript interface for `node.js` project

- #### Step 10: Finally, remove the `dfx` setting as well as the `defaults` and `networks` settings.

They will lock the project to a specific and outdated version of `dfx`, and we want to use `dfx` 12 or later.
They will lock the project to a specific and outdated version of `dfx`, and use `dfx` 12 or later.

After these steps, your `dfx.json` file should look like this:

Expand Down Expand Up @@ -173,7 +173,7 @@ After these steps, your `dfx.json` file should look like this:

- #### Step 11: Now, you can start up your project.

We will use an example principal, derived from a seed phrase of the word `"test"` 12 times. This principal will be `rwbxt-jvr66-qvpbz-2kbh3-u226q-w6djk-b45cp-66ewo-tpvng-thbkh-wae`.
You will use an example principal, derived from a seed phrase of the word `"test"` 12 times. This principal will be `rwbxt-jvr66-qvpbz-2kbh3-u226q-w6djk-b45cp-66ewo-tpvng-thbkh-wae`.

:::caution
It should go without saying, but this is a testing seed phrase, and any real seed phrase used to deploy or manage a canister should be kept a secret.
Expand All @@ -199,11 +199,11 @@ dfx canister call asset authorize "(principal \"rwbxt-jvr66-qvpbz-2kbh3-u226q-w
dfx generate nft
```

The interface will be placed into `src/declarations/nft`, and we will use that to interact with the canister. Before we setup the actor, we will need to have an identity.
The interface will be placed into `src/declarations/nft`, and will be used that to interact with the canister. Before you setup the actor, you will need to have an identity.

### Identity from a seed phrase

- #### Step 13: Since we are running the code using the `--es-module-specifier-resolution=node` flag, we can use `import` syntax in our code.
- #### Step 13: Since you are running the code using the `--es-module-specifier-resolution=node` flag, you can use `import` syntax in your code.

Let's start by setting up an identity that will resolve to the principal that is mentioned above.

Expand All @@ -228,18 +228,18 @@ Remember to store any seed phrase you use in production in a secure place. Use e

### Setting up an actor

- #### Step 14: Back in `src > node > index.js` file, we can now set up our actor.
- #### Step 14: Back in `src > node > index.js` file, you can now set up your actor.

We can import a `createActor` utility from the `nft` declarations, as well as a `canisterId` alias, which by default points to `process.env.<canister-id>_CANISTER_ID`.
You can import a `createActor` utility from the `nft` declarations, as well as a `canisterId` alias, which by default points to `process.env.<canister-id>_CANISTER_ID`.

You can pass the canister id environment variable logic to your application in a number of ways. You could:

- Edit it into the start of your `package.json` scripts `NFT_CANISTER_ID=... node...`.
- Install [dotenv](https://www.npmjs.com/package/dotenv) and configure it to read from a hidden `.env` file.

For the sake of this example, which will focus on local development, we will simply read it from the local `canister_ids.json` file, which can be found in `.dfx/local/canister_ids.json`.
For the sake of this example, which will focus on local development, you will simply read it from the local `canister_ids.json` file, which can be found in `.dfx/local/canister_ids.json`.

So, to import the canister ID and set up our actor, it will look something like this:
So, to import the canister ID and set up your actor, it will look something like this:

:::caution
The following example is a **code snippet** that is part of a larger code file. This snippet may return an error if run on its own. To view the full code file that should be run, please see [final code](#final-code).
Expand Down Expand Up @@ -272,15 +272,15 @@ const actor = createActor(effectiveCanisterId, {
});
```
At the end here, the actor is fully set up and ready to make calls to the local canister and the agent we have set up. Since we are focusing on local, the `host` is pointing to the local replica at `http://127.0.0.1:4943`. If we want to talk to the IC mainnet, the `host` should point to `https://icp0.io`.
At the end here, the actor is fully set up and ready to make calls to the local canister and the agent you have set up. Since this tutorial is focusing on local development the `host` is pointing to the local replica at `http://127.0.0.1:4943`. If you want to talk to the IC mainnet, the `host` should point to `https://icp0.io`.

:::info
The port `4943` is the default port for the local replica. If you have changed the port, or you are using an older version of `dfx`, you will need to update it here and in the other instances in the code.
:::

### Minting logic

Now, let's go through and write some logic to mint our NFTs. The steps we will need to go through include:
Now, let's go through and write some logic to mint your NFTs. The steps will go through:
- 1: Parse a config for the NFTs to be minted.
- 2: Load assets and metadata for the assets.
Expand All @@ -290,7 +290,7 @@ Now, let's go through and write some logic to mint our NFTs. The steps we will n
### Parse the config
- #### Step 15: To parse the config, we'll store it in a JSON file, using an array of items.
- #### Step 15: To parse the config, store it in a JSON file, using an array of items.
There's the included "asset" name, plus some key-value metadata that can get loaded as well.

Expand All @@ -309,7 +309,7 @@ Create a new file in the `src/node` directory called `nft.json` and insert the f
]
```

Then, we can load that in the `src/node/index.js` script:
Then, load that in the `src/node/index.js` script:

:::caution
The following example is a **code snippet** that is part of a larger code file. This snippet may return an error if run on its own. To view the full code file that should be run, please see [final code](#final-code).
Expand Down Expand Up @@ -372,7 +372,7 @@ main();
### Prepare thumbnail
- #### Step 17: To prepare the thumbnail, we can use `image-thumbnail`, a utility based on `sharp`.
- #### Step 17: To prepare the thumbnail, you can use `image-thumbnail`, a utility based on `sharp`.
In the `src/node/index.js` script, add the following:
Expand All @@ -394,7 +394,7 @@ const thumbnail = await imageThumbnail(filePath, options);
### Upload assets
- #### Step 18: We can use a community library to simplify uploading to our asset canister. We'll need to get the canister ID, pass our agent, and then upload our two files.
- #### Step 18: You can use a community library to simplify uploading to your asset canister. You'll need to get the canister ID, pass your agent, and then upload your two files.

In the `src/node/index.js` script, add the following:

Expand Down Expand Up @@ -429,7 +429,7 @@ async function main() {

### Assemble the data and mint

- #### Step 19: Then, all we have left to do is assemble the metadata pointing to our uploaded assets, and to mint the NFT.
- #### Step 19: Then, all you have left to do is assemble the metadata pointing to your uploaded assets, and to mint the NFT.

In the `src/node/index.js` script, add the following:

Expand Down Expand Up @@ -458,7 +458,7 @@ async function main() {
...metadata,
];

// set our minting identity as the recipient - replace if you have airdrops in mind
// set your minting identity as the recipient - replace if you have airdrops in mind
const principal = await (await identity).getPrincipal();
const mintResult = await actor.mint(principal, BigInt(idx), data);

Expand Down
4 changes: 2 additions & 2 deletions docs/developer-docs/backend/candid/candid-howto.md
Original file line number Diff line number Diff line change
Expand Up @@ -22,9 +22,9 @@ If you write a canister in Motoko, for example, the compiler automatically gener

For canisters written in Rust, the Candid extractor tool can be used with the IC CDK version `0.11.0` and newer. You can find the full instructions for using the Candid extractor [here](/docs/current/developer-docs/backend/candid/generating-candid).

In other languages, you will have to write the Candid interface description manually. With the help of types, we have developed tools to automatically generate UI and perform random testing based on the service description file.
In other languages, you will have to write the Candid interface description manually. With the help of types, tools have been developed to automatically generate UI and perform random testing based on the service description file.

With the help of types, we developed tools to automatically generate UI and perform random testing based on the service description file.
With the help of types, tools have been developed to automatically generate UI and perform random testing based on the service description file.

## Interact with a service in a terminal

Expand Down
2 changes: 1 addition & 1 deletion docs/developer-docs/backend/motoko/access-control.md
Original file line number Diff line number Diff line change
Expand Up @@ -215,7 +215,7 @@ Backend canister via Candid interface:

## Check the current identity context

Before we create any additional identities, let’s review the principal identifiers associated with the `owner` identity and the cycles wallet for your `owner` identity. This `owner` identity is created when your canisters were deployed.
Before you create any additional identities, let’s review the principal identifiers associated with the `owner` identity and the cycles wallet for your `owner` identity. This `owner` identity is created when your canisters were deployed.

On the Internet Computer blockchain, a principal is the internal representative for a user, canister, node, or subnet. The textual representation for a principal is the external identifier you see displayed with working with the principal data type.

Expand Down
Loading

0 comments on commit ac939ba

Please sign in to comment.