diff --git a/README.md b/README.md index 286b98ac19..681eb8a50b 100644 --- a/README.md +++ b/README.md @@ -598,15 +598,19 @@ The [Ecosystem Helper](https://mvw4g-yiaaa-aaaam-abnva-cai.icp0.io/) is an oncha The list of tags is not final, and will be updated as the project evolves. For now, the following tags are available: -- `Wallet` +- `AI` +- `Chain Fusion` - `Bitcoin` -- `NFT` -- `SocialFi` +- `Ethereum` +- `DAO` - `DeFi` +- `Enterprise` - `Games` -- `DAO` - `Metaverse` +- `NFT` +- `SocialFi` - `Tools / Infrastructure` +- `Wallet` ### Object schema @@ -617,7 +621,7 @@ The list of tags is not final, and will be updated as the project evolves. For n oneLiner: string, // short description of the project website: string, // URL starting with `https://` - tags: ('Wallet' | 'Bitcoin' | 'NFT' | 'SocialFi' | 'DeFi' | 'Games' | 'DAO' | 'Metaverse' | 'Tools / Infrastructure')[], + tags: ('AI' | 'Chain Fusion' | 'Bitcoin' | 'Ethereum' | 'DAO' | 'DeFi' | 'Enterprise' | 'Games' | 'Metaverse' | 'NFT' | 'SocialFi' | 'Tools / Infrastructure' | 'Wallet')[], description: string, // description of the project stats: string, // eg. "10,000 users" logo: string, // url to logo file, eg. /img/showcase/awesome-icp-project_logo.webp diff --git a/docs/developer-docs/developer-tools/ide/gitpod.mdx b/docs/developer-docs/developer-tools/ide/gitpod.mdx index e1120ba12d..42f512d223 100644 --- a/docs/developer-docs/developer-tools/ide/gitpod.mdx +++ b/docs/developer-docs/developer-tools/ide/gitpod.mdx @@ -53,7 +53,7 @@ In this example, we'll use the [DFINITY examples repo](https://github.com/dfinit - #### Step 8: To deploy your canister, first assure that your project has a `dfx.json` file. -[Learn more about the `dfx.json` file](/docs/current/developer-docs/smart-contracts/write/default-template) +[Learn more about the `dfx.json` file](/docs/current/developer-docs/smart-contracts/write/overview) ![Gitpod step 8](./_attachments/gitpod8.png) diff --git a/docs/developer-docs/developer-tools/off-chain/agents/nodejs.mdx b/docs/developer-docs/developer-tools/off-chain/agents/nodejs.mdx index 898d68e495..ad43265796 100644 --- a/docs/developer-docs/developer-tools/off-chain/agents/nodejs.mdx +++ b/docs/developer-docs/developer-tools/off-chain/agents/nodejs.mdx @@ -191,7 +191,7 @@ This test will do the following: - Defines a test method that accepts two arguments. Inside this method, `expect` is used to check the result of the backend canister's `greet` function against the expected result. -This test is written for the [default backend canister](/docs/current/developer-docs/smart-contracts/write/default-template). +This test is written for the [default backend canister](/docs/current/developer-docs/smart-contracts/write/overview). To run this test, you will need to deploy your project and generate the necessary declarations for your canister. [Learn more about creating and deploying a project](https://internetcomputer.org/docs/current/tutorials/developer-journey/level-2/2.5-unit-testing#end-to-end-e2e-testing). diff --git a/docs/developer-docs/smart-contracts/call/overview.mdx b/docs/developer-docs/smart-contracts/call/overview.mdx index d60fcd910a..fad8ff6515 100644 --- a/docs/developer-docs/smart-contracts/call/overview.mdx +++ b/docs/developer-docs/smart-contracts/call/overview.mdx @@ -26,24 +26,28 @@ A query method can be called as both an update and a query, whereas update metho | Goes through consensus | Does not go through consensus | | Synchronous response | Synchronous response | | Executed on all nodes of a subnet | Executed on a single node | - +| Cost cycles | Free | See the reference on [ingress messages](/docs/current/references/ingress-messages) for a more technical discussion of this topic. ## Update calls -Update calls are executed on all nodes of a subnet since the result of the call must go through consensus. This makes them slower than query calls. They are submitted asynchronously and answered synchronously. +Update calls are executed on all nodes of the subnet that the canister is deployed on since the result of the call must go through consensus. This makes them slower than query calls. They are submitted asynchronously and answered synchronously. + +:::danger +Update calls do not go through consensus on the local replica. +::: ### Making update calls To make a update call to a canister, use the [`dfx canister call`](/docs/current/developer-docs/developer-tools/cli-tools/cli-reference/dfx-canister#dfx-canister-call) command with the `--update` flag: -- `dfx canister call --update ` : Make an update call to a canister deployed locally. The local replica must be running to create a canister locally. Start it with `dfx start --background`. +- `dfx canister call --update ` : Make an update call to a canister deployed locally. The local replica must be running to create a canister locally. Start it with `dfx start --background`. -- `dfx canister call --update --network=playground`: Make an update call to a canister deployed on the playground. Making update calls to canisters deployed on the playground is free, but canisters are temporary and will be removed after 20 minutes. +- `dfx canister call --update --network=playground`: Make an update call to a canister deployed on the [playground](/docs/current/developer-docs/smart-contracts/deploy/overview#testnets). Making update calls to canisters deployed on the playground is free, but canisters are temporary and will be removed after 20 minutes. -- `dfx canister call --update --network=ic`: Make an update call to a canister deployed on the mainnet. Update calls will cost [cycles](/docs/current/developer-docs/gas-cost). +- `dfx canister call --update --network=ic`: Make an update call to a canister deployed on the mainnet. Update calls will cost [cycles](/docs/current/developer-docs/gas-cost). ### Using update calls from within canisters @@ -51,61 +55,27 @@ To make a update call to a canister, use the [`dfx canister call`](/docs/current -```motoko -actor Counter { - - stable var counter = 0; - - public func inc() : async () { - counter += 1; - }; -}; +```motoko file=../../../references/samples/motoko/counter/src/Main.mo#L10-L13 ``` -```rust -use candid::types::number::Nat; -use std::cell::RefCell; - -thread_local! { - static COUNTER: RefCell = RefCell::new(Nat::from(0_u32)); -} - -#[ic_cdk::update] -fn inc() { - COUNTER.with(|counter| *counter.borrow_mut() += 1_u32); -} +```rust file=../../../references/samples/rust/counter/src/lib.rs#L14-L19 ``` }> -```typescript -Azle code coming soon. - [Learn more about Azle.](https://demergent-labs.github.io/azle/) -``` }> -```python -Kybra code coming soon. - [Learn more about Kybra.](https://demergent-labs.github.io/kybra/) -``` - -:::caution - -Kybra canisters must be deployed from a Python virtual environment. [Learn more in the Kybra docs](/docs/current/developer-docs/backend/python/). - -::: - @@ -119,6 +89,16 @@ Query calls, also referred to as non-replicated queries, are executed on a singl To make a query call to a canister, use the [`dfx canister call`](/docs/current/developer-docs/developer-tools/cli-tools/cli-reference/dfx-canister#dfx-canister-call) command with the `--query` flag: +- `dfx canister call --query `: Make a query call to a canister deployed locally. The local replica must be running to create a canister locally. Start it with `dfx start --background`. + +- `dfx canister call --query --network=playground`: Make a query call to a canister deployed on the [playground](/docs/current/developer-docs/smart-contracts/deploy/overview#testnets). Query calls are free, but canisters are temporary and will be removed after 20 minutes. + +- `dfx canister call --query --network=ic`: Make a query call to a canister deployed on the mainnet. Query calls are free. + +### Making query calls + +To make a query call to a canister, use the [`dfx canister call`](/docs/current/developer-docs/developer-tools/cli-tools/cli-reference/dfx-canister#dfx-canister-call) command with the `--query` flag: + - `dfx canister call --query `: Make a query call to a canister deployed locally. The local replica must be running to create a canister locally. Start it with `dfx start --background`. - `dfx canister call --query --network=playground`: Make a query call to a canister deployed on the playground. Query calls are free, but canisters are temporary and will be removed after 20 minutes. @@ -134,14 +114,7 @@ The downside of query calls is that the response is not trusted since it's comin -```motoko -actor { - - public func greet(name : Text) : async Text { - return "Hello, " # name # "!"; - }; - -}; +```motoko no-repl file=../../../references/samples/motoko/counter/src/Main.mo#L5-L9 ``` @@ -149,39 +122,20 @@ actor { -```rust -#[ic_cdk::query] -fn greet(name: String) -> String { - format!("Hello, {}!", name) -} +```rust file=../../../references/samples/rust/counter/src/lib.rs#L8-L12 ``` }> -```typescript -Azle code coming soon. - [Learn more about Azle.](https://demergent-labs.github.io/azle/) -``` }> -```python -Kybra code coming soon. - [Learn more about Kybra.](https://demergent-labs.github.io/kybra/) -``` - -:::caution - -Kybra canisters must be deployed from a Python virtual environment. [Learn more in the Kybra docs](/docs/current/developer-docs/backend/python/). - -::: - @@ -198,11 +152,11 @@ Typically, a call is processed within a single message execution unless there ar ### Composite queries -Composite queries are query calls that can call other queries on the same subnet. They can only be invoked by end users and not by other canisters. +[Composite queries](/docs/current/developer-docs/smart-contracts/advanced-features/composite-query) are query calls that can call other queries on the same subnet. They can only be invoked by end users and not by other canisters. ### Certified queries -Certified queries use certified variables to prove the authenticity of a piece of data that comes along with the query's response. Certified variables can be set via an update call, then read via a query call. +Certified queries use [certified variables](/docs/current/references/samples/motoko/cert-var/) to prove the authenticity of a piece of data that comes along with the query's response. Certified variables can be set via an update call, then read via a query call. ### Replicated queries diff --git a/docs/developer-docs/smart-contracts/compile.mdx b/docs/developer-docs/smart-contracts/compile.mdx index 197f6a01ca..d8cd71eb1c 100644 --- a/docs/developer-docs/smart-contracts/compile.mdx +++ b/docs/developer-docs/smart-contracts/compile.mdx @@ -47,11 +47,11 @@ To compile your canister's Wasm module, you can use the [`dfx build`](/docs/curr Compile your canisters from within the project's directory: -- `dfx build `: Compile a canister locally. The local replica must be running to compile a canister locally. Start it with `dfx start --background`. +- `dfx build `: Compile a canister locally. The local replica must be running to compile a canister locally. Start it with `dfx start --background`. -- `dfx build --network=playground`: Compile a canister on the playground. Compiling a canister on the playground is free, but canisters are temporary and will be removed after 20 minutes. +- `dfx build --network=playground`: Compile a canister on the playground. Compiling a canister on the playground is free, but canisters are temporary and will be removed after 20 minutes. -- `dfx build --network=ic`: Compile a canister on the mainnet. Compiling a canister on the mainnet will cost [cycles](/docs/current/developer-docs/gas-cost). +- `dfx build --network=ic`: Compile a canister on the mainnet. Compiling a canister on the mainnet will cost [cycles](/docs/current/developer-docs/gas-cost). - `dfx build --network=ic`: Compile all canisters in the project's `dfx.json` file on the mainnet. diff --git a/docs/developer-docs/smart-contracts/create.mdx b/docs/developer-docs/smart-contracts/create.mdx index 74693bf332..75abc51005 100644 --- a/docs/developer-docs/smart-contracts/create.mdx +++ b/docs/developer-docs/smart-contracts/create.mdx @@ -35,11 +35,11 @@ Canisters are created with [`dfx canister create`](/docs/current/developer-docs/ Create your canisters from within the project's directory: -- `dfx canister create `: Create a canister locally. The local replica must be running to create a canister locally. Start it with `dfx start --background`. +- `dfx canister create `: Create a canister locally. The local replica must be running to create a canister locally. Start it with `dfx start --background`. -- `dfx canister create --network=playground`: Create a canister on the playground. Creating a canister on the playground is free, but canisters are temporary and will be removed after 20 minutes. +- `dfx canister create --network=playground`: Create a canister on the [playground](/docs/current/developer-docs/smart-contracts/deploy/overview#testnets). Creating a canister on the playground is free, but canisters are temporary and will be removed after 20 minutes. -- `dfx canister create --network=ic`: Create a canister on the mainnet. Creating a canister on the mainnet will cost [cycles](/docs/current/developer-docs/gas-cost). +- `dfx canister create --network=ic`: Create a canister on the mainnet. Creating a canister on the mainnet will cost [cycles](/docs/current/developer-docs/gas-cost). - `dfx canister create --all --network=ic`: Create all canisters in the project's `dfx.json` file on the mainnet. diff --git a/docs/developer-docs/smart-contracts/deploy/overview.mdx b/docs/developer-docs/smart-contracts/deploy/overview.mdx index 29f20c1137..0185a6c09a 100644 --- a/docs/developer-docs/smart-contracts/deploy/overview.mdx +++ b/docs/developer-docs/smart-contracts/deploy/overview.mdx @@ -60,23 +60,23 @@ For most developers, the playground option can be used. For more advanced develo Write a smart contract.
- Create your canister. + Create your canister. Optional; dfx deploy will execute this step if not already complete.
- Compile your canister code into Wasm. + Compile your canister code into Wasm. Optional; dfx deploy will execute this step if not already complete.
- Install the Wasm module into your canister. + Install the Wasm module into your canister. Optional; dfx deploy will execute this step if not already complete. Verify you are in your project's directory and the canisters you'd like to deploy are configured in the project's `dfx.json` file. -- `dfx deploy hello_world`: Deploy a canister locally. The local replica must be running to deploy a canister locally. Start it with `dfx start --background`. +- `dfx deploy `: Deploy a canister locally. The local replica must be running to deploy a canister locally. Start it with `dfx start --background`. -- `dfx deploy hello_world --network=playground`: Deploy a canister on the playground. Deploying a canister on the playground is free, but canisters are temporary and will be removed after 20 minutes. +- `dfx deploy --network=playground`: Deploy a canister on the playground. Deploying a canister on the playground is free, but canisters are temporary and will be removed after 20 minutes. -- `dfx deploy hello_world --network=ic`: Deploy a canister on the mainnet. Deploying a canister on the mainnet will cost [cycles](/docs/current/developer-docs/gas-cost). +- `dfx deploy --network=ic`: Deploy a canister on the mainnet. Deploying a canister on the mainnet will cost [cycles](/docs/current/developer-docs/gas-cost). - `dfx deploy --network=ic`: Deploy all canisters in the project's `dfx.json` file on the mainnet. @@ -112,14 +112,14 @@ You can set a canister's init arguments when the canister is deployed by passing the `--argument` flag: ```bash -dfx deploy --argument "(arg in candid)" +dfx deploy --argument "(arg in candid)" ``` If several arguments should be used, an argument file can be defined with the `--argument-file` flag instead: ```bash -dfx deploy --argument-file file.txt +dfx deploy --argument-file file.txt ``` Alternatively, init arguments can be set in `dfx.json` in `dfx` versions diff --git a/docs/developer-docs/smart-contracts/development-workflow.mdx b/docs/developer-docs/smart-contracts/development-workflow.mdx index 77aa307952..59e89290dd 100644 --- a/docs/developer-docs/smart-contracts/development-workflow.mdx +++ b/docs/developer-docs/smart-contracts/development-workflow.mdx @@ -14,9 +14,8 @@ The Internet Computer Protocol (ICP) accepts and executes smart contracts in the In theory, developers could write valid smart contracts directly in the Wasm bytecode. Since that would be too tedious and time consuming, the standard practice is to write smart contract code in a higher-level language, such as JavaScript/TypeScript, Motoko, Python, or Rust, then compile it into Wasm. - -The primary developer tool in the ICP ecosystem is `dfx`. -It is a command line multi-tool that assists the developer throughout the entire development process, starting from the generation of developer keys and setting up a new project, to compiling, deploying, and managing smart contracts. +The primary developer tool in the ICP ecosystem is the IC SDK, which includes `dfx`. +`dfx` is a command line multi-tool that assists the developer throughout the entire development process, starting from the generation of developer keys and setting up a new project, to compiling, deploying, and managing smart contracts.
canister and use the UI of the webpage to interact with the backend canister. Under the hood, the UI uses JavaScript and the [ICP JavaScript agent](https://www.npmjs.com/package/@dfinity/agent) to send messages to the backend smart contract. This is the standard way to interact with the smart contract that regular users would also use. -1. Use the `dfx canister call` command and pass the input arguments as command line arguments. +2. Use the `dfx canister call` command and pass the input arguments as command line arguments. Under the hood, `dfx` uses a Rust library called ic-agent to send messages to the smart contract. -1. Write an off-chain program that uses an [agent library](/docs/current/developer-docs/developer-tools/off-chain/agents/overview) to send messages to the smart contract. +3. Write an off-chain program that uses an [agent library](/docs/current/developer-docs/developer-tools/off-chain/agents/overview) to send messages to the smart contract.
- -## Next steps - -- [Install dev tools](/docs/current/developer-docs/getting-started/install). - -- [Start the developer ladder series](/docs/current/tutorials/developer-journey/). diff --git a/docs/developer-docs/smart-contracts/install.mdx b/docs/developer-docs/smart-contracts/install.mdx index 8aea9ca674..4e768572e8 100644 --- a/docs/developer-docs/smart-contracts/install.mdx +++ b/docs/developer-docs/smart-contracts/install.mdx @@ -41,11 +41,11 @@ Canister code must be [compiled](/docs/current/developer-docs/smart-contracts/co Code must be installed into a canister using the [`dfx canister install`](/docs/current/developer-docs/developer-tools/cli-tools/cli-reference/dfx-canister#dfx-canister-install) command from the project's directory: -- `dfx canister install hello_world`: Install canister code locally. The local replica must be running to create a canister locally. Start it with `dfx start --background`. +- `dfx canister install `: Install canister code locally. The local replica must be running to create a canister locally. Start it with `dfx start --background`. -- `dfx canister install hello_world --network=playground`: Install canister code on the playground. Installing code in a canister on the playground is free, but canisters are temporary and will be removed after 20 minutes. +- `dfx canister install --network=playground`: Install canister code on the playground. Installing code in a canister on the [playground](/docs/current/developer-docs/smart-contracts/deploy/overview#testnets) is free, but canisters are temporary and will be removed after 20 minutes. -- `dfx canister install hello_world --network=ic`: Install canister code on the mainnet. Installing code in a canister on the mainnet will cost [cycles](/docs/current/developer-docs/gas-cost). +- `dfx canister install --network=ic`: Install canister code on the mainnet. Installing code in a canister on the mainnet will cost [cycles](/docs/current/developer-docs/gas-cost). - `dfx canister install --all --network=ic`: Install code for all canisters in the project's `dfx.json` file on the mainnet. diff --git a/docs/developer-docs/smart-contracts/maintain/control.mdx b/docs/developer-docs/smart-contracts/maintain/control.mdx index 78e8bde741..80ecd4000c 100644 --- a/docs/developer-docs/smart-contracts/maintain/control.mdx +++ b/docs/developer-docs/smart-contracts/maintain/control.mdx @@ -64,4 +64,4 @@ A canister has no controller and is immutable. On ICP, this model is often calle Common errors related to controllers include: -- [Invalid controller](/docs/current/references/execution-errors#invalid-controller). \ No newline at end of file +- [Invalid controller](/docs/current/references/execution-errors#invalid-controller). diff --git a/docs/developer-docs/smart-contracts/maintain/delete.mdx b/docs/developer-docs/smart-contracts/maintain/delete.mdx index 1a90ecde6b..350c038dc1 100644 --- a/docs/developer-docs/smart-contracts/maintain/delete.mdx +++ b/docs/developer-docs/smart-contracts/maintain/delete.mdx @@ -21,4 +21,4 @@ Common errors related to canister deletion include: - [Delete canister not stopped](/docs/current/references/execution-errors#delete-canister-not-stopped). - [Delete canister self](/docs/current/references/execution-errors#delete-canister-self). -- [Delete canister queue not empty](/docs/current/references/execution-errors#delete-canister-queue-not-empty). \ No newline at end of file +- [Delete canister queue not empty](/docs/current/references/execution-errors#delete-canister-queue-not-empty). diff --git a/docs/developer-docs/smart-contracts/overview/canister-lifecycle.mdx b/docs/developer-docs/smart-contracts/overview/canister-lifecycle.mdx index 04c9512ba3..aedce8fab7 100644 --- a/docs/developer-docs/smart-contracts/overview/canister-lifecycle.mdx +++ b/docs/developer-docs/smart-contracts/overview/canister-lifecycle.mdx @@ -20,7 +20,7 @@ Usually, developers write code in a higher-level language and then compile the c ## Create A developer can create an empty canister on ICP by calling the system canister. -It can be done using the [NNS frontend dapp](/docs/current/developer-docs/daos/nns/using-the-nns-dapp/nns-app-quickstart#deploying-and-managing-canisters-from-the-nns-dapp) in the browser or [`dfx`](/docs/current/developer-docs/developer-tools/cli-tools/cli-reference/) in the command line. +It can be done using [`dfx canister create`](/docs/current/developer-docs/developer-tools/cli-tools/cli-reference/dfx-canister#dfx-canister-create) in the command line or the [NNS frontend dapp](/docs/current/developer-docs/daos/nns/using-the-nns-dapp/nns-app-quickstart#deploying-and-managing-canisters-from-the-nns-dapp) in the browser. The developer can specify the initial canister settings and choose the target subnet. Once the canister is created, the developer gets its canister ID and becomes the controller of the canister. @@ -32,15 +32,15 @@ Once the canister is created, the developer gets its canister ID and becomes the ## Compile -Once an empty canister has been created, the canister's code must be compiled into a Wasm binary. +Once an empty canister has been created, the canister's code must be compiled into a Wasm binary using [`dfx build`](/docs/current/developer-docs/developer-tools/cli-tools/cli-reference/dfx-build). [Learn more about compiling code into Wasm](../compile.mdx). ## Install -The next step after writing the code and creating a canister is installing the code into the canister. +The next step after writing the code, creating a canister, and compiling the code is installing the code into the canister. This can be done by calling the `install_code` endpoint of the system canister and passing the canister ID and the Wasm binary to it. -The `dfx` tool has [a command](/docs/current/developer-docs/developer-tools/cli-tools/cli-reference/dfx-canister#dfx-canister-install) for making this call. +The [`dfx canister install`](/docs/current/developer-docs/developer-tools/cli-tools/cli-reference/dfx-canister#dfx-canister-install) command is used for making this call.
Install canister @@ -48,7 +48,7 @@ The `dfx` tool has [a command](/docs/current/developer-docs/developer-tools/cli- ## Deploy -Once a canister has an installed Wasm binary, it can be deployed to the local, testnet, or mainnet environments. +Once a canister has an installed Wasm binary, it can be deployed to the local, playground, or mainnet environments with [`dfx deploy`](/docs/current/developer-docs/developer-tools/cli-tools/cli-reference/dfx-deploy). [Learn more about deploying canisters](../deploy/overview.mdx). diff --git a/docs/developer-docs/smart-contracts/overview/trust-in-canisters.mdx b/docs/developer-docs/smart-contracts/overview/trust-in-canisters.mdx index c4ed48e7ab..3c65c7ee6a 100644 --- a/docs/developer-docs/smart-contracts/overview/trust-in-canisters.mdx +++ b/docs/developer-docs/smart-contracts/overview/trust-in-canisters.mdx @@ -40,10 +40,10 @@ Canister controllers, if not voluntarily decentralized, have complete control ov The simplest option is to remove a canister's controller. Without a controller, the canister can only be mutated by the NNS via NNS proposal, assuming the integrity of the platform is maintained. -A user can verify the list of controllers for a canister using `dfx`: +A user can verify the list of controllers for a canister using [`dfx canister info`](/docs/current/developer-docs/developer-tools/cli-tools/cli-reference/dfx-canister#dfx-canister-info): ``` -dfx canister --network ic info ryjl3-tyaaa-aaaaa-aaaba-cai +dfx canister info ryjl3-tyaaa-aaaaa-aaaba-cai --network ic ``` This will return the list of controllers for the canister with principal `ryjl3-tyaaa-aaaaa-aaaba-cai` (in this example, the ledger canister). @@ -58,4 +58,4 @@ Finally, a somewhat more useful solution is to pass control of the canister to a A more complex but powerful approach is to set the sole controller of the canister to a distributed governance mechanism. In this scenario, the NNS still has ultimate control over the canister even though it is not explicitly in the controller list. -The advantage of using another form of governance, such as an SNS, is that the governance of the canister can be tailored specifically to the canister or project that the canister is a part of. One can imagine different levels of complexity and control that such a governance mechanism may implement. An example is the [SNS feature](/docs/current/developer-docs/daos/sns/overview) which allows developers to set the controller of their canister(s) to some governing canister. Using an SNS, the trust requirements are moved to the SNS controlling the canister, where all of the considerations regarding code inspection and reproducibility apply. \ No newline at end of file +The advantage of using another form of governance, such as an SNS, is that the governance of the canister can be tailored specifically to the canister or project that the canister is a part of. One can imagine different levels of complexity and control that such a governance mechanism may implement. An example is the [SNS feature](/docs/current/developer-docs/daos/sns/overview) which allows developers to set the controller of their canister(s) to some governing canister. Using an SNS, the trust requirements are moved to the SNS controlling the canister, where all of the considerations regarding code inspection and reproducibility apply. diff --git a/docs/developer-docs/smart-contracts/write/default-template.mdx b/docs/developer-docs/smart-contracts/write/default-template.mdx deleted file mode 100644 index 4d0b6ec42f..0000000000 --- a/docs/developer-docs/smart-contracts/write/default-template.mdx +++ /dev/null @@ -1,385 +0,0 @@ ---- -keywords: [beginner, getting started, tutorial, project template, default template] ---- - -import TabItem from "@theme/TabItem"; -import { AdornedTabs } from "/src/components/Tabs/AdornedTabs"; -import { AdornedTab } from "/src/components/Tabs/AdornedTab"; -import { BetaChip } from "/src/components/Chip/BetaChip"; -import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow"; - - -# Default project template - - - -## Overview - -The `dfx new ` command creates a new project directory, template files, and a new `` Git repository for your project. - -When creating new projects with `dfx`, only alphanumeric characters and underscores should be used. This is to assure that project names are valid within Motoko, JavaScript, and other contexts. - -## Exploring the default project structure - -By default, the project structure will resemble the following: - - - - -```bash -hello/ -├── README.md # Default project documentation -├── dfx.json # Project configuration file -├── node_modules # Libraries for frontend development -├── package-lock.json -├── package.json -├── src # Source files directory -│ ├── hello_backend -│ │ └── main.mo -│ ├── hello_frontend -│ ├── assets -│ │ ├── logo.png -│ │ ├── main.css -│ │ └── sample-asset.txt -│ └── src -│ ├── index.html -│ └── index.js -└── webpack.config.js -``` - - - - -```bash -hello/ -├── README.md # Default project documentation -├── dfx.json # Project configuration file -├── node_modules # Libraries for frontend development -├── package-lock.json -├── package.json -├── src # Source files directory -│ ├── hello_backend -│ │ └── Cargo.toml -│ │ └── hello_backend.did -│ │ └── src -│ │ ├── lib.rs -│ ├── hello_frontend -│ ├── assets -│ │ ├── logo.png -│ │ ├── main.css -│ │ └── sample-asset.txt -│ └── src -│ ├── index.html -│ └── index.js -└── webpack.config.js -``` - - - -}> - -```bash - hello/ -├── README.md # Default project documentation -├── dfx.json # Project configuration file -├── node_modules -├── package-lock.json # Libraries for frontend development -├── package.json -├── src # Source files directory -│   ├── hello_backend -| | └── index.ts -│ ├── hello_frontend -│ ├── assets -│ │ ├── logo.png -│ │ ├── main.css -│ │ └── sample-asset.txt -│ └── src -│ ├── index.html -│ └── index.js -└── tsconfig.json -``` - - - - -}> - -``` -hello/ -├── README.md # Default project documentation -├── dfx.json # Project configuration file -├── node_modules # Libraries for frontend development -├── package-lock.json -├── package.json -├── src # Source files directory -│ ├── hello_backend -│ │ └── hello_backend.did -│ │ └── src -│ │ ├── main.py -│ ├── hello_frontend -│ ├── assets -│ │ ├── logo.png -│ │ ├── main.css -│ │ └── sample-asset.txt -│ └── src -│ ├── index.html -│ └── index.js -└── tsconfig.json -``` - - - - -In this directory, the following files and directories are notable: - -- `README.md`: The default README file to be used for documenting your project. -- `dfx.json`: The default configuration file used to set configurable options for your project. -- `src/`: The source directory that contains all of your dapp's source files. -- `hello_backend`: The source directory that contains your dapp's backend code files. -- `hello_frontend`: The source directory that contains your dapp's frontend code files. - -:::info - -**Why are there two canisters, `hello_backend` and `hello_frontend`?** - -The `hello_frontend` canister is used to store the dapp's frontend assets, such as HTML, CSS, JavaScript, React, images, videos, and other media to be displayed in the app's user interface. - -The `hello_backend` canister is used to store the dapp's code and core logic. - -A canister is capable of storing both the frontend assets and backend code, but using two canisters with a dedicated canister for the frontend means that any language can be used for the backend canister without needing a library for the assets storage API. - -::: - -## Reviewing the default configuration - -By default, the `dfx.json` file will contain automatically generated configuration settings for your new project. This file is used to configure the components of your project: - - - - -```json title="dfx.json" -{ - "canisters": { - "hello_backend": { - "main": "src/hello_backend/main.mo", - "type": "motoko" - }, - "hello_frontend": { - "dependencies": [ - "hello_backend" - ], - "frontend": { - "entrypoint": "src/hello_frontend/src/index.html" - }, - "source": [ - "src/hello_frontend/assets", - "dist/hello_frontend/" - ], - "type": "assets" - } - }, - "defaults": { - "build": { - "args": "", - "packtool": "" - } - }, - "output_env_file": ".env", - "version": 1 -} -``` - - - - - -```json title="dfx.json" -{ - "canisters": { - "hello_backend": { - "candid": "src/hello_backend/hello_backend.did", - "package": "hello_backend", - "type": "rust" - }, - "hello_frontend": { - "dependencies": [ - "hello_backend" - ], - "frontend": { - "entrypoint": "src/hello_frontend/src/index.html" - }, - "source": [ - "src/hello_frontend/assets", - "dist/hello_frontend/" - ], - "type": "assets" - } - }, - "defaults": { - "build": { - "args": "", - "packtool": "" - } - }, - "output_env_file": ".env", - "version": 1 -}% -``` - - - -}> - -```json title="dfx.json" -{ - "canisters": { - "hello_backend": { - "type": "azle", - "main": "src/hello_backend/index.ts", - "candid_gen": "automatic", - "declarations": { - "output": "test/dfx_generated/hello_backend", - "node_compatibility": true - } - } - "hello_frontend": { - "dependencies": [ - "hello_backend" - ], - "frontend": { - "entrypoint": "src/hello_frontend/src/index.html" - }, - "source": [ - "src/hello_frontend/assets", - "dist/hello_frontend/" - ], - "type": "assets" - } - }, -} -``` - - - -}> - -```json title="dfx.json" -{ - "canisters": { - "hello_backend": { - "type": "custom", - "build": "python -m kybra hello_backend src/hello_backend/src/main.py src/hello_backend/hello_backend.did", - "candid": "src/hello_backend/hello_backend.did", - "gzip": true, - "wasm": ".kybra/hello_backend/hello_backend.wasm" - "metadata": [ - { - "name": "candid:service", - "path": "src/main.did" - }, - { - "name": "cdk:name", - "content": "kybra" - } - ], - }, - "hello_frontend": { - "dependencies": [ - "hello_backend" - ], - "frontend": { - "entrypoint": "src/hello_frontend/src/index.html" - }, - "source": [ - "src/hello_frontend/assets", - "dist/hello_frontend/" - ], - "type": "assets" - } - }, - "defaults": { - "build": { - "args": "", - "packtool": "" - } - }, - "output_env_file": ".env", - "version": 1 -} -``` - - - - - -## Reviewing the default program code - -The backend canister's code will be located in the `src/hello_backend` subdirectory. - - - - -```motoko title="src/hello_backend/main.mo" - -actor { -public query func greet(name : Text) : async Text { - return "Hello, " # name # "!"; -}; -}; -``` - - - - -```rust title="src/hello_backend/src/lib.rs" -#[ic_cdk::query] -fn greet(name: String) -> String { - format!("Hello, {}!", name) -} -``` - - - -}> - -```typescript title="src/hello_backend/src/index.ts" -import { IDL, query, update } from 'azle'; - -export default class { - message: string = 'Hello world!'; - - @query([], IDL.Text) - getMessage(): string { - return this.message; - } - - @update([IDL.Text]) - setMessage(message: string): void { - this.message = message; - } -} -``` - - - -}> - -```python title="src/hello_backend/src/main.py" -from kybra import query - -@query -def greet(name: str) -> str: - return f"Hello, {name}!" -``` - - - - - -## Next steps - -To interact with this code, you first need to deploy the canister. To learn how to deploy to a local developer environment, see the documentation here: - -- [Local deployment](/docs/current/developer-docs/getting-started/deploy-and-manage). - - diff --git a/docs/developer-docs/smart-contracts/write/overview.mdx b/docs/developer-docs/smart-contracts/write/overview.mdx index bf109609d6..0e0fec65d4 100644 --- a/docs/developer-docs/smart-contracts/write/overview.mdx +++ b/docs/developer-docs/smart-contracts/write/overview.mdx @@ -15,11 +15,12 @@ import { BetaChip } from "/src/components/Chip/BetaChip"; ICP supports a wide range of applications and architecture types. -Apps can range from single smart contracts to complex, multi-canister projects that are controlled by a DAO and everything in between. + +Apps can range from a single canister to complex, multi-canister projects and everything in between. You can begin writing and structuring your application using one of two primary workflows: -- **Standard workflow**: The developer writes both the frontend code and the backend code, then deploys both to ICP as canisters. +- **Standard workflow**: The developer writes both the frontend and backend code, then deploys both to ICP as canisters. - **Framework-based workflow**: An external framework is used to help facilitate creating and deploying canisters. [Learn more about frameworks](#framework-based-workflow). @@ -47,7 +48,9 @@ Examples of production smart contracts that use Motoko include [ICDex](https://g ### Choosing a web framework for the frontend The [HTTP Gateway protocol](/docs/current/references/http-gateway-protocol-spec) of ICP allows browsers to load web assets such as JS, HTML, and CSS from a canister via HTTP. -This means that web assets can be stored fully onchain and developers don’t need to use traditional centralized web hosting to serve the UI of their application. +This means that [web assets can be stored fully onchain](/docs/current/developer-docs/web-apps/application-frontends/overview) and developers don’t need to use traditional centralized web hosting to serve the UI of their application. + +[Svelte](https://svelte.dev/), [React](https://react.dev/), and [Vue](https://vuejs.org/) have been used successfully in production. `dfx v0.17.0` and newer can be used to generate project templates that include one of these frameworks. [Learn more](/docs/current/developer-docs/web-apps/browser-js/js-frameworks). The typical development workflow of the frontend is: @@ -58,11 +61,8 @@ The typical development workflow of the frontend is: 5. The canister serves the web assets to the browser via its `http_request` endpoint that gets invoked for each HTTP request. 6. When the JS code runs in the browser, it can call the backend canister endpoints using the [ICP JavaScript agent](/docs/current/developer-docs/web-apps/browser-js/js-request-api) library, which is analogous to `web3.js` and `ethers.js` of Ethereum. -Since ICP supports general HTML, JS, and CSS code, any web framework should be compatible with ICP. -For example, SvelteKit, React, and Vue have been used successfully in production. `dfx v0.17.0` and newer can be used to generate project templates that include one of these frameworks. [Learn more](/docs/current/developer-docs/web-apps/browser-js/js-frameworks). - #### Limitations -One feature of modern web frameworks that currently doesn’t work in a canister is server-side rendering (SSR). That’s because SSR requires running JS code in the canister. +Server-side rendering (SSR) does not work in canisters because they require JS code that is not built into canisters. In the future, this might become possible with Azle. Until then, if SSR is required, then one solution is to host the frontend outside of ICP while keeping the core logic in the backend canister. Having no frontend at all is also a valid option for smart contracts that don’t have a UI and are callable only by users or other smart contracts. @@ -73,6 +73,15 @@ Having no frontend at all is also a valid option for smart contracts that don’ Install the IC SDK. +
+
+ Download and install an IDE or code editor. VS Code is recommended. + +:::tip + +For writing Motoko code, the [Motoko VS Code extension](https://marketplace.visualstudio.com/items?itemName=dfinity-foundation.vscode-motoko) is highly recommended for syntax highlighting. + +::: @@ -99,7 +108,7 @@ Navigate into your project directory: cd hello ``` -By default, the project structure will resemble the following: +For projects created with `dfx new`, the project structure will resemble the following. If you are using an ICP Ninja project or other sample project, project structure may vary. @@ -182,7 +191,7 @@ hello/ }> -``` +```bash hello/ ├── README.md # Default project documentation ├── dfx.json # Project configuration file @@ -211,20 +220,19 @@ hello/ In this directory, the following files and directories are notable: - `README.md`: The default README file to be used for documenting your project. -- `dfx.json`: The default configuration file used to set configurable options for your project. +- `dfx.json`: The default ICP configuration file used to set configurable options for your project. - `src/`: The source directory that contains all of your dapp's source files. - `hello_backend`: The source directory that contains your dapp's backend code files. - `hello_frontend`: The source directory that contains your dapp's frontend code files. ### Reviewing the default program code -The backend canister's code will be located in the `src/hello_backend` subdirectory. +Open the backend canister source code file in your code editor. The backend canister's code will be located in the `src/hello_backend` subdirectory. For projects created with `dfx new`, the default backend code will resemble the following. If you are using an ICP Ninja project or other sample project, program code will vary. ```motoko title="src/hello_backend/main.mo" - actor { public query func greet(name : Text) : async Text { return "Hello, " # name # "!"; @@ -246,28 +254,13 @@ fn greet(name: String) -> String { }> -```typescript title="src/hello_backend/src/index.ts" -import { Canister, query, text } from 'azle'; - -export default Canister({ - greet: query([text], text, (name) => { - return `Hello, ${name}!`; - }) -}) -``` +[Learn more about Azle.](https://demergent-labs.github.io/azle/) }> -```python title="src/hello_backend/src/main.py" -from kybra import query - -@query -def greet(name: str) -> str: - return f"Hello, {name}!" -``` - +[Learn more about Kybra.](https://demergent-labs.github.io/kybra/) @@ -277,23 +270,28 @@ def greet(name: str) -> str: ### Juno [Juno](/docs/current/developer-docs/web-apps/frameworks/juno) is a community project that is tailored for Web2 developers. It takes care of hosting code and data in canisters such that developers can write Web3 applications using familiar Web2 concepts and patterns. For more details, please follow [the official Juno documentation](https://juno.build/docs/intro). - ### Bitfinity EVM [Bitfinity EVM](/docs/current/developer-docs/backend/solidity/) is tailored for Solidity developers. It is a canister that runs an instance of the Ethereum virtual machine and allows developers to upload and execute smart contracts written in Solidity. For more details, please follow [the official Bitfinity documentation](https://docs.bitfinity.network/). ## Architecture considerations A common question when developing an application is how and where to store the data. In contrast to traditional platforms, ICP does not provide a database. -Instead, ICP automatically persists changes in the canister state, including its Wasm and stable memories. -This means that developers have a lot of freedom in organizing and storing the data. The recommended practice is to use already existing libraries, such as the Rust [stable-structures](https://github.com/dfinity/stable-structures) library, to store data in the stable memory. +Instead, ICP can persists changes in the canister state using stable memory. +This means that developers have a lot of freedom in organizing and storing the data. The recommended practice is to use already existing libraries, such as the Motoko [stable regions](https://internetcomputer.org/docs/current/motoko/main/stable-memory/stable-regions) library or the Rust [stable-structures](https://github.com/dfinity/stable-structures) library, to store data in the stable memory. Another question that developers should ask is how to structure their application. It is possible to build an application consisting of multiple canisters that communicate with each other. A common pitfall for new developers is designing the application for millions of users from the get-go without understanding the underlying trade-offs of the system. It is better to start with the simplest possible architecture and iteratively improve it with user growth. +### Canister per service architecture +Canisters can be thought of as microservices, where each canister is responsible for a specific service of the application, such as managing users, storing data, or processing data. +Note that all benefits and disadvantages of the traditional microservice architecture apply here as well. +The default project structure that [`dfx new`](/docs/current/developer-docs/developer-tools/cli-tools/cli-reference/dfx-new) generates can be viewed as the simplest microservice architecture, with the frontend canister being responsible for serving web assets and the backend canister being responsible for the core logic and of the application. + ### Single canister architecture This is the simplest possible architecture and the recommended starting point for most developers. + A single canister can host the entire application stack, including its web assets, core logic, and data. To write a single canister that hosts frontend assets and backend core logic, you will need to use a library for the asset storage API, such as the `ic-certified-assets` library for Rust canisters. A few examples of single canister projects include: - [HTTPS greet example](https://github.com/krpeacock/server/tree/main/examples/http_greet). diff --git a/docs/developer-docs/smart-contracts/write/resources.mdx b/docs/developer-docs/smart-contracts/write/resources.mdx deleted file mode 100644 index 7306edc138..0000000000 --- a/docs/developer-docs/smart-contracts/write/resources.mdx +++ /dev/null @@ -1,76 +0,0 @@ ---- -keywords: [beginner, write, resources, concept, ide, cdk] ---- - -import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow"; -import { Tooltip } from "/src/components/Tooltip/Tooltip"; - -# Resources - - - -## Overview - -After learning about the different [workflows](./overview.mdx) that can be followed when creating a canister, the [languages](./overview.mdx#choosing-the-programming-language-for-the-backend) that can be used, and the components that go into a canister, its time to write the canister code. - -To write canister code, several different tools can be used. - -## Canister development kits (CDKs) - -A canister development kit (CDK) provides programming languages with the necessary features and functionality to create, deploy, and manage canisters. CDKs are a popular choice for developers who prefer a standard development workflow. - -To develop using a CDK, see the documentation for the CDK of your choice below. - -DFINITY maintained CDKs include: - -- [Motoko](/docs/current/motoko/main/getting-started/motoko-introduction). - -- [Rust](/docs/current/developer-docs/backend/rust/) - -Community contributed and maintained CDKs include: - -- [Kybra: Python CDK - Beta](/docs/current/developer-docs/backend/python/). - -- [Azle: TypeScript CDK - Beta](/docs/current/developer-docs/backend/typescript/). - -- [C++ CDK](https://docs.icpp.world/). - -## Integrated development environments (IDEs) - -Another popular tool used in standard development workflows are integrated development environments (IDEs). IDEs are commonly used in conjunction with CDKs to create, edit, and manage code files. Any IDE can be used to create and edit canister code. Some examples with documentation include: - -- [Playground](/docs/current/developer-docs/developer-tools/ide/playground). - -- [Visual Studio Code](/docs/current/developer-docs/developer-tools/ide/vs-code). - -- [Gitpod](/docs/current/developer-docs/developer-tools/ide/gitpod). - - -## Frameworks - -As an alternative approach to the standard development workflow, a framework-based approach can be used. Frameworks offer additional services, such handling the canister deployment and data hosting for you. Currently supported frameworks include: - -- [Juno](/docs/current/developer-docs/web-apps/frameworks/juno). - -- [Bitfinity EVM](/docs/current/developer-docs/backend/solidity/). - -## Writing canister code tutorials - -Want to follow a tutorial for writing canister code? Check out these written and video tutorial resources: - -- [Writing smart contracts example](/docs/current/developer-docs/getting-started/write-smart-contracts). - -- [Developer ladder: 1.3: Deploying your first dapp - Documentation](/docs/current/tutorials/developer-journey/level-1/1.3-first-dapp). - -- [Developer ladder: 1.3: Deploying your first dapp - Video walkthrough](https://www.youtube.com/watch?v=oBUpJ4CqmN0). - -- [Developer ladder 2.1: Canister upgrades, storage, and persistence - Documentation](/docs/current/tutorials/developer-journey/level-2/2.1-storage-persistence). - -- [Developer ladder 2.1: Canister upgrades, storage, and persistence - Video walkthrough](https://www.youtube.com/watch?v=-aXjKSz_oXc). - -- [Sample projects](/docs/current/samples/overview). - -- [Zero to dApp education video series](https://youtube.com/playlist?list=PLuhDt1vhGcrcRcHvSKmxIgJAh1b3rcR7N&si=sIElj5bAkJeMqDoA). - -- [ICP YouTube channel](https://www.youtube.com/dfinity). - diff --git a/docs/samples/overview.mdx b/docs/samples/overview.mdx index 4601b2d47e..9fdb0eda1e 100644 --- a/docs/samples/overview.mdx +++ b/docs/samples/overview.mdx @@ -9,8 +9,8 @@ Take a look at some sample dapps below and see the possibilities of building on ## Hello, world! The dapp equivalent of 'Hello, World!' with a separate backend and frontend canister serving a web page. -- [Motoko](https://github.com/dfinity/examples/tree/master/motoko/hello). -- [Rust](https://github.com/dfinity/examples/tree/master/rust/hello). +- [Motoko](https://github.com/dfinity/icp-hello-world-motoko). +- [Rust](https://github.com/dfinity/icp-hello-world-rust). - [See a running example](https://6lqbm-ryaaa-aaaai-qibsa-cai.ic0.app/). ## Developer ladder series @@ -104,16 +104,9 @@ This tutorial shows how to quickly set up a static website structure, add conten The example shows how to deploy a web game on ICP, sample code can be found at [samples repo](https://github.com/dfinity/examples/tree/master/hosting). -## Token approve and transfer from - -This sample code demonstrates how a canister can be approved to transfer funds on behalf of a user. -- [Motoko](https://github.com/dfinity/examples/tree/master/motoko/token_transfer_from). -- [Rust](https://github.com/dfinity/examples/tree/master/rust/token_transfer_from). - ## ICP transfer This sample code demonstrates how a canister can hold and transfer ICP tokens. -- [Motoko](https://github.com/dfinity/examples/tree/master/motoko/icp_transfer). - [Rust](https://github.com/dfinity/examples/tree/master/rust/icp_transfer). ## ICRC-2 token swap @@ -124,10 +117,6 @@ This sample code demonstrates how a canister can hold and transfer ICP tokens. - [Motoko](https://github.com/dfinity/examples/tree/master/motoko/internet_identity_integration). -## Invoice canister - -- [Motoko](https://github.com/dfinity/examples/tree/master/motoko/invoice-canister). - ## Minimal counter dapp The example dapp shows how to build a very basic dapp with both backend and frontend, using Motoko for the backend functionality and plain HTML and JavaScript for the frontend. The dapp is a simple counter, which will increment a counter by clicking a button in the frontend. @@ -145,7 +134,7 @@ This is an NFT wallet example dapp that utilizes minted NFTs from the Rust dip72 - [Rust](https://github.com/dfinity/examples/tree/master/rust/nft-wallet). -## Paralell calls +## Parallel calls - [Motoko](https://github.com/dfinity/examples/tree/master/motoko/parallel_calls). - [Rust](https://github.com/dfinity/examples/tree/master/rust/parallel_calls). @@ -211,8 +200,9 @@ This example is a simple CRUD dapp. - [Motoko](https://github.com/dfinity/examples/tree/master/motoko/token_transfer). - [Rust](https://github.com/dfinity/examples/tree/master/rust/token_transfer). -## Token transfer_from +## Token approve and transfer from +This sample code demonstrates how a canister can be approved to transfer funds on behalf of a user. - [Motoko](https://github.com/dfinity/examples/tree/master/motoko/token_transfer_from). - [Rust](https://github.com/dfinity/examples/tree/master/rust/token_transfer_from). diff --git a/plugins/utils/redirects.js b/plugins/utils/redirects.js index 2a455333ff..0ef9bb9a49 100644 --- a/plugins/utils/redirects.js +++ b/plugins/utils/redirects.js @@ -220,7 +220,7 @@ const redirects = ` /docs/current/developer-docs/setup/cycles/cycles-faucet /docs/current/developer-docs/getting-started/tokens-and-cycles /docs/current/developer-docs/setup/cycles/cycles-wallet /docs/current/developer-docs/defi/cycles/cycles-wallet /docs/current/developer-docs/setup/cycles/converting_icp_tokens_into_cycles /docs/current/developer-docs/defi/cycles/converting_icp_tokens_into_cycles - /docs/current/developer-docs/setup/first-canister /docs/current/developer-docs/smart-contracts/write/default-template + /docs/current/developer-docs/setup/first-canister /docs/current/developer-docs/smart-contracts/write/overview /docs/current/developer-docs/setup/deploy-locally /docs/current/developer-docs/getting-started/deploy-and-manage /docs/current/developer-docs/setup/deploy-mainnet /docs/current/developer-docs/getting-started/deploy-and-manage /docs/current/developer-docs/production/best-practices /docs/current/developer-docs/smart-contracts/best-practices/general @@ -632,13 +632,14 @@ const redirects = ` /docs/current/developer-docs/smart-contracts/call/arguments /docs/current/developer-docs/smart-contracts/call/overview /docs/current/developer-docs/smart-contracts/candid/ /docs/current/developer-docs/smart-contracts/candid/candid-concepts /docs/current/developer-docs/getting-started/development-workflow /docs/current/developer-docs/smart-contracts/development-workflow - /docs/current/developer-docs/getting-started/default-template /docs/current/developer-docs/smart-contracts/write/default-template + /docs/current/developer-docs/getting-started/default-template /docs/current/developer-docs/smart-contracts/write/overview /docs/current/developer-docs/getting-started/hello-world /docs/current/developer-docs/getting-started/write-smart-contracts /docs/current/developer-docs/getting-started/cycles/overview /docs/current/developer-docs/getting-started/tokens-and-cycles /docs/current/developer-docs/getting-started/accounts /docs/current/developer-docs/getting-started/identities /docs/current/developer-docs/getting-started/deploy/local /docs/current/developer-docs/getting-started/deploy-and-manage /docs/current/developer-docs/getting-started/deploy/testnet /docs/current/developer-docs/getting-started/deploy-and-manage /docs/current/developer-docs/getting-started/deploy-and-manage /docs/current/developer-docs/getting-started/deploy-and-manage + /docs/current/developer-docs/smart-contracts/write/default-template /docs/current/developer-docs/smart-contracts/write/overview ` .split(/[\r\n]+/) .map((line) => line.trim().replace(/^#.*$/, "").trim()) diff --git a/showcase.json b/showcase.json index 2003fd045b..dab55450b9 100644 --- a/showcase.json +++ b/showcase.json @@ -517,19 +517,20 @@ { "id": "rubaru", "name": "RuBaRu", - "oneLiner": "Building Onchain Regenerative Creator-Consumer Economy", + "oneLiner": "The fully on-chain content creator/influencer platform: own your profile, own your content, and earn fair incentives.", "website": "https://rubaru.app/", "tags": [ "SocialFi" ], - "description": "RuBaRu aims to create a vibrant 100% Onchain DAO-based tokenized economy owned & governed by the community, where creators, influencers, consumers, and brands coexist harmoniously. By doing so, we unlock new opportunities, reshape digital creativity, drive economic growth, and foster a thriving ecosystem of shared prosperity.", + "stats": "190+ canisters N/W, On-chain content : 15k+ images & 5k+ videos", + "description": "The fully on-chain content creator/influencer platform: own your profile, own your content, and earn fair incentives.", "logo": "/img/showcase/rubaru_logo.png", "display": "Large", "usesInternetIdentity": true, "youtube": "https://youtu.be/CBumSMJRV08", "twitter": "https://twitter.com/RuBaRu_app", "screenshots": [ - "/img/showcase/rubaru_dapp_screenshots.png" + "/img/showcase/rubaru_dapp_screenshot.png" ], "video": "/img/showcase/rubaru_video.mp4", "videoContentType": "video/mp4", @@ -2068,21 +2069,21 @@ { "id": "chainsight", "name": "Chainsight", - "oneLiner": "Interchain Data Processing Layer", + "oneLiner": "An advanced on-chain data hub that aggregates data from various markets and makes it accessible on-chain.", "tags": [ "Tools / Infrastructure", "Ethereum", "Chain Fusion" ], - "description": "Chainsight is an interchain data processing layer that makes blockchain data available for decentralized applications. It allows time series analysis and forecasting based on historical data to be incorporated into onchain application logic in a trustless manner.", + "description": "An advanced on-chain data hub that aggregates data from various markets and makes it accessible on-chain.", "usesInternetIdentity": false, - "website": "https://demo.chainsight.network", + "website": "https://chainsight.network", "github": "https://github.com/horizonx-tech", "twitter": "https://twitter.com/Chainsight_", "display": "Large", "logo": "/img/showcase/chainsight_logo.webp", "screenshots": [ - "/img/showcase/chainsight_screenshot.webp" + "/img/showcase/chainsight_screenshot.png" ], "submittableId": "36057758" }, @@ -2922,10 +2923,9 @@ { "id": "icgpt", "name": "icgpt", - "oneLiner": "A fun dApp to demonstrate onchain LLMs", + "oneLiner": "A chat app that uses Qwen2.5-instruct LLM with 0.5 billion parameters, the largest LLM currently live on ICP.", "website": "https://icgpt.icpp.world/", - "description": "A llama2 LLM, trained on the tiny Stories dataset is running in a canister. You can interact with it via a ChatGPT style frontend, served from an IC canister. You provide the start of a story as the prompt, and the LLM will generate a tiny story.", - "stats": "15M parameter llama2", + "description": "A chat app that uses Qwen2.5-instruct LLM with 0.5 billion parameters, the largest LLM currently live on ICP.", "tags": [ "Tools / Infrastructure", "AI" @@ -3054,12 +3054,11 @@ { "name": "ICSoccerWorld", "description": "Soccer simulation built for ICP using ICPP. Based on code sample from book \"AI Game Programming by Example\". Demo is built in C++ and uses Jolt physics Engine.", - "website": "https://github.com/ktimam/ICSimpleSoccer", + "website": "https://gb4ri-5yaaa-aaaal-ac3hq-cai.raw.icp0.io/", "logo": "/img/showcase/ICSoccerWorld.png", "display": "Normal", "id": "ICSoccerWorld", - "oneLiner": "Physics Based Soccer Simulation.", - "stats": "Community Dev Demo", + "oneLiner": "Soccer simulation built for ICP using ICPP. ", "tags": [ "NFT", "Metaverse", @@ -3069,9 +3068,7 @@ "usesInternetIdentity": false, "github": "https://github.com/ktimam/ICSimpleSoccer", "twitter": "https://twitter.com/ICSoccerWorld", - "youtube": "", - "submittableId": "44414655", - "videoContentType": "video/mp4" + "submittableId": "44414655" }, { "name": "Mapz", @@ -3432,18 +3429,20 @@ { "id": "gamebloc", "name": "Game Bloc", - "oneLiner": "A decentralised platform for hosting game tournaments which can either be crowdfunded or prepaid.", + "oneLiner": "A decentralized platform empowering gamers and gaming organizations to create, manage, and participate in game tournaments.", "website": "https://cv4ma-4qaaa-aaaal-adntq-cai.icp0.io/", "github": "https://github.com/Game-Bloc/Gamebloc-ICP", "twitter": "https://twitter.com/game_bloc", "discord": "https://discord.gg/wgRuenwTEK", + "youtube": "https://www.youtube.com/@Game_bloc", "tags": [ - "Games" + "Games", + "SocialFi" ], - "description": "A decentralised platform for hosting game tournaments which can either be crowdfunded or prepaid.", + "description": "A decentralized platform empowering gamers and gaming organizations to create, manage, and participate in game tournaments.", "usesInternetIdentity": true, "display": "Normal", - "logo": "/img/showcase/gameblock_logo.png", + "logo": "/img/showcase/gamebloc_logo.png", "submittableId": "44503915" }, { @@ -3835,15 +3834,16 @@ { "id": "icpexchange", "name": "ICPEx", - "oneLiner": "Decentralized exchange built entirely on the chain based on the ICP.", + "oneLiner": "A fully on-chain decentralized exchange powered by the Proactive Market Maker (PMM) algorithm.", "tags": [ "DeFi" ], - "description": "Decentralized exchange built entirely on the chain based on the ICP.", + "description": "A fully on-chain decentralized exchange powered by the Proactive Market Maker (PMM) algorithm that is committed to becoming the leading decentralized financial hub serving Web3.", "usesInternetIdentity": true, "website": "https://icpex.org/", "github": "https://github.com/ICPExchange", "twitter": "https://twitter.com/ICPExchange", + "youtube": "https://www.youtube.com/@ICPExchange", "display": "Normal", "stats": "229 tokens and 90 liquidity pools created", "logo": "/img/showcase/icpex_logo.png", @@ -4943,5 +4943,19 @@ ], "twitter": "https://x.com/phasmafuture", "website": "https://entrepot.app/marketplace/phasma" + }, + { + "id": "medblock", + "name": "Medblock", + "description": "Medblock is a secure mobile app that puts medical records in patients' hands while helping hospitals manage healthcare data efficiently through blockchain technology.", + "logo": "/img/showcase/medblock.svg", + "display": "Normal", + "tags": [ + "Enterprise" + ], + "github": "https://github.com/baliola/Medblock", + "twitter": "https://x.com/medblockid", + "website": "https://medblock.id", + "submittableId": "44389918" } ] \ No newline at end of file diff --git a/src/components/DocsHome/index.tsx b/src/components/DocsHome/index.tsx index b1dcd9d206..032949d2c5 100644 --- a/src/components/DocsHome/index.tsx +++ b/src/components/DocsHome/index.tsx @@ -351,7 +351,7 @@ const Education = () => { { title: (

- Start your developer journey with Jessie + Start your developer ladder with Jessie

), subtitle: ( @@ -369,7 +369,7 @@ const Education = () => { ), - mainImage: "/img/docs/teaser-cards/main-1.svg", + mainImage: "/img/docs/teaser-cards/developerLadder.svg", }, { title:

Hackathon Prep Course

, diff --git a/static/img/docs/teaser-cards/developerLadder.svg b/static/img/docs/teaser-cards/developerLadder.svg new file mode 100644 index 0000000000..6d0bf49a06 --- /dev/null +++ b/static/img/docs/teaser-cards/developerLadder.svg @@ -0,0 +1,979 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/static/img/docs/teaser-cards/main-1.svg b/static/img/docs/teaser-cards/main-1.svg deleted file mode 100644 index b887e02a95..0000000000 --- a/static/img/docs/teaser-cards/main-1.svg +++ /dev/null @@ -1 +0,0 @@ - \ No newline at end of file diff --git a/static/img/showcase/chainsight_screenshot.png b/static/img/showcase/chainsight_screenshot.png new file mode 100644 index 0000000000..6ad69c38da Binary files /dev/null and b/static/img/showcase/chainsight_screenshot.png differ diff --git a/static/img/showcase/chainsight_screenshot.webp b/static/img/showcase/chainsight_screenshot.webp deleted file mode 100644 index 11e283ee27..0000000000 Binary files a/static/img/showcase/chainsight_screenshot.webp and /dev/null differ diff --git a/static/img/showcase/gamebloc_logo.png b/static/img/showcase/gamebloc_logo.png new file mode 100644 index 0000000000..4d824850d0 Binary files /dev/null and b/static/img/showcase/gamebloc_logo.png differ diff --git a/static/img/showcase/gameblock_logo.png b/static/img/showcase/gameblock_logo.png deleted file mode 100644 index bb488e1ebb..0000000000 Binary files a/static/img/showcase/gameblock_logo.png and /dev/null differ diff --git a/static/img/showcase/medblock.svg b/static/img/showcase/medblock.svg new file mode 100644 index 0000000000..dbef7d3150 --- /dev/null +++ b/static/img/showcase/medblock.svg @@ -0,0 +1,27 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/static/img/showcase/rubaru_dapp_screenshot.png b/static/img/showcase/rubaru_dapp_screenshot.png new file mode 100644 index 0000000000..e15baa120b Binary files /dev/null and b/static/img/showcase/rubaru_dapp_screenshot.png differ diff --git a/static/img/showcase/rubaru_dapp_screenshots.png b/static/img/showcase/rubaru_dapp_screenshots.png deleted file mode 100644 index 8bf42ca5da..0000000000 Binary files a/static/img/showcase/rubaru_dapp_screenshots.png and /dev/null differ