From 1f02eade3bfe7d82519b59a5dbc99e51dec3f550 Mon Sep 17 00:00:00 2001 From: Jessie Mongeon Date: Wed, 4 Dec 2024 13:23:34 -0800 Subject: [PATCH 1/8] cleanup docs --- .../defi/tokens/asset_flow/index.mdx | 38 +-- .../getting-started/tokens-and-cycles.mdx | 4 +- .../authentication/email-password.mdx | 25 -- .../identity/authentication/msq.mdx | 140 -------- .../identity/authentication/nfid.mdx | 302 ------------------ .../identity/authentication/overview.mdx | 10 +- .../identity/authentication/siwb.mdx | 131 -------- .../identity/authentication/siwe.mdx | 39 --- .../identity/authentication/siws.mdx | 58 ---- .../best-practices/troubleshooting.mdx | 4 +- .../smart-contracts/write/overview.mdx | 6 +- .../application-frontends/overview.mdx | 2 +- docusaurus.config.js | 11 - plugins/utils/redirects.js | 24 +- sidebars.js | 234 ++++---------- 15 files changed, 107 insertions(+), 921 deletions(-) delete mode 100644 docs/developer-docs/identity/authentication/email-password.mdx delete mode 100644 docs/developer-docs/identity/authentication/msq.mdx delete mode 100644 docs/developer-docs/identity/authentication/nfid.mdx delete mode 100644 docs/developer-docs/identity/authentication/siwb.mdx delete mode 100644 docs/developer-docs/identity/authentication/siwe.mdx delete mode 100644 docs/developer-docs/identity/authentication/siws.mdx diff --git a/docs/developer-docs/defi/tokens/asset_flow/index.mdx b/docs/developer-docs/defi/tokens/asset_flow/index.mdx index 0750563296..7ef4536041 100644 --- a/docs/developer-docs/defi/tokens/asset_flow/index.mdx +++ b/docs/developer-docs/defi/tokens/asset_flow/index.mdx @@ -14,17 +14,17 @@ import { GlossaryTooltip } from "/src/components/Tooltip/GlossaryTooltip"; ## Overview -When interacting with the [ICP or ICRC-1 ledgers](/docs/developer-docs/defi/tokens/ledger/overview.mdx), there are different asset flow operations that can be executed. These operations are: +When interacting with the [ICP or ICRC-1 ledgers](/docs/developer-docs//defi/overview.mdx), there are different asset flow operations that can be executed. These operations are: * **Transfer**: A simple transfer between two entities. -* **Approve**: Approving tokens to be spent by another entity. +* **Approve**: Approving tokens to be spent by another entity. * **Mint**: Creating new tokens (**Requires minting account privileges**). -* **Burn**: Destroying tokens. -* **TransferFrom**: Spend approved tokens on behalf of another entity. +* **Burn**: Destroying tokens. +* **TransferFrom**: Spend approved tokens on behalf of another entity. -Both ledger types support these operations. There are several ways on how to create transactions corresponding to each asset flow operation. This guide will demonstrate how to use `dfx` using `Rust` code. +Both ledger types support these operations. There are several ways on how to create transactions corresponding to each asset flow operation. This guide will demonstrate how to use `dfx` using `Rust` code. -### Prerequisites +### Prerequisites * Download and install [`dfx`](/docs/current/developer-docs/developer-tools/cli-tools/cli-reference/dfx-parent). @@ -32,7 +32,7 @@ Both ledger types support these operations. There are several ways on how to cre ## Transfer tokens -To transfer tokens, your transaction will need the following required fields: +To transfer tokens, your transaction will need the following required fields: * `to`: The account that will receive the tokens. * `amount`: The amount of tokens to be sent. @@ -40,9 +40,9 @@ To transfer tokens, your transaction will need the following required fields: Additionally, the transaction takes the following optional fields: * `from_subaccount`: The subaccount of the approver. -* `fee`: The fee paid by the sender for the transfer. If not set, the default fee will have to be paid. +* `fee`: The fee paid by the sender for the transfer. If not set, the default fee will have to be paid. * `memo`: An arbitrary 32 bytes array to ensure transaction hash uniqueness. -* `created_at_time`: A timestamp that is used to trigger the [deduplication mechanism](https://github.com/dfinity/ICRC-1/blob/main/standards/ICRC-1/README.md#transaction_deduplication). +* `created_at_time`: A timestamp that is used to trigger the [deduplication mechanism](https://github.com/dfinity/ICRC-1/blob/main/standards/ICRC-1/README.md#transaction_deduplication). ### dfx Here is an example command for a `Transfer` transaction using `dfx`: @@ -68,11 +68,11 @@ candid::Decode!(&ic_agent.update("icrc1_transfer", &candid::Encode!(&transfer_ar :::info Mint and burn operations are technically speaking also transfers. They work exactly like regular transfers with certain conditions that have to be met. They are the following: * For **mint** operations, the sender of the transfer has to be the minter account. This means that if you want to make mint transactions, you will need to know the private key of the minter account. The recipient will receive the newly minted tokens. -* For **burn** operations, the receiver needs to be set to the mint account while the sender can be any account. You can request the minter account by calling the `icrc1_minting_account` endpoint of the ledger. +* For **burn** operations, the receiver needs to be set to the mint account while the sender can be any account. You can request the minter account by calling the `icrc1_minting_account` endpoint of the ledger. ::: ## Approve tokens -To approve tokens, your transaction will need the following required fields: +To approve tokens, your transaction will need the following required fields: * `spender`: The account that is allowed to spend the tokens. * `amount`: The maximum amount of tokens to be spent by the spender. @@ -80,11 +80,11 @@ To approve tokens, your transaction will need the following required fields: Additionally, the transaction takes the following optional fields: * `from_subaccount`: The subaccount of the approver. -* `expected_allowance`: If set, this field serves as a guarantee that before the new approved amount is set, the expected allowance reflects the previously set approved amount. -* `expires_at`: The timestamp at which the allowance will expire. -* `fee`: The fee paid by the approver for the approval. If not set, the default fee will have to be paid. +* `expected_allowance`: If set, this field serves as a guarantee that before the new approved amount is set, the expected allowance reflects the previously set approved amount. +* `expires_at`: The timestamp at which the allowance will expire. +* `fee`: The fee paid by the approver for the approval. If not set, the default fee will have to be paid. * `memo`: An arbitrary 32 bytes array to ensure transaction hash uniqueness. -* `created_at_time`: A timestamp that is used to trigger the [deduplication mechanism](https://github.com/dfinity/ICRC-1/blob/main/standards/ICRC-1/README.md#transaction_deduplication). +* `created_at_time`: A timestamp that is used to trigger the [deduplication mechanism](https://github.com/dfinity/ICRC-1/blob/main/standards/ICRC-1/README.md#transaction_deduplication). ### dfx Here is an example command for an `Approve` transaction using `dfx`: @@ -111,15 +111,15 @@ candid::Decode!(&ic_agent.update("icrc2_approve", &candid::Encode!(&approve_args ``` ## Transferring approved tokens -To transfer approved tokens, your transaction will need the following required fields: +To transfer approved tokens, your transaction will need the following required fields: * `to`: The account that will receive the tokens. -* `from`: The approvers account who's tokens will be transferred. +* `from`: The approvers account who's tokens will be transferred. * `amount`: The amount of tokens to be sent. Additionally, the transaction takes the following optional fields: * `spender_subaccount`: The subaccount of the spender. -* `fee`: The fee paid by the sender for the transfer. If not set the default fee will have to be paid. +* `fee`: The fee paid by the sender for the transfer. If not set the default fee will have to be paid. * `memo`: An arbitrary 32 bytes array to ensure transaction hash uniqueness. -* `created_at_time`: A timestamp that is used to trigger the [deduplication mechanism](https://github.com/dfinity/ICRC-1/blob/main/standards/ICRC-1/README.md#transaction_deduplication). +* `created_at_time`: A timestamp that is used to trigger the [deduplication mechanism](https://github.com/dfinity/ICRC-1/blob/main/standards/ICRC-1/README.md#transaction_deduplication). ### dfx Here is an example command for a `TransferFrom` transaction using `dfx`: diff --git a/docs/developer-docs/getting-started/tokens-and-cycles.mdx b/docs/developer-docs/getting-started/tokens-and-cycles.mdx index 14f2fef3d2..e773172e10 100644 --- a/docs/developer-docs/getting-started/tokens-and-cycles.mdx +++ b/docs/developer-docs/getting-started/tokens-and-cycles.mdx @@ -50,9 +50,9 @@ The Internet Computer supports creating and deploying custom fungible or non-fun ## What is a ledger? -A [**ledger**](/docs/current/developer-docs/defi/tokens/ledger/overview) is a system canister used to store accounts and their transactions. Each token on the Internet Computer has its **own** ledger. This means that there are separate ledgers for ICP tokens, cycles, and every ICRC token that has been deployed on the network. +A [**ledger**](/docs/current/developer-docs//defi/overview) is a system canister used to store accounts and their transactions. Each token on the Internet Computer has its **own** ledger. This means that there are separate ledgers for ICP tokens, cycles, and every ICRC token that has been deployed on the network. -[Learn more about ledgers](/docs/current/developer-docs/defi/tokens/ledger/overview). +[Learn more about ledgers](/docs/current/developer-docs//defi/overview). ## Obtaining cycles diff --git a/docs/developer-docs/identity/authentication/email-password.mdx b/docs/developer-docs/identity/authentication/email-password.mdx deleted file mode 100644 index 0f8dd90b6f..0000000000 --- a/docs/developer-docs/identity/authentication/email-password.mdx +++ /dev/null @@ -1,25 +0,0 @@ ---- -keywords: [intermediate, tutorial, user sign in, user login, email password, nfid] ---- - -import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow"; - -# Email & password - - - -## Overview - -For some dapps, authenticating with a traditional email and password method may be desired. To support this workflow, [NFID](https://nfid.one/) can be used. NFID is a form of digital identity with a backend built entirely on ICP. It supports authentication with dapps through an email and password login or an existing Google account. - -[Learn how to use NFID](nfid.mdx). - -## Resources - -- [How NFID works](https://docs.nfid.one/embed/how-it-works/overview). - -- [NFID documentation](https://docs.nfid.one/embed/integration/quickstart). - -- [NFID playground](https://playground.nfid.one/). - -- [NFID Medium blog post](https://medium.com/dfinity/nfid-the-digital-identity-protocol-7d8a39f7ac85). \ No newline at end of file diff --git a/docs/developer-docs/identity/authentication/msq.mdx b/docs/developer-docs/identity/authentication/msq.mdx deleted file mode 100644 index 6e9cd8b6ef..0000000000 --- a/docs/developer-docs/identity/authentication/msq.mdx +++ /dev/null @@ -1,140 +0,0 @@ ---- -keywords: [authentication, msq, integration] ---- - -import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow"; - -# MSQ - - - -## Overview - -[MSQ](https://icp.msq.tech/) is a [MetaMask Snap](https://metamask.io/snaps/) designed to allow users to use Metamask to authenticate with dapps deployed on ICP. MSQ uses a scoped-identity architecture, meaning each user gets a unique and dedicated identity for each domain they interact with. Scoped-identity architectures help protect users from signature-stealing attacks. - -I'll let you decide what is the best way to explain this! - -Response from MSQ team: https://forum.dfinity.org/t/msq-hits-the-metamask-snap-store/30499/23 - -It provides two primary features: - -- User authorization: Web services can sign arbitrary data with a user's scoped key pair. - -- ICRC-1 payments: Users can request to perform ICRC-1 transfers to pay for goods or services. - -## Installation - -Insall the `msq` package with the command: - -``` -npm install @fort-major/msq-client -``` - -Then, import it into your project's `package.json` file: - -```json title="package.json" -"dependencies": { - ... - "@fort-major/msq-client": "^0.3", - ... -} -``` - -Users will need to connect to MetaMask and the MSQ Snap. - -The MSQ client library does this using the following function. For example, a user who interacts with a frontend element (e.g., button) that triggers the function will be prompted to connect using Metamask and install the MSQ Snap. - -```typescript title="src/frontend/index.tsx" -const result = await MsqClient.create(); - -if (!("Ok" in result)) { - // handle possible errors -} -``` - -Then, retrieve the client with the following code: - -```typescript title="src/frontend/index.tsx" -import { TMsqCreateOk, MsqClient } from "@fort-major/msq-client"; - -const msq: MsqClient = (result as TMsqCreateOk).Ok; -``` - -The MSQ client library version correlates with the respective Snap version. For example, the client library version `0.2.4` works with Snap version `0.2.x` or `0.3.x`, but does not work with `1.x.x`. - -## User authorization - -To enable users to authorize with MSQ and interact with your dapp, you can call the `requestLogin()` function of the client: - -```typescript title="src/frontend/index.tsx" -import { Identity } from "@dfinity/identity"; - -const identity: Identity | null = await msq.requestLogin(); - -if (identity === null) { - // the user has rejected to log in -} -``` - -This function returns an identity object which can then be supplied to an agent's `HttpAgent` constructor which can then be used to call canisters on a user's behalf: - -```typescript title="src/frontend/index.tsx" -import { HttpAgent } from "@dfinity/agent"; - -const agent = new HttpAgent({ identity }); -``` - -Authorization for a user lasts indefinitely unless explicitly ended. The following code can be used to check if a user's session exists: - -```typescript title="src/frontend/index.tsx" -if (msq.isAuthorized()) { -} -``` - -To stop the user's session, use the `requestLogout()` function: - -```typescript title="src/frontend/index.tsx" -if (await msq.requestLogout()) { -} else { -} -``` - -You can learn more about user authentication in the [MSQ documentation](https://github.com/fort-major/msq/blob/master/documentation/integration.md). - -## ICRC-1 payments - -MSQ enables users to make payments using a pre-defined ICRC-1 account through the `requestICRC1Payment()` function: - -```typescript -const blockId: bigint | null = await msq.requestICRC1Payment({ - if (blockId === null) { - renderErrorScreen("Payment failed"); - }, - // A canister ID of the valid `ICRC-1` token: - tokenCanisterId, - to: { - // Payment recipient's `principal` ID - owner, - // Payment recipient's `subaccount` ID - subaccount, - }, - // An amount of tokens that the user needs to transfer to the recipient - amount, - // An optional ICRC-1 memo - memo, -}); -``` - -This function returns either a `bigint` or `null`. A `bigint` response will indicate the block number of the executed ICRC-1 transaction and means that the payment was successful. That block number can then be used to query the token canister, verify the payment, and execute some business logic. - -MSQ supports ICRC-1 token payments by default through a series of whitelisted ICRC-1 tokens. If you accept payment of a whitelisted token, your workflow will execute as expected. However, if you accept a token that isn't currently whitelisted, the user will be prompted to add the token to their personal whitelist. - -[View the MSQ documentation for the full list of whitelisted ICRC-1 tokens](https://github.com/fort-major/msq/blob/master/documentation/integration.md#icrc-1-payments). - -## Resources - -- [MSQ GitHub repo](https://github.com/fort-major/msq/blob/master/) - -- [MSQ documentation](https://github.com/fort-major/msq/blob/master/documentation/integration.md) - -- [MSQ MetaMask Snap](https://snaps.metamask.io/snap/npm/fort-major/msq/) diff --git a/docs/developer-docs/identity/authentication/nfid.mdx b/docs/developer-docs/identity/authentication/nfid.mdx deleted file mode 100644 index e086bb819a..0000000000 --- a/docs/developer-docs/identity/authentication/nfid.mdx +++ /dev/null @@ -1,302 +0,0 @@ ---- -keywords: [intermediate, tutorial, user sign in, user login, nfid] ---- - -import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow"; -import '/src/components/CenterImages/center.scss'; - - -# NFID - - - -## Overview - -[NFID](https://nfid.one/) is a form of digital identity built on ICP. Similar to Internet Identity, NFID allows users to sign into services without downloading an app or extension and can be used across several different dapps. - -NFID is different from Internet Identity, however, in the fact that is allows you to sign in to a dapp using your email or Google account. With Internet Identity, these log in options aren't available. This makes NFID a great option for those that want to use email or Google authentication methods. - -NFID also supports signing in with a passkey stored on a mobile device or local keychain, which is the same method used by Internet Identity. - -## Using NFID - -### Prerequisites - -Before starting the guide, verify the following: - -- [x] You have `Node.js` `16.0.0` or newer installed for frontend development and can install packages using `npm install` in your project. For information about installing node for your local operating system and package manager, see the [Node](https://nodejs.org/en/) website. - -- [x] You have downloaded and installed the IC SDK package as described in the [download and install](/docs/current/developer-docs/getting-started/install) page. - -Check out the [GitHub repo for this project](https://github.com/internet-identity-labs/motoko-bootcamp/tree/main) to clone and deploy the project quickly. - -### Create a new project - -First, create a new project with the `dfx new` command: - -``` -dfx new NFID_project -``` - -If using `dfx` v0.17.0 and newer, select 'Motoko' and 'Vanilla JS' when prompted. - -### Edit the backend canister - -Replace the default Motoko backend canister code (`src/NFID_backend/main.mo`) with the following: - -```motoko title="src/NFID_backend/main.mo" -import Principal "mo:base/Principal"; - -actor { - public shared query({caller}) func greet(name : Text) : async Text { - return "Hello, " # name # "! " # "Your PrincipalId is: " # Principal.toText(caller); - }; -}; -``` - -### Update the project's `dfx.json` file. - -Replace the `dfx.json` file's content with the following configuration: - -```json title="dfx.json" -{ - "canisters": { - "NFID_backend": { - "main": "src/NFID_backend/main.mo", - "type": "motoko" - }, - "NFID_frontend": { - "dependencies": [ - "NFID_backend" - ], - "frontend": { - "entrypoint": "src/NFID_frontend/src/index.html" - }, - "source": [ - "src/NFID_frontend/assets" - ], - "type": "assets" - } - }, - "defaults": { - "build": { - "args": "", - "packtool": "" - } - }, - "version": 1 -} -``` - -### Install the `auth-client` package. - -Install the DFINITY `auth-client` package with the command: - -``` -npm install --save @dfinity/auth-client -``` - -### Create a file called `index.html` in the subdirectory `src/NFID_frontend/src/`. - -Insert the following code into the `index.html` file: - -```html title="src/NFID_frontend/src/index.html" - - - - - - NFID example - - - - - -
- DFINITY logo -
-
-
- -
-
-
- - - -
-
-
- - -``` - -### Create an `index.js` file in the `src/NFID_frontend/src` subdirectory. - -Insert the following code into this new `index.js` file: - -```javascript title="src/NFID_frontend/src/index.js" -import { Actor } from "@dfinity/agent"; -import { AuthClient } from "@dfinity/auth-client"; -import { NFID_backend } from "../../declarations/NFID_backend"; - -let authClient = null; - -async function init() { - authClient = await AuthClient.create(); -} - -document.querySelector("form").addEventListener("submit", async (e) => { - e.preventDefault(); - const button = e.target.querySelector("button"); - - const name = document.getElementById("name").value.toString(); - - button.setAttribute("disabled", true); - - // Interact with foo actor, calling the greet method - const greeting = await NFID_backend.greet(name); - - button.removeAttribute("disabled"); - - document.getElementById("greeting").innerText = greeting; - - return false; -}); - -function handleSuccess() { - const principalId = authClient.getIdentity().getPrincipal().toText(); - - document.getElementById( - "principalId" - ).innerText = `Your PrincipalId: ${principalId}`; -} - -document.getElementById("login").addEventListener("click", async (e) => { - if (!authClient) throw new Error("AuthClient not initialized"); - - authClient.login({ - onSuccess: handleSuccess, - }); -}); - -init(); -``` - -### Deploy your project - -Deploy the project with the command: - -```bash -dfx deploy -``` - -You will receive the URL for the frontend and backend canisters running locally: - -```bash -Deployed canisters. -URLs: - Frontend canister via browser - NFID_frontend: http://127.0.0.1:4943/?canisterId=br5f7-7uaaa-aaaaa-qaaca-cai - Backend canister via Candid interface: - NFID_backend: http://127.0.0.1:4943/?canisterId=bw4dl-smaaa-aaaaa-qaacq-cai&id=be2us-64aaa-aaaaa-qaabq-cai -``` - -Open the `NFID_frontend` URL in your web browser. You'll see the following UI: - -![UI](../_attachments/default-ui.png) - -### Configure NFID - -Currently, the `Log me in` button doesn't have any functionality when clicked. Let's configure it to use NFID. - -Replace the existing `index.js` code with the following: - -```javascript title="src/NFID_frontend/src/index.js" -import { Actor } from "@dfinity/agent"; -import { AuthClient } from "@dfinity/auth-client"; -import { NFID_backend } from "../../declarations/NFID_backend"; - -let authClient = null; - -async function init() { - authClient = await AuthClient.create(); -} - -document.querySelector("form").addEventListener("submit", async (e) => { - e.preventDefault(); - const button = e.target.querySelector("button"); - - const name = document.getElementById("name").value.toString(); - - button.setAttribute("disabled", true); - - // Interact with foo actor, calling the greet method - const greeting = await NFID_backend.greet(name); - - button.removeAttribute("disabled"); - - document.getElementById("greeting").innerText = greeting; - - return false; -}); - -function handleSuccess() { - const principalId = authClient.getIdentity().getPrincipal().toText(); - - document.getElementById( - "principalId" - ).innerText = `Your PrincipalId: ${principalId}`; - - Actor.agentOf(NFID_backend).replaceIdentity( - authClient.getIdentity() - ); -} - -document.getElementById("login").addEventListener("click", async (e) => { - if (!authClient) throw new Error("AuthClient not initialized"); - - const APP_NAME = "NFID example"; - const APP_LOGO = "https://nfid.one/icons/favicon-96x96.png"; - const CONFIG_QUERY = `?applicationName=${APP_NAME}&applicationLogo=${APP_LOGO}`; - - const identityProvider = `https://nfid.one/authenticate${CONFIG_QUERY}`; - - authClient.login({ - identityProvider, - onSuccess: handleSuccess, - windowOpenerFeatures: ` - left=${window.screen.width / 2 - 525 / 2}, - top=${window.screen.height / 2 - 705 / 2}, - toolbar=0,location=0,menubar=0,width=525,height=705 - `, - }); -}); - -init(); -``` - - -### Redeploy the canisters - -To implement the changes, redeploy the canisters with `dfx deploy`. - -Now, when you click 'Log me in', you'll get an NFID login prompt: - -![NFID login](../_attachments/nfid-ui.png) - -## Resources - -- [GitHub repo for this project](https://github.com/internet-identity-labs/motoko-bootcamp/tree/main). - -- [Video tutorial for this project](https://www.youtube.com/watch?v=jqNQQf6V6zg). - -- [How NFID works](https://docs.nfid.one/embed/how-it-works/overview). - -- [NFID documentation](https://docs.nfid.one/embed/integration/quickstart). - -- [NFID playground](https://playground.nfid.one/). - -- [NFID Medium blog post](https://medium.com/dfinity/nfid-the-digital-identity-protocol-7d8a39f7ac85). - - diff --git a/docs/developer-docs/identity/authentication/overview.mdx b/docs/developer-docs/identity/authentication/overview.mdx index 69a38f69fb..196dead20f 100644 --- a/docs/developer-docs/identity/authentication/overview.mdx +++ b/docs/developer-docs/identity/authentication/overview.mdx @@ -22,7 +22,7 @@ Authentication methods available on ICP include: - [Email and password](email-password.mdx): Authentication with an email and password. -- [NFID](nfid.mdx): A digital form of identity that allows users to use an email and password or their Google account. +- [NFID](https://nfid.one/): A digital form of identity that allows users to use an email and password or their Google account. - [`ic-auth`](https://github.com/id-daniel-mccoy/ic-auth): A modular tool to integrate wallet providers into ICP apps. Supports Stoic, Plug, Internet Identity, and NFID. @@ -30,12 +30,12 @@ Authentication methods available on ICP include: The following tools enable authenticating with ICP dapps using wallet addresses from other chains and ecosystems: -- [Sign in with Bitcoin](siwb.mdx): An authentication standard that enables Bitcoin wallet-based authentication for ICP applications. +- [Sign in with Bitcoin](https://github.com/AstroxNetwork/ic-siwb): An authentication standard that enables Bitcoin wallet-based authentication for ICP applications. -- [Sign in with Ethereum](siwe.mdx): An authentication standard that enables Ethereum wallet-based authentication for ICP applications. +- [Sign in with Ethereum](https://github.com/kristoferlund/ic-siwe-react-demo-rust): An authentication standard that enables Ethereum wallet-based authentication for ICP applications. -- [Sign in with Solana](siws.mdx): An authentication standard that enables Solana wallet-based authentication for ICP applications. +- [Sign in with Solana](https://github.com/kristoferlund/ic-siws): An authentication standard that enables Solana wallet-based authentication for ICP applications. -- [MSQ library](msq.mdx): A client library for dapps to enable user interaction with ICP solely via their existing MetaMask wallet using the [Metamask Snaps](https://metamask.io/snaps/) feature. +- [MSQ library](https://icp.msq.tech/): A client library for dapps to enable user interaction with ICP solely via their existing MetaMask wallet using the [Metamask Snaps](https://metamask.io/snaps/) feature. diff --git a/docs/developer-docs/identity/authentication/siwb.mdx b/docs/developer-docs/identity/authentication/siwb.mdx deleted file mode 100644 index db240c12a0..0000000000 --- a/docs/developer-docs/identity/authentication/siwb.mdx +++ /dev/null @@ -1,131 +0,0 @@ ---- -keywords: [advanced, bitcoin, sign in, bitcoin sign in] ---- - -import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow"; - -# Sign in with Bitcoin - - - -## Overview - -Sign in with Bitcoin (SIWB) is a fork of the [sign in with Ethereum](siwe.mdx) package that enables dapps to provide users with the option to authenticate with their Bitcoin wallet address. - -SIWB supports the popular BTC wallets [Wizz](https://wizzwallet.io/) and [Unisat](https://unisat.io/). - -### Key features - -- Consistent principal generation: Ensures that logging in with a BTC wallet will produce the same principal consistently. - -- Session identity uniqueness: Each session identity is specific to the application's context, avoiding cross-app identity exploits. - -- Direct BTC-to-principal mapping: Each BTC address has a 1:1 correlation with a principal. - -- Timebound sessions: Developers can set session expiration times for control and security enhancement. - -- Prebuilt identity provider: A prebuilt canister to integrate into any existing ICP dapp. - -## Usage - -The SIWB package can be downloaded from its [GitHub repo](https://github.com/AstroxNetwork/ic-siwb.git) which includes an example integration. - -To use the example integration, clone the repo, then deploy the included pre-built canisters: - -``` -git clone https://github.com/AstroxNetwork/ic-siwb.git -cd ic-siwb -dfx start --clean --background -npm install -dfx deploy -``` - -This example deploys the prebuild `ic_siwb_provider` canister alongside an example `ic_siwb_test_canister`. - -:::caution - -If you are deploying on a Mac OS X machine and receive an error such as: - -``` -secp256k1-sys@0.8.1: error: unable to create target: 'No available targets are compatible with triple "wasm32-unknown-unknown"' -error: failed to run custom build command for `secp256k1-sys v0.8.1` -``` - -This is due to the default Mac OS X clang compiler not supporting compiling to target wasm32-unknown-unknown. - -You can remedy this error by installing another compiler using `brew` that does support wasm32-unknown-unknown: - -``` -brew install llvm -export PATH="/opt/homebrew/opt/llvm/bin:$PATH" &&  export LDFLAGS="-L/opt/homebrew/opt/llvm/lib" && export CPPFLAGS="-I/opt/homebrew/opt/llvm/include" -cargo build --target wasm32-unknown-unknown --release -``` -::: - - -As part of the canisters' deployment, both will require initialization arguments. The first is the `ic_siwb_provider` canister. Before initialization, this canister's ID will be printed on the terminal in a line such as: - -``` -Installing canisters... -Installing code for canister ic_siwb_provider, with canister ID bkyz2-fmaaa-aaaaa-qaaaq-cai -This canister requires an initialization argument. -``` - -Copy the canister's ID. Then, configure the initialization arguments as prompted: - -- URI: The full URL, such as `http://localhost:3000`. -- Salt: A string used to generate seed that uniquely identifies each user principal. -- Domain: The domain name, such as `localhost`. -- Optional runtime feature enabled: Select yes to enable and no to disable. -- Optional statement: A message presented to the user by the Bitcoin wallet. -- Optional scheme: The scheme used to serve the frontend that uses SIWB. Defaults to "https". -- Optional network: Defaults to the Bitcoin mainnet.  -- Optional session expiration time: Time to live for a session in nanoseconds. -- Optional target: All canisters for which the identity delegation is allowed. Defaults to None. -- Optional sign in expiration time: Time to live for a sign in message in nanoseconds. - -An example of the canister's initialization configuration can be found below: - -``` -( -  record { -    uri = "http://localhost:3000"; -    runtime_features = null; -    domain = "localhost"; -    statement = null; -    scheme = null; -    salt = "test"; -    network = null; -    session_expires_in = null; -    targets = null; -    sign_in_expires_in = null; -  }, -) -``` - -Next, you will need to pass the canister ID for `ic_siwb_provider` to the `ic_siwb_test_canister` as its initialization argument when prompted: - -``` -Installing code for canister ic_siwb_test_canister, with canister ID bd3sg-teaaa-aaaaa-qaaba-cai -This canister requires an initialization argument. -✔ Enter a text (type :e to use editor) · bkyz2-fmaaa-aaaaa-qaaaq-cai -Sending the following argument: -("bkyz2-fmaaa-aaaaa-qaaaq-cai") -``` - -Once both canisters have been installed, initialized, and deployed, you will receive the local URLs for both canisters: - -``` -URLs: -  Backend canister via Candid interface: -    ic_siwb_provider: http://127.0.0.1:4943/?canisterId=be2us-64aaa-aaaaa-qaabq-cai&id=bkyz2-fmaaa-aaaaa-qaaaq-cai -    ic_siwb_test_canister: http://127.0.0.1:4943/?canisterId=be2us-64aaa-aaaaa-qaabq-cai&id=bd3sg-teaaa-aaaaa-qaaba-cai -``` - -You can view the full frontend example in the [project's repo](https://github.com/AstroxNetwork/ic-siwb/tree/main/examples/frontend). - -## Resources - -- [View this project on GitHub](https://github.com/AstroxNetwork/ic-siwb/tree/main) - -- [Join the forum conversation for this project](https://forum.dfinity.org/t/sign-in-with-bitcoin-on-icp/32734) diff --git a/docs/developer-docs/identity/authentication/siwe.mdx b/docs/developer-docs/identity/authentication/siwe.mdx deleted file mode 100644 index 2241ad0234..0000000000 --- a/docs/developer-docs/identity/authentication/siwe.mdx +++ /dev/null @@ -1,39 +0,0 @@ ---- -keywords: [advanced, ethereum, sign in, ethereum sign in] ---- - -import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow"; - -# Sign in with Ethereum - - - -## Overview - -The [SIWE](https://eips.ethereum.org/EIPS/eip-4361) standard defines a protocol for off-chain authentication of Ethereum accounts. This protocol is designed to enable Ethereum wallet-based authentication for applications on other platforms, such as the Internet Computer (ICP). - -By integrating the third party library [ic_siwe](https://github.com/kristoferlund/ic-siwe/tree/main/packages/ic_siwe) or adding the pre-built [ic_siwe_provider](https://github.com/kristoferlund/ic-siwe/tree/main/packages/ic_siwe_provider) canister to your project, you can enable users to sign into your application using their Ethereum wallets. - -The goal of the `ic_siwe` project is to enhance the interoperability between Ethereum and ICP, enabling developers to build applications that leverage the strengths of both platforms. - -### Key features - -- **Ethereum Wallet Sign-In**: Enables Ethereum wallet sign-in for ICP applications. Sign in with any Ethereum wallet to generate an ICP identity and session. -- **Session identity uniqueness**: Ensures that session identities are specific to each application's context, preventing cross-app identity misuse. -- **Consistent principal generation**: Guarantees that logging in with an Ethereum wallet consistently produces the same principal, irrespective of the client used. -- **Direct Ethereum address to principal mapping**: Creates a 1:1 correlation between Ethereum addresses and principals within the scope of the current application. -- **Timebound sessions**: Allows developers to set expiration times for sessions, enhancing security and control. - -## Usage - -While the `ic_siwe` library can be integrated with any Rust-based ICP project, using the pre-built [ic-siwe-provider](https://github.com/kristoferlund/ic-siwe/tree/main/packages/ic_siwe_provider) canister is the easiest way to integrate Ethereum wallet authentication into an ICP app built using any language. - -The canister is designed as a plug-and-play solution for developers, enabling easy integration into existing ICP applications with minimal coding requirements. By adding the pre built `ic_siwe_provider` canister to the `dfx.json` of an ICP project, developers can quickly enable Ethereum wallet-based authentication for their applications. The canister simplifies the authentication flow by managing the creation and verification of SIWE messages and handling user session management. - -## React demo application - -A demo application that uses the `ic_siwe_provider` canister to demonstrate the full login flow is available in two versions: -- [ic-siwe-react-demo-rust](https://github.com/kristoferlund/ic-siwe-react-demo-rust) -- [ic-siwe-react-demo-ts](https://github.com/kristoferlund/ic-siwe-react-demo-ts) - -The demo uses another package from the `ic-siwe` project, [ic-use-siwe-identity](https://github.com/kristoferlund/ic-siwe/tree/main/packages/ic-use-siwe-identity), a React hook and context provider for easy frontend integration with SIWE enabled ICP canisters. \ No newline at end of file diff --git a/docs/developer-docs/identity/authentication/siws.mdx b/docs/developer-docs/identity/authentication/siws.mdx deleted file mode 100644 index ca1fe8472e..0000000000 --- a/docs/developer-docs/identity/authentication/siws.mdx +++ /dev/null @@ -1,58 +0,0 @@ ---- -keywords: [advanced, solana sign in, solana sign in] ---- - -import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow"; - -# Sign in with Solana - - - -## Overview - -The `ic-siws` (SIWS) project provides ICP dapps with a way to enable Solana-based authentication. The project's goal is to enhance the interoperability between ICP and Solana by enabling developers to build dapps that can use both chains. - -The [`ic-siwe` (SIWE)](siwe.mdx) project is also available for enabling Ethereum-based authentication. - -You can try the deployed demo here: https://guidq-3qaaa-aaaal-qiteq-cai.icp0.io - -### Key features - -- **Solana Wallet Sign-In**: Enables any Solana wallet to generate an ICP identity and sign into ICP dapps. - -- **Prebuilt identity solution**: Provides a prebuilt canister that can be integrated into any ICP project, independent of the project's programming language. - -- **Direct Solana wallet address to `Principal` mapping**: Uses a 1:1 correlation between Solana addresses and `Principals`. - -- **Consistent principal generation**: Ensures each Solana wallet produces the same `Principal`. - -- **Session identity uniqueness**: Verifies that each session identity is specific to each application's context. - -- **Timebound sessions**: Developers can set expiration times for sessions to enhance control and security. - - -## Usage - -To use SIWS, developers have two possible workflows: - -1. Use the prebuilt [ic_siws_provider](https://github.com/kristoferlund/ic-siws/tree/main/packages/ic_siws_provider)**: The pre-built identity provider canister can be integrated with any ICP project by adding the canister's information to the project's `dfx.json` file. When using the pre-built canister solution, the following login workflow is used: - -- An ICP dapp requests a SIWS message on behalf of a user from the `ic_siws_provider` canister. - -- The dapp displays the SIWS message to the user who must sign it with their Solana wallet. - -- The dapp sends the signed SIWS message to the `ic_siws_provider` canister. The canister verifies the signature and creates an ICP Principal for the user. - -- The dapp retrieves the Principal from the `ic_siws_provider` canister and can now use the new Principal to make authenticated calls for the user. - -2. **Use the [ic_siws](https://crates.io/crates/ic_siws) Rust library directly**: Provides developers with full control over the SIWS integration through the `ic_swis` library. - -## Resources - -- [ic_siws Rust library](https://github.com/kristoferlund/ic-siws/tree/main/packages/ic_siws) - -- [`ic-siws-provider` prebuilt canister](https://github.com/kristoferlund/ic-siws/tree/main/packages/ic_siws_provider) - -- [ic-siws-react-demo-rust](https://github.com/kristoferlund/ic-siws-react-demo-rust): A demo dapp written in Rust that demonstrates how to integrate SIWS. - -- [ic-use-siws-identity](https://github.com/kristoferlund/ic-siws/tree/main/packages/ic-use-siws-identity): A React hook and context provider for enabling frontend integration with SIWS-enabled canisters. diff --git a/docs/developer-docs/smart-contracts/best-practices/troubleshooting.mdx b/docs/developer-docs/smart-contracts/best-practices/troubleshooting.mdx index f49b2967bc..ed3b084503 100644 --- a/docs/developer-docs/smart-contracts/best-practices/troubleshooting.mdx +++ b/docs/developer-docs/smart-contracts/best-practices/troubleshooting.mdx @@ -28,9 +28,9 @@ If your canister is running on a subnet that has a consistently high load and th ### Recommendation: Use query calls instead of update calls when possible. -[Query calls](/docs/current/developer-docs/web-apps/design-dapps#using-query-calls) are executed on a single node within a subnet and do not go through consensus, therefore they can be returned much faster than an update call. For some applications, query calls can be used in place of update calls to reduce latency. +[Query calls](/docs/current/developer-docs/smart-contracts/call/overview/#query-calls) are executed on a single node within a subnet and do not go through consensus, therefore they can be returned much faster than an update call. For some applications, query calls can be used in place of update calls to reduce latency. -However, the security trade-offs of query calls must be considered. Since query calls do not go through consensus, it is not recommended that they are used for retrieving sensitive information that requires data assurance. For example, returning financial data on a decentralized exchange dapp should not use basic query calls, as it is important the call return data that has been validated through the subnet's consensus. As an alternative, [certified queries](/docs/current/developer-docs/web-apps/design-dapps#using-query-calls) may be used. +However, the security trade-offs of query calls must be considered. Since query calls do not go through consensus, it is not recommended that they are used for retrieving sensitive information that requires data assurance. For example, returning financial data on a decentralized exchange dapp should not use basic query calls, as it is important the call return data that has been validated through the subnet's consensus. As an alternative, [certified queries](/docs/current/developer-docs/smart-contracts/call/overview/#query-calls) may be used. ### Recommendation: Use efficient query calls. diff --git a/docs/developer-docs/smart-contracts/write/overview.mdx b/docs/developer-docs/smart-contracts/write/overview.mdx index fdc353021e..fb24557f70 100644 --- a/docs/developer-docs/smart-contracts/write/overview.mdx +++ b/docs/developer-docs/smart-contracts/write/overview.mdx @@ -58,7 +58,7 @@ The typical development workflow of the frontend is: 3. The developer deploys the project. `dfx` will compile the frontend asset files into an asset canister. 4. Users open the application in the browser by navigating to the URL `https://.icp0.io` or a [custom domain](/docs/current/developer-docs/web-apps/custom-domains/using-custom-domains) if one has been registered for the canister. 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. +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/developer-tools/off-chain/agents/javascript-agent) library, which is analogous to `web3.js` and `ethers.js` of Ethereum. #### Limitations Server-side rendering (SSR) does not work in canisters because they require JS code that is not built into canisters. @@ -107,7 +107,7 @@ Navigate into your project directory: cd hello ``` -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. +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. @@ -226,7 +226,7 @@ In this directory, the following files and directories are notable: ### Reviewing the default program code -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. +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. diff --git a/docs/developer-docs/web-apps/application-frontends/overview.mdx b/docs/developer-docs/web-apps/application-frontends/overview.mdx index e2283a9d12..3c88956dad 100644 --- a/docs/developer-docs/web-apps/application-frontends/overview.mdx +++ b/docs/developer-docs/web-apps/application-frontends/overview.mdx @@ -21,7 +21,7 @@ Application frontends exist in the following forms: - A frontend canister that communicates with backend canister(s) to provide a full-stack dapp. -- Backend canisters that communicate with an external frontend application that isn't hosted on ICP. To facilitate this communication, [the ICP JavaScript agent](/docs/current/developer-docs/developer-tools/off-chain/agents/javascript-agent) can be used. [Learn more about the JS request API](/docs/current/developer-docs/web-apps/browser-js/js-request-api). +- Backend canisters that communicate with an external frontend application that isn't hosted on ICP. To facilitate this communication, [the ICP JavaScript agent](/docs/current/developer-docs/developer-tools/off-chain/agents/javascript-agent) can be used. [Learn more about the JS request API](/docs/current/developer-docs/developer-tools/off-chain/agents/javascript-agent). - A frontend canister that doesn't communicate with any backend canisters and only provides web assets. diff --git a/docusaurus.config.js b/docusaurus.config.js index 3dc633f7ff..3e6a55e8d6 100644 --- a/docusaurus.config.js +++ b/docusaurus.config.js @@ -86,17 +86,6 @@ const subnavItems = [ }, ], }, - { - type: "dropdown", - position: "left", - label: "Frameworks", - items: [ - { - label: "Juno", - href: "/docs/current/developer-docs/web-apps/frameworks/juno", - }, - ], - }, { type: "dropdown", position: "left", diff --git a/plugins/utils/redirects.js b/plugins/utils/redirects.js index c9b8f85822..26cd7dd720 100644 --- a/plugins/utils/redirects.js +++ b/plugins/utils/redirects.js @@ -83,7 +83,7 @@ const redirects = ` /docs/current/developer-docs/build/languages/rust/* /docs/current/developer-docs/backend/rust/ /docs/current/developer-docs/build/project-setup/cycles-wallet /docs/current/developer-docs/defi/cycles/cycles-wallet /docs/current/developer-docs/build/project-setup/manage-canisters /docs/current/developer-docs/smart-contracts/maintain/settings - /docs/current/developer-docs/build/project-setup/design-dapps /docs/current/developer-docs/web-apps/design-dapps + /docs/current/developer-docs/build/project-setup/design-dapps /docs/current/developer-docs/smart-contracts/overview/introduction /docs/current/developer-docs/build/troubleshooting /docs/current/developer-docs/getting-started/troubleshooting /docs/current/developer-docs/build/agents/ /docs/current/developer-docs/developer-tools/off-chain/agents/overview /docs/current/developer-docs/build/agents/javascript/javascript-intro /docs/current/developer-docs/developer-tools/off-chain/agents/javascript-agent @@ -100,7 +100,7 @@ const redirects = ` /docs/developers-guide/concepts/concepts-intro /docs/current/developer-docs/getting-started/network-overview /docs/developers-guide/customize-projects /docs/current/developer-docs/smart-contracts/compile /docs/developers-guide/default-wallet /docs/current/developer-docs/defi/cycles/cycles-wallet - /docs/developers-guide/design-apps /docs/current/developer-docs/web-apps/design-dapps + /docs/developers-guide/design-apps /docs/current/developer-docs/smart-contracts/overview/introduction /docs/developers-guide/glossary /docs/current/references/glossary /docs/developers-guide/install-upgrade-remove /docs/current/developer-docs/getting-started/install /docs/developers-guide/lang-service-ide /docs/current/developer-docs/developer-tools/ide/vs-code @@ -345,7 +345,7 @@ const redirects = ` /docs/current/developer-docs/frontend/existing-frontend /docs/current/developer-docs/web-apps/application-frontends/existing-frontend /docs/current/developer-docs/production/custom-domain/ /docs/current/developer-docs/web-apps/custom-domains/using-custom-domains /docs/current/developer-docs/production/custom-domain/dns-setup /docs/current/developer-docs/web-apps/custom-domains/dns-setup - /docs/current/developer-docs/backend/design-dapps /docs/current/developer-docs/web-apps/design-dapps + /docs/current/developer-docs/backend/design-dapps /docs/current/developer-docs/smart-contracts/overview/introduction /docs/current/developer-docs/integrations/independently-verifying-ic-signatures /docs/current/developer-docs/web-apps/independently-verifying-ic-signatures /docs/current/developer-docs/integrations/internet-identity/overview /docs/current/developer-docs/identity/internet-identity/overview /docs/current/developer-docs/integrations/internet-identity/creating-ii /docs/current/developer-docs/identity/internet-identity/creating-ii @@ -522,7 +522,7 @@ const redirects = ` /docs/current/developer-docs/web-apps/user-login/internet-identity/creating-ii /docs/current/developer-docs/identity/internet-identity/creating-ii /docs/current/developer-docs/web-apps/user-login/internet-identity/integrate-internet-identity /docs/current/developer-docs/identity/internet-identity/integrate-internet-identity /docs/current/developer-docs/web-apps/user-login/internet-identity/alternative-origins /docs/current/developer-docs/identity/internet-identity/alternative-origins - /docs/current/developer-docs/web-apps/user-login/nfid /docs/current/developer-docs/identity/authentication/nfid + /docs/current/developer-docs/web-apps/user-login/nfid /docs/current/developer-docs/identity/authentication/overview /docs/current/developer-docs/web-apps/user-login/email-password /docs/current/developer-docs/identity/authentication/email-password /docs/current/developer-docs/multi-chain/ethereum/using-eth/siwe /docs/current/developer-docs/identity/authentication/siwe /docs/current/developer-docs/build/cdks/motoko-dfinity/motoko/ /docs/current/motoko/main/getting-started/motoko-introduction @@ -644,6 +644,22 @@ const redirects = ` /docs/current/developer-docs/smart-contracts/advanced-features/serving-http-request /docs/current/developer-docs/smart-contracts/advanced-features/handling-get-post-requests /docs/current/developer-docs/smart-contracts/write/default-template /docs/current/developer-docs/smart-contracts/write/overview /developers /docs/current/home + + + + /docs/current/developer-docs/identity/authentication/email-password /docs/current/identity/authentication/overview + /docs/current/developer-docs/identity/authentication/nfid /docs/current/identity/authentication/overview + /docs/current/developer-docs/identity/authentication/siwb /docs/current/identity/authentication/overview + /docs/current/developer-docs/identity/authentication/siwe /docs/current/identity/authentication/overview + /docs/current/developer-docs/identity/authentication/siws /docs/current/identity/authentication/overview + /docs/current/developer-docs/identity/authentication/msq /docs/current/identity/authentication/overview + /docs/current/developer-docs/web-apps/browser-js/js-request-api /docs/current/developer-docs/developer-tools/off-chain/agents/javascript-agent + /docs/current/developer-docs/defi/tokens/asset_flow/index /docs/current/developer-docs/defi/overview + /docs/current/developer-docs/defi/tokens/ledger/overview /docs/current/developer-docs/defi/overview + /docs/current/developer-docs/defi/tokens/ledger/setup/overview /docs/current/developer-docs/defi/overview + /docs/current/developer-docs/defi/tokens/ledger/usage/overview /docs/current/developer-docs/defi/overview + /docs/current/developer-docs/web-apps/obtain-verify-ic-pubkey /docs/current/developer-docs/developer-tools/cli-tools/cli-reference/dfx-ping + /docs/current/developer-docs/web-apps/design-dapps /docs/current/developer-docs/smart-contracts/overview/introduction ` .split(/[\r\n]+/) .map((line) => line.trim().replace(/^#.*$/, "").trim()) diff --git a/sidebars.js b/sidebars.js index a2efbe15a6..bbff85da62 100644 --- a/sidebars.js +++ b/sidebars.js @@ -127,6 +127,17 @@ const sidebars = { label: "Overview", id: "developer-docs/smart-contracts/call/overview", }, + { + type: "doc", + label: "Async code & inter-canister calls", + id: "developer-docs/smart-contracts/advanced-features/async-code", + }, + { + type: "doc", + label: "Composite queries", + id: "developer-docs/smart-contracts/advanced-features/composite-query", + }, + "developer-docs/smart-contracts/advanced-features/query-stats", { type: "category", label: "Candid", @@ -191,55 +202,52 @@ const sidebars = { type: "category", label: "Advanced features", items: [ - { - type: "doc", - label: "Async code & inter-canister calls", - id: "developer-docs/smart-contracts/advanced-features/async-code", - }, - { - type: "doc", - label: "Composite queries", - id: "developer-docs/smart-contracts/advanced-features/composite-query", - }, - { - type: "doc", - label: "HTTP gateways & incoming requests", - id: "developer-docs/smart-contracts/advanced-features/handling-get-post-requests", - }, - { - type: "category", - label: "HTTPS outcalls", - items: [ - { - label: "Overview", - type: "doc", - id: "developer-docs/smart-contracts/advanced-features/https-outcalls/https-outcalls-overview", - }, - "developer-docs/smart-contracts/advanced-features/https-outcalls/https-outcalls-how-to-use", - "developer-docs/smart-contracts/advanced-features/https-outcalls/https-outcalls-get", - "developer-docs/smart-contracts/advanced-features/https-outcalls/https-outcalls-post", - ], - }, { type: "category", - label: "HTTP certification", - items: [ + label: "HTTP/HTTPS", + items: + [ { type: "doc", - id: "developer-docs/web-apps/http-compatible-canisters/custom-http-canisters", - label: "Custom HTTP canisters", + label: "HTTP gateways & incoming requests", + id: "developer-docs/smart-contracts/advanced-features/handling-get-post-requests", }, { - type: "doc", - id: "developer-docs/web-apps/http-compatible-canisters/serving-json-over-http", - label: "Serving JSON over HTTP", + type: "category", + label: "HTTPS outcalls", + items: [ + { + label: "Overview", + type: "doc", + id: "developer-docs/smart-contracts/advanced-features/https-outcalls/https-outcalls-overview", + }, + "developer-docs/smart-contracts/advanced-features/https-outcalls/https-outcalls-how-to-use", + "developer-docs/smart-contracts/advanced-features/https-outcalls/https-outcalls-get", + "developer-docs/smart-contracts/advanced-features/https-outcalls/https-outcalls-post", + ], }, { - type: "doc", - id: "developer-docs/web-apps/http-compatible-canisters/serving-static-assets-over-http", - label: "Serving static assets over HTTP", + type: "category", + label: "HTTP certification", + items: [ + { + type: "doc", + id: "developer-docs/web-apps/http-compatible-canisters/custom-http-canisters", + label: "Custom HTTP canisters", + }, + { + type: "doc", + id: "developer-docs/web-apps/http-compatible-canisters/serving-json-over-http", + label: "Serving JSON over HTTP", + }, + { + type: "doc", + id: "developer-docs/web-apps/http-compatible-canisters/serving-static-assets-over-http", + label: "Serving static assets over HTTP", + }, + ], }, - ], + ] }, { type: "doc", @@ -273,12 +281,11 @@ const sidebars = { "developer-docs/smart-contracts/signatures/signing-messages-t-schnorr", ], }, + "developer-docs/web-apps/independently-verifying-ic-signatures", ], }, "developer-docs/smart-contracts/advanced-features/periodic-tasks", - "developer-docs/smart-contracts/advanced-features/query-stats", "developer-docs/smart-contracts/advanced-features/simd", - "developer-docs/smart-contracts/advanced-features/system-canisters", "developer-docs/smart-contracts/advanced-features/time-and-timestamps", ], }, @@ -532,17 +539,9 @@ const sidebars = { ], }, { - type: "category", - label: "Browser JS", - items: [ - "developer-docs/web-apps/browser-js/js-frameworks", - "developer-docs/web-apps/browser-js/js-request-api", - ], - }, - { - type: "category", - label: "Frameworks", - items: ["developer-docs/web-apps/frameworks/juno"], + type: "doc", + label: "JS frameworks", + id: "developer-docs/web-apps/browser-js/js-frameworks", }, { type: "category", @@ -552,9 +551,7 @@ const sidebars = { "developer-docs/web-apps/custom-domains/using-custom-domains", ], }, - "developer-docs/web-apps/design-dapps", - "developer-docs/web-apps/independently-verifying-ic-signatures", - "developer-docs/web-apps/obtain-verify-ic-pubkey", + "developer-docs/web-apps/frameworks/juno", ], }, { @@ -759,10 +756,6 @@ const sidebars = { ], }, { - type: "category", - label: "Identity", - items: [ - { type: "category", label: "Authentication", items: [ @@ -771,7 +764,6 @@ const sidebars = { type: "doc", id: "developer-docs/identity/authentication/overview", }, - { type: "category", label: "Internet Identity (II)", @@ -786,14 +778,6 @@ const sidebars = { "developer-docs/identity/internet-identity/alternative-origins", ], }, - "developer-docs/identity/authentication/email-password", - "developer-docs/identity/authentication/nfid", - "developer-docs/identity/authentication/siwb", - "developer-docs/identity/authentication/siwe", - "developer-docs/identity/authentication/siws", - "developer-docs/identity/authentication/msq", - ], - }, { type: "category", label: "Verifiable credentials", @@ -824,23 +808,13 @@ const sidebars = { label: "Tokens", items: [ "developer-docs/defi/tokens/token-standards", - "developer-docs/defi/tokens/asset_flow/index", { type: "category", label: "Ledgers", items: [ - { - type: "doc", - label: "Overview", - id: "developer-docs/defi/tokens/ledger/overview", - }, { type: "category", label: "Setup", - link: { - type: "doc", - id: "developer-docs/defi/tokens/ledger/setup/overview", - }, items: [ "developer-docs/defi/tokens/ledger/setup/icp_ledger_setup", "developer-docs/defi/tokens/ledger/setup/icrc1_ledger_setup" @@ -849,10 +823,6 @@ const sidebars = { { type: "category", label: "Usage", - link: { - type: "doc", - id: "developer-docs/defi/tokens/ledger/usage/overview", - }, items: [ "developer-docs/defi/tokens/ledger/usage/icp_ledger_usage", "developer-docs/defi/tokens/ledger/usage/icrc1_ledger_usage" @@ -875,7 +845,7 @@ const sidebars = { }, { type: "category", - label: "Advanced", + label: "Rosetta", items: [ { type: "category", @@ -1211,101 +1181,6 @@ const sidebars = { }, ], }, - { - type: "category", - label: "Sample apps", - items: [ - "samples/overview", - { - type: "category", - label: "Hosting", - items: [ - "references/samples/hosting/godot-html5-template/README", - "references/samples/hosting/photo-storage/README", - "references/samples/hosting/static-website/README", - "references/samples/hosting/unity-webgl-template/README", - ], - }, - { - type: "category", - label: "Motoko", - items: [ - "references/samples/motoko/basic_bitcoin/README", - "references/samples/motoko/basic_dao/README", - "references/samples/motoko/cert-var/README", - "references/samples/motoko/classes/README", - "references/samples/motoko/composite_query/README", - "references/samples/motoko/counter/README", - { - type: "doc", - label: "CRUD example", - id: "references/samples/motoko/superheroes/README", - }, - "references/samples/motoko/encrypted-notes-dapp-vetkd/README", - "references/samples/motoko/encrypted-notes-dapp/README", - "references/samples/motoko/life/README", - "references/samples/motoko/hello_cycles/README", - "references/samples/motoko/send_http_get/README", - "references/samples/motoko/send_http_post/README", - "references/samples/motoko/ic-pos/README", - "references/samples/motoko/icrc2-swap/README", - "references/samples/motoko/internet_identity_integration/README", - "references/samples/motoko/minimal-counter-dapp/README", - "references/samples/motoko/parallel_calls/README", - "references/samples/motoko/pub-sub/README", - "references/samples/motoko/random_maze/README", - "references/samples/motoko/threshold-ecdsa/README", - "references/samples/motoko/token_transfer/README", - "references/samples/motoko/token_transfer_from/README", - "references/samples/motoko/vetkd/README", - ], - }, - { - type: "category", - label: "Rust", - items: [ - "references/samples/rust/basic_bitcoin/README", - "references/samples/rust/basic_dao/README", - "references/samples/rust/canister-info/README", - "references/samples/rust/composite_query/README", - "references/samples/rust/counter/README", - "references/samples/rust/defi/src/frontend/README", - "references/samples/rust/encrypted-notes-dapp-vetkd/README", - "references/samples/rust/encrypted-notes-dapp/README", - "references/samples/rust/icp_transfer/README", - "references/samples/rust/nft-wallet/README", - "references/samples/rust/parallel_calls/README", - "references/samples/rust/performance_counters/README", - "references/samples/rust/periodic_tasks/README", - "references/samples/rust/pub-sub/README", - "references/samples/rust/qrcode/README", - "references/samples/rust/send_http_get/README", - "references/samples/rust/send_http_post/README", - "references/samples/rust/threshold-ecdsa/README", - "references/samples/rust/token_transfer/README", - "references/samples/rust/token_transfer_from/README", - "references/samples/rust/vetkd/README", - ], - }, - { - type: "category", - label: "Native dapps", - items: [ - "references/samples/native-apps/unity_ii_applink/README", - "references/samples/native-apps/unity_ii_deeplink/README", - "references/samples/native-apps/unity_ii_deeplink/ii_integration_dapp/README", - ], - }, - { - type: "category", - label: "Svelte", - items: [ - "references/samples/svelte/svelte-motoko-starter/README", - "references/samples/svelte/svelte-starter/README", - ], - }, - ], - }, { type: "category", label: "References", @@ -1407,6 +1282,7 @@ const sidebars = { label: "Ingress messages", id: "references/ingress-messages", }, + "developer-docs/smart-contracts/advanced-features/system-canisters", { type: "category", label: "Node providers", From 28dd9b6346b969c5b6b908a29e4405f71d77fb00 Mon Sep 17 00:00:00 2001 From: Jessie Mongeon Date: Wed, 4 Dec 2024 13:26:37 -0800 Subject: [PATCH 2/8] remove redundant files --- .../defi/tokens/asset_flow/_category_.yml | 3 - .../defi/tokens/asset_flow/index.mdx | 146 ------------------ .../defi/tokens/ledger/overview.mdx | 31 ---- .../defi/tokens/ledger/setup/overview.mdx | 12 -- .../defi/tokens/ledger/usage/overview.mdx | 12 -- .../web-apps/browser-js/js-request-api.mdx | 78 ---------- docs/developer-docs/web-apps/design-dapps.mdx | 45 ------ .../web-apps/obtain-verify-ic-pubkey.mdx | 40 ----- plugins/utils/redirects.js | 3 - 9 files changed, 370 deletions(-) delete mode 100644 docs/developer-docs/defi/tokens/asset_flow/_category_.yml delete mode 100644 docs/developer-docs/defi/tokens/asset_flow/index.mdx delete mode 100644 docs/developer-docs/defi/tokens/ledger/overview.mdx delete mode 100644 docs/developer-docs/defi/tokens/ledger/setup/overview.mdx delete mode 100644 docs/developer-docs/defi/tokens/ledger/usage/overview.mdx delete mode 100644 docs/developer-docs/web-apps/browser-js/js-request-api.mdx delete mode 100644 docs/developer-docs/web-apps/design-dapps.mdx delete mode 100644 docs/developer-docs/web-apps/obtain-verify-ic-pubkey.mdx diff --git a/docs/developer-docs/defi/tokens/asset_flow/_category_.yml b/docs/developer-docs/defi/tokens/asset_flow/_category_.yml deleted file mode 100644 index 947103ef9c..0000000000 --- a/docs/developer-docs/defi/tokens/asset_flow/_category_.yml +++ /dev/null @@ -1,3 +0,0 @@ -label: 'Asset Flow' -position: 7 -collapsed: true \ No newline at end of file diff --git a/docs/developer-docs/defi/tokens/asset_flow/index.mdx b/docs/developer-docs/defi/tokens/asset_flow/index.mdx deleted file mode 100644 index 7ef4536041..0000000000 --- a/docs/developer-docs/defi/tokens/asset_flow/index.mdx +++ /dev/null @@ -1,146 +0,0 @@ ---- -keywords: [intermediate, tokens, tutorial, ledger, asset flow] ---- - -import TabItem from "@theme/TabItem"; -import { AdornedTabs } from "/src/components/Tabs/AdornedTabs"; -import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow"; -import { GlossaryTooltip } from "/src/components/Tooltip/GlossaryTooltip"; - - -# Asset flow - - - -## Overview - -When interacting with the [ICP or ICRC-1 ledgers](/docs/developer-docs//defi/overview.mdx), there are different asset flow operations that can be executed. These operations are: - -* **Transfer**: A simple transfer between two entities. -* **Approve**: Approving tokens to be spent by another entity. -* **Mint**: Creating new tokens (**Requires minting account privileges**). -* **Burn**: Destroying tokens. -* **TransferFrom**: Spend approved tokens on behalf of another entity. - -Both ledger types support these operations. There are several ways on how to create transactions corresponding to each asset flow operation. This guide will demonstrate how to use `dfx` using `Rust` code. - -### Prerequisites - -* Download and install [`dfx`](/docs/current/developer-docs/developer-tools/cli-tools/cli-reference/dfx-parent). - -* Setup an [ICP Rust agent](https://crates.io/crates/ic-agent). - -## Transfer tokens - -To transfer tokens, your transaction will need the following required fields: - -* `to`: The account that will receive the tokens. -* `amount`: The amount of tokens to be sent. - -Additionally, the transaction takes the following optional fields: - -* `from_subaccount`: The subaccount of the approver. -* `fee`: The fee paid by the sender for the transfer. If not set, the default fee will have to be paid. -* `memo`: An arbitrary 32 bytes array to ensure transaction hash uniqueness. -* `created_at_time`: A timestamp that is used to trigger the [deduplication mechanism](https://github.com/dfinity/ICRC-1/blob/main/standards/ICRC-1/README.md#transaction_deduplication). - -### dfx -Here is an example command for a `Transfer` transaction using `dfx`: -```bash -dfx canister call icrc1_ledger_canister icrc1_transfer "(record { to = record { owner = principal \"sckqo-e2vyl-4rqqu-5g4wf-pqskh-iynjm-46ixm-awluw-ucnqa-4sl6j-mqe\";}; amount = 10_000;})" -``` - -### Rust -Here is an example Rust code snippet for making a `Transfer` transaction: -```bash -let to = icrc_ledger_types::icrc1::account::Account{ owner:ic_principal::Principal::from_slice(&[1, 2, 3, 4]) , subaccount: None}; -let amount = candid::Nat::from(500u64); -let transfer_arg = icrc_ledger_types::icrc1::transfer::TransferArg{ - from_subaccount: None, - to, - amount, - fee: None, - memo: : None, - created_at_time: : None, -} -candid::Decode!(&ic_agent.update("icrc1_transfer", &candid::Encode!(&transfer_arg)?).await.unwrap(), Result).unwrap(); -``` -:::info -Mint and burn operations are technically speaking also transfers. They work exactly like regular transfers with certain conditions that have to be met. They are the following: -* For **mint** operations, the sender of the transfer has to be the minter account. This means that if you want to make mint transactions, you will need to know the private key of the minter account. The recipient will receive the newly minted tokens. -* For **burn** operations, the receiver needs to be set to the mint account while the sender can be any account. You can request the minter account by calling the `icrc1_minting_account` endpoint of the ledger. -::: - -## Approve tokens -To approve tokens, your transaction will need the following required fields: - -* `spender`: The account that is allowed to spend the tokens. -* `amount`: The maximum amount of tokens to be spent by the spender. - -Additionally, the transaction takes the following optional fields: - -* `from_subaccount`: The subaccount of the approver. -* `expected_allowance`: If set, this field serves as a guarantee that before the new approved amount is set, the expected allowance reflects the previously set approved amount. -* `expires_at`: The timestamp at which the allowance will expire. -* `fee`: The fee paid by the approver for the approval. If not set, the default fee will have to be paid. -* `memo`: An arbitrary 32 bytes array to ensure transaction hash uniqueness. -* `created_at_time`: A timestamp that is used to trigger the [deduplication mechanism](https://github.com/dfinity/ICRC-1/blob/main/standards/ICRC-1/README.md#transaction_deduplication). - -### dfx -Here is an example command for an `Approve` transaction using `dfx`: -```bash -dfx canister call icrc1_ledger_canister icrc2_approve "(record { amount = 500; spender = record{owner = principal \"sckqo-e2vyl-4rqqu-5g4wf-pqskh-iynjm-46ixm-awluw-ucnqa-4sl6j-mqe\";} })" -``` - -### Rust -Here is an example Rust code snippet for making an `Approve` transaction: -```bash -let spender = icrc_ledger_types::icrc1::account::Account{ owner:ic_principal::Principal::from_slice(&[1, 2, 3, 4]) , subaccount: None}; -let amount = candid::Nat::from(500u64); -let approve_args = icrc_ledger_types::icrc1::approve::ApproveArgs{ - from_subaccount: None, - spender, - amount, - expected_allowance: None, - expires_at: None, - fee: None, - memo: : None, - created_at_time: : None, -} -candid::Decode!(&ic_agent.update("icrc2_approve", &candid::Encode!(&approve_args)?).await.unwrap(), Result).unwrap(); -``` - -## Transferring approved tokens -To transfer approved tokens, your transaction will need the following required fields: -* `to`: The account that will receive the tokens. -* `from`: The approvers account who's tokens will be transferred. -* `amount`: The amount of tokens to be sent. -Additionally, the transaction takes the following optional fields: -* `spender_subaccount`: The subaccount of the spender. -* `fee`: The fee paid by the sender for the transfer. If not set the default fee will have to be paid. -* `memo`: An arbitrary 32 bytes array to ensure transaction hash uniqueness. -* `created_at_time`: A timestamp that is used to trigger the [deduplication mechanism](https://github.com/dfinity/ICRC-1/blob/main/standards/ICRC-1/README.md#transaction_deduplication). - -### dfx -Here is an example command for a `TransferFrom` transaction using `dfx`: -```bash -dfx canister call icrc1_ledger_canister icrc2_transfer_from "(record { from = record { owner = principal \"ltyfs-qiaaa-aaaak-aan3a-cai\";}; to = record { owner = principal \"sckqo-e2vyl-4rqqu-5g4wf-pqskh-iynjm-46ixm-awluw-ucnqa-4sl6j-mqe\";}; amount = 500;})" -``` - -### Rust -Here is an example Rust code snippet for making a `TransferFrom` transaction: -```bash -let to = icrc_ledger_types::icrc1::account::Account{ owner:ic_principal::Principal::from_slice(&[1, 2, 3, 4]) , subaccount: None}; -let from = icrc_ledger_types::icrc1::account::Account{ owner:ic_principal::Principal::from_slice(&[5, 6, 7, 8]) , subaccount: None}; -let amount = candid::Nat::from(500u64); -let transfer_from_arg = icrc_ledger_types::icrc1::transfer_from::TransferFromArgs{ - spender_subaccount: None, - from, - to, - amount, - fee: None, - memo: : None, - created_at_time: : None, -} -candid::Decode!(&ic_agent.update("icrc2_transfer_from", &candid::Encode!(&transfer_from_arg)?).await.unwrap(), Result).unwrap(); -``` \ No newline at end of file diff --git a/docs/developer-docs/defi/tokens/ledger/overview.mdx b/docs/developer-docs/defi/tokens/ledger/overview.mdx deleted file mode 100644 index 3700da07a1..0000000000 --- a/docs/developer-docs/defi/tokens/ledger/overview.mdx +++ /dev/null @@ -1,31 +0,0 @@ ---- -keywords: [intermediate, rosetta, tutorial, accountidentifier] ---- -import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow"; - -# Ledger overview - -In this section, you will learn about the different types of ledgers that exist on the Internet Computer. This guide will go into detail about what the different ledgers are, what their purposes are, and how they differ from ledgers you may be familiar with from other blockchains. - -## ICP ledger -The ICP ledger is a canister that is responsible for keeping track of ICP balances, processing new transactions, and providing clients with data about the history of transactions. It stores all data onchain. For every transaction, a single block is created, which points to its parent block by storing the parent block's hash. - -The ICP ledger uses `AccountIdentifiers` as its internal account representation. It is compatible with the ICRC-1 standard; however, due to the fact that it uses `AccountIdentifiers` instead of `Accounts'` it stores information in a different block format than ICRC-1 ledgers. The same is true for the minting account of the ICP ledger. - -It runs on the NNS subnet, as it is part of the NNS, and its controller is the governance canister. Upgrades to the ICP ledger have to be approved by the NNS, making the process decentralized. - -## ICRC-1 ledgers -ICRC-1 ledgers are a standardized version of ledgers on the Internet Computer. While [ICRC-1](/docs/current/developer-docs/defi/tokens/token-standards) is the network standard defining how ledger canisters should behave, an ICRC-1 ledger is a single implementation of the ICRC-1 standard. It differs from the ICP ledger as it uses `Accounts` as its internal representation. - -ICRC-1 ledgers are stand-alone implementations, but in many cases, they are part of a larger software structure, such as an SNS or chain-key token implementation. - -## Differences from other blockchains -One of the biggest differences between ledgers deployed on ICP and ledgers deployed on other blockchains is that most account-based blockchains have the balances of accounts baked into their base protocol (e.g., Ethereum). This is not the case with either the ICP or ICRC-1 ledgers. - -The ICP ledger canister sits on the application layer of the network rather than the protocol level. Consensus on the Internet Computer is independent of the existence of the ICP ledger. Nevertheless, the ICP ledger is fundamentally important to the way the network functions, especially due to its importance as a part of the NNS. - -Since the ICP ledger runs on the application layer, transfers of the ICP token do not happen at the protocol level as they do on other chains. All ICP token transactions go through this canister. Any information gathered about historic ICP token transactions originates from the ICP ledger canister. This includes the ICP index canister, which fetches blocks periodically from the ICP ledger canister. - -ICRC-1 ledgers are very similar in this regard; however, they resemble tokens that can often be found on other blockchains more closely. They are also run by a canister that runs the ICRC-1 ledger code, and all transactions of the ICRC-1 token go through an ICRC-1 ledger canister. - - diff --git a/docs/developer-docs/defi/tokens/ledger/setup/overview.mdx b/docs/developer-docs/defi/tokens/ledger/setup/overview.mdx deleted file mode 100644 index e466f691fc..0000000000 --- a/docs/developer-docs/defi/tokens/ledger/setup/overview.mdx +++ /dev/null @@ -1,12 +0,0 @@ ---- -keywords: [intermediate, rosetta, tutorial, accountidentifier] ---- -import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow"; - -# Ledger setup - -## Overview - -In this section you will learn how to setup a local instance of a ledger. This guide will go into depth on how to install, deploy and initialize two types of ledgers: -* [ICP Ledger Setup](/docs/developer-docs/defi/tokens/ledger/setup/icp_ledger_setup.mdx) -* [ICRC-1 Ledger Setup](/docs/developer-docs/defi/tokens/ledger/setup/icrc1_ledger_setup.mdx) diff --git a/docs/developer-docs/defi/tokens/ledger/usage/overview.mdx b/docs/developer-docs/defi/tokens/ledger/usage/overview.mdx deleted file mode 100644 index 50b8f356e2..0000000000 --- a/docs/developer-docs/defi/tokens/ledger/usage/overview.mdx +++ /dev/null @@ -1,12 +0,0 @@ ---- -keywords: [intermediate, rosetta, tutorial, accountidentifier] ---- -import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow"; - -# Ledger usage - -## Overview - -In this section you will learn how to use a ledger. This guide will go into depth on how to interact with two types of ledgers: -* [Using the ICP ledger](/docs/developer-docs/defi/tokens/ledger/usage/icp_ledger_usage.mdx) -* [Using the ICRC-1 ledger](/docs/developer-docs/defi/tokens/ledger/usage/icrc1_ledger_usage.mdx) diff --git a/docs/developer-docs/web-apps/browser-js/js-request-api.mdx b/docs/developer-docs/web-apps/browser-js/js-request-api.mdx deleted file mode 100644 index 2e27a28d9a..0000000000 --- a/docs/developer-docs/web-apps/browser-js/js-request-api.mdx +++ /dev/null @@ -1,78 +0,0 @@ ---- -keywords: [intermediate, browser js, javascript, ICP JavaScript agent, agents] ---- - -import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow"; - -# JavaScript request API - - - -## Overview - -To make API calls to ICP endpoints and canisters from a JavaScript program, the ICP JavaScript agent can be used. It provides call, query, and readState methods to an actor. - -## Install the ICP JavaScript agent - -To install the [ICP JavaScript agent](https://www.npmjs.com/package/@dfinity/agent) with `npm`, use the command: - -``` -npm i --save @dfinity/agent -``` - -## Import the ICP JavaScript agent in the browser - -To import the [ICP JavaScript agent](https://www.npmjs.com/package/@dfinity/agent) in the browser, use the import statement: - -``` -import * as agent from "@dfinity/agent"; -``` - -You can also use individual exports: - -``` -import { Actor, HttpAgent } from '@dfinity/agent'; -``` - -## Making API calls - -To make API calls, the [ICP JavaScript agent](https://www.npmjs.com/package/@dfinity/agent) uses the [`fetch`](https://www.npmjs.com/package/isomorphic-fetch) API. Here is an example: - -```javascript -import fetch from 'isomorphic-fetch'; -import { HttpAgent } from '@dfinity/agent'; - -const host = process.env.DFX_NETWORK === 'local' ? 'http://127.0.0.1:4943' : 'https://icp-api.io'; - -const agent = new HttpAgent({ fetch, host }); -``` - -This example includes a `host` option, since the agent will not be able to determine the host using the global context. - -You can also pass `fetchOptions` to the agent's constructor, such as a custom header: - -```javascript -import fetch from 'isomorphic-fetch'; -import { HttpAgent } from '@dfinity/agent'; - -const host = process.env.DFX_NETWORK === 'local' ? 'http://127.0.0.1:4943' : 'https://ic0.app'; - -/** - * @type {RequestInit} - */ -const fetchOptions = { - headers: { - 'X-Custom-Header': 'value', - }, -}; - -const agent = new HttpAgent({ fetch, host, fetchOptions }); -``` -## ICP JavaScript agent documentation - -To learn more about the [ICP JavaScript agent](https://www.npmjs.com/package/@dfinity/agent), check out the [ICP JavaScript agent documentation page](/docs/current/developer-docs/developer-tools/off-chain/agents/javascript-agent). - - -## Resources - -You can learn more about using the ICP JavaScript agent to make API calls in the [API documentation](https://agent-js.icp.xyz/agent/index.html). \ No newline at end of file diff --git a/docs/developer-docs/web-apps/design-dapps.mdx b/docs/developer-docs/web-apps/design-dapps.mdx deleted file mode 100644 index 8709825343..0000000000 --- a/docs/developer-docs/web-apps/design-dapps.mdx +++ /dev/null @@ -1,45 +0,0 @@ ---- -keywords: [beginner, concept, dapp design, design considerations] ---- - -import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow"; - -# Dapp design considerations - - - -## Overview - -As you come up with ideas for dapps, you are going to make many design decisions about how to structure and organize your project. On the Internet Computer, there are a few design decisions that you should pay particular attention to as you plan the implementation for your app. - -## Single or multiple canister architecture - -One of the first decisions you might want to consider when designing your dapp is whether it should be encapsulated in a single canister or consist of multiple canisters. - -For example, if you are writing a simple service with no frontend, you might want to use a single canister to simplify project management and maintenance and focus on adding features. If your dapp has both frontend assets and backend business logic, your project is likely to consist of at least two canisters, with one canister for managing user interface components and another canister for the backend services the application provides. - -In planning, you might also consider placing some common reusable services in their own canister so that they can be imported and called from other more-specialized canisters or made available for other developers to use. The [LinkedUp](https://github.com/dfinity/linkedup) sample dapp illustrates this approach by splitting the professional service dapp into two canisters. In the LinkedUp example, the functions that establish social connections are defined in the `connectd` canister and separate from the functions used to set up professional profiles that are defined in the `linkedup` canister. It is easy to imagine extending the dapp with a third canister, for example to schedule events based on profile attributes or shared connections. - -## Segregating actors from types and utilities - -In planning the architecture for your project, one common practice is to place the code for the main actor in one file with separate additional files for defining the types you program uses and utility functions that don’t require an actor. - -For example, you might set up the backend logic for your dapp to consist of the following files: - -- `Main.mo` or `main.rs` with the functions that require an actor to send query and update calls. - -- `Util.mo` or `util.rs` with helper functions that can be imported for the actor to use. - -- `Types.mo` or `types.rs` with all of the data type definitions for your dapp. - -## Using query calls - -As discussed in [query and update methods](/docs/current/concepts/canisters-code#query-update), queries return results faster than update calls. Therefore, explicitly marking a function as a `query` is an effective strategy for improving application performance. In the planning and design phase, you should consider how best to use query calls instead of functions that can perform queries or updates. - -That is a good general rule to follow and can be applied broadly to most categories of dapps. However, you should also consider the security and performance trade-off that queries don’t go through consensus and do not appear on the blockchain. For some dapps, that trade-off might be appropriate. For example, if you are developing a blogging platform, queries that retrieve articles matching a tag probably don’t warrant going through consensus to ensure that a majority of nodes agree on the results. However, if your dapp is retrieving sensitive information—like financial data—you might want more assurance about your results than a basic query provides. - -As an alternative to basic queries, the Internet Computer also supports **certified queries**. Certified queries enable you to receive **authenticated responses** that end users can trust. Using certified queries is an advanced technique that is not covered in the tutorials or other developer-focused documentation, but you can learn about how the authentication works and what you need to do to configure your program to return certified data in response to queries in the [IC interface specification](/references/ic-interface-spec.md). - -## Data storage and retrieval - -The Internet Computer enables you to use **stable memory** to handle long-term data storage—often referred to as orthogonal persistence—and to use **query calls** to retrieve your data. Efficiently retrieving data using one or more keys can typically be achieved by using data structures like hash tables. It is also possible to implement a more traditional database inside a canister. diff --git a/docs/developer-docs/web-apps/obtain-verify-ic-pubkey.mdx b/docs/developer-docs/web-apps/obtain-verify-ic-pubkey.mdx deleted file mode 100644 index f973f38922..0000000000 --- a/docs/developer-docs/web-apps/obtain-verify-ic-pubkey.mdx +++ /dev/null @@ -1,40 +0,0 @@ ---- -keywords: [intermediate, tutorial, verifying public key, obtaining public key, public key, ic public key] ---- - -import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow"; - -# Verifying the public key - - - -## Overview - -When a user or canister receives a response from ICP, that response will have a certificate that validates the response has not been altered or changed. This certificate is signed by the root of trust, which is the ICP root public key. This public key can be used to additionally verify that a user or canister is interacting with a version of ICP that has not been tampered with, verifying that the response's certificate is valid. - -### Local - -In a local canister execution environment, the key can be fetched via the [`/api/v2/status`](/docs/current/references/ic-interface-spec#api-status) endpoint. - -### Mainnet - -On the mainnet, you can use [the ICP JavaScript agent](https://github.com/dfinity/agent-js) or [agent-rs](https://github.com/dfinity/agent-rs) to fetch the public key, as these agents have the root key [hard-coded](https://github.com/dfinity/agent-js/blob/main/packages/agent/src/agent/proxy.ts#L244C1-L250C2). - -## Verifying the public key - -Once you have obtained the public key, you can validate it is correct by using `dfx` to ping the network you're using, such as: - -```bash -dfx ping ic // mainnet -dfx ping local // local canister execution -``` - -This ping command will return the public root key of the network specified: - -```json -{ - "ic_api_version": "0.18.0" "replica_health_status": "healthy" "root_key": [48, 129, 130, 48, 29, 6, 13, 43, 6, 1, 4, 1, 130, 220, 124, 5, 3, 1, 2, 1, 6, 12, 43, 6, 1, 4, 1, 130, 220, 124, 5, 3, 2, 1, 3, 97, 0, 129, 76, 14, 110, 199, 31, 171, 88, 59, 8, 189, 129, 55, 60, 37, 92, 60, 55, 27, 46, 132, 134, 60, 152, 164, 241, 224, 139, 116, 35, 93, 20, 251, 93, 156, 12, 213, 70, 217, 104, 95, 145, 58, 12, 11, 44, 197, 52, 21, 131, 191, 75, 67, 146, 228, 103, 219, 150, 214, 91, 155, 180, 203, 113, 113, 18, 248, 71, 46, 13, 90, 77, 20, 80, 95, 253, 116, 132, 176, 18, 145, 9, 28, 95, 135, 185, 136, 131, 70, 63, 152, 9, 26, 11, 170, 174] -} -``` - - diff --git a/plugins/utils/redirects.js b/plugins/utils/redirects.js index 26cd7dd720..ff2d5b9630 100644 --- a/plugins/utils/redirects.js +++ b/plugins/utils/redirects.js @@ -644,9 +644,6 @@ const redirects = ` /docs/current/developer-docs/smart-contracts/advanced-features/serving-http-request /docs/current/developer-docs/smart-contracts/advanced-features/handling-get-post-requests /docs/current/developer-docs/smart-contracts/write/default-template /docs/current/developer-docs/smart-contracts/write/overview /developers /docs/current/home - - - /docs/current/developer-docs/identity/authentication/email-password /docs/current/identity/authentication/overview /docs/current/developer-docs/identity/authentication/nfid /docs/current/identity/authentication/overview /docs/current/developer-docs/identity/authentication/siwb /docs/current/identity/authentication/overview From 4229b43a945f77162fd3b29c4bf0584523970b42 Mon Sep 17 00:00:00 2001 From: Jessie Mongeon Date: Wed, 4 Dec 2024 13:58:28 -0800 Subject: [PATCH 3/8] cleanup docs --- .../identity/authentication/overview.mdx | 2 +- .../independently-verifying-ic-signatures.mdx | 24 +++++++------------ 2 files changed, 10 insertions(+), 16 deletions(-) diff --git a/docs/developer-docs/identity/authentication/overview.mdx b/docs/developer-docs/identity/authentication/overview.mdx index 196dead20f..0531a84618 100644 --- a/docs/developer-docs/identity/authentication/overview.mdx +++ b/docs/developer-docs/identity/authentication/overview.mdx @@ -20,7 +20,7 @@ Authentication methods available on ICP include: - [Internet Identity](/docs/current/developer-docs/identity/internet-identity/overview): ICP's native identity service that uses a cryptographic public/private key pair for authentication. -- [Email and password](email-password.mdx): Authentication with an email and password. +- [Email and password](https://nfid.one): Authentication with an email and password. - [NFID](https://nfid.one/): A digital form of identity that allows users to use an email and password or their Google account. diff --git a/docs/developer-docs/web-apps/independently-verifying-ic-signatures.mdx b/docs/developer-docs/web-apps/independently-verifying-ic-signatures.mdx index fb53b2f504..4136775964 100644 --- a/docs/developer-docs/web-apps/independently-verifying-ic-signatures.mdx +++ b/docs/developer-docs/web-apps/independently-verifying-ic-signatures.mdx @@ -44,17 +44,17 @@ The call is calculated using the content record, which allows the signature to b A transaction's signature can be delegated from one key to another. If delegation is used, the `sender_delegation` field contains an array of delegations with the following fields: -- `delegation` (`map`): A map containing the fields: +`delegation` (`map`): A map containing the fields: -    - `pubkey` (`blob`): A public key. +   - `pubkey` (`blob`): A public key. -    - `expiration` (`nat`): The delegation's expiration, defined in nanoseconds analogously to the `ingress_expiry`. +   - `expiration` (`nat`): The delegation's expiration, defined in nanoseconds analogously to the `ingress_expiry`. -    - `targets` (`array` of `CanisterId`, optional): Sets the delegation to apply only for requests sent to the canisters within the canister list; has a maximum of 1000 canisters. +   - `targets` (`array` of `CanisterId`, optional): Sets the delegation to apply only for requests sent to the canisters within the canister list; has a maximum of 1000 canisters. -    - `senders` (`array` of `Principal`, optional): Sets the delegation to only apply for requests originating from the principals in the list. +   - `senders` (`array` of `Principal`, optional): Sets the delegation to only apply for requests originating from the principals in the list. -    - `signature` (`blob`): The signature for the `32-byte` delegation field map, using the 27 bytes `\x1Aic-request-auth-delegation` as the domain separator. +   - `signature` (`blob`): The signature for the `32-byte` delegation field map, using the 27 bytes `\x1Aic-request-auth-delegation` as the domain separator. The first delegation in the array has a signature created using the public key corresponding to the `sender_pubkey` field. All subsequent delegations are signed with the public key corresponding to the key contained in the preceding delegation. @@ -64,15 +64,9 @@ The `sender_sig` field is calculated by concatenating the domain separator, `\x0 To verify a signature with an agent, an accepted identity is required. The following are accepted identity and signature types: -- Ed25519 and ECDSA signatures. +- Ed25519 and ECDSA signatures: Plain signatures are supported for these schemes. -    - Plain signatures are supported for the schemes. - -- Ed25519 or ECDSA on curve P-256 (also known as secp256r1). - -    - Using SHA-256 as a hash function. - -    - Using the Koblitz curve in secp256k1. +- Ed25519 or ECDSA on curve P-256 (also known as secp256r1): Support for using SHA-256 as a hash function or using the Koblitz curve in secp256k1. When these identities are encoded as a `Principal`, an agent will attach a suffix byte, which indicates whether the identity is anonymous or self-authenticating. @@ -125,7 +119,7 @@ match result { [Reference the crate's implementation logic](https://sourcegraph.com/github.com/dfinity/ic/-/blob/rs/validator/src/ingress_validation.rs?L605) for additional context. -## Verifying signatures with the library `@dfinity/standalone-sig-verifier-web` +## Verifying signatures with the JavaScript/TypeScript wrapper `@dfinity/standalone-sig-verifier-web` An `npm` library has been created as a JavaScript/TypeScript wrapper for the [`ic-standalone-sig-verifier`](https://github.com/dfinity/ic/tree/master/rs/crypto/standalone-sig-verifier) Rust crate. From 947545258b3fa0151d52d19d7be6e2fdb71f52f1 Mon Sep 17 00:00:00 2001 From: Jessie Mongeon Date: Wed, 4 Dec 2024 13:59:11 -0800 Subject: [PATCH 4/8] updates --- submodules/internetidentity | 2 +- submodules/motoko | 2 +- submodules/quill | 2 +- submodules/response-verfication | 2 +- submodules/samples | 2 +- submodules/sdk | 2 +- 6 files changed, 6 insertions(+), 6 deletions(-) diff --git a/submodules/internetidentity b/submodules/internetidentity index 29f7f61ae3..766795bf2f 160000 --- a/submodules/internetidentity +++ b/submodules/internetidentity @@ -1 +1 @@ -Subproject commit 29f7f61ae375ab2a0250db9df3e94efff1ad23b7 +Subproject commit 766795bf2f289685c1b66b9078b2aa54c5b6eb08 diff --git a/submodules/motoko b/submodules/motoko index 074ffca17f..6603c0ac25 160000 --- a/submodules/motoko +++ b/submodules/motoko @@ -1 +1 @@ -Subproject commit 074ffca17f95a3da876d8d0dda4d123cd5c16674 +Subproject commit 6603c0ac25df0ae7527b8abd3b563b0714c9b027 diff --git a/submodules/quill b/submodules/quill index 88158f521f..5a5a9ad4a7 160000 --- a/submodules/quill +++ b/submodules/quill @@ -1 +1 @@ -Subproject commit 88158f521f5f777bfe3ce68e5b21e1f2bc9fcadd +Subproject commit 5a5a9ad4a72ea9fa9f0adad5c3b11b00ced78db9 diff --git a/submodules/response-verfication b/submodules/response-verfication index 58770d8ae3..7e3f70d69f 160000 --- a/submodules/response-verfication +++ b/submodules/response-verfication @@ -1 +1 @@ -Subproject commit 58770d8ae39b99bfa5bb5ddd341e422f76552839 +Subproject commit 7e3f70d69fa5e238d1be81af58f89cb2a012abe7 diff --git a/submodules/samples b/submodules/samples index 24aca5b979..daf9a06654 160000 --- a/submodules/samples +++ b/submodules/samples @@ -1 +1 @@ -Subproject commit 24aca5b979fd7f3690ee31890b466c19f45a027d +Subproject commit daf9a06654785c59ec273df1df459bb1b03b85cf diff --git a/submodules/sdk b/submodules/sdk index 0cf8c452a5..3405dc6933 160000 --- a/submodules/sdk +++ b/submodules/sdk @@ -1 +1 @@ -Subproject commit 0cf8c452a5e51fddb73f9cf0a8d1878b122fcce8 +Subproject commit 3405dc693391c144c97ab77d8a67cf70a3606343 From a1501a827554794edd28626a0761b43cba58d2d5 Mon Sep 17 00:00:00 2001 From: Jessie Mongeon Date: Thu, 5 Dec 2024 11:22:34 -0800 Subject: [PATCH 5/8] fix redirects --- .../ethereum/using-eth/eth-dev-workflow.mdx | 2 +- plugins/utils/redirects.js | 20 +++++++++---------- 2 files changed, 11 insertions(+), 11 deletions(-) diff --git a/docs/developer-docs/multi-chain/ethereum/using-eth/eth-dev-workflow.mdx b/docs/developer-docs/multi-chain/ethereum/using-eth/eth-dev-workflow.mdx index 6d676c3016..e1bd07ef5c 100644 --- a/docs/developer-docs/multi-chain/ethereum/using-eth/eth-dev-workflow.mdx +++ b/docs/developer-docs/multi-chain/ethereum/using-eth/eth-dev-workflow.mdx @@ -41,7 +41,7 @@ Additional sample projects can be found in the [EVM RPC](../evm-rpc/samples.mdx) ## Integrating with Ethereum -The Ethereum integration can be incorporated into dapps for several purposes, such as authentication, as shown in the [Sign In With Ethereum (SIWE)](/docs/current/developer-docs/identity/authentication/siwe) example. The SIWE example showcases how to use an Ethereum wallet to sign into ICP applications. It creates a 1:1 correlation between Ethereum addresses and ICP principals within the scope of the application. It also guarantees that logging in with an Ethereum wallet will consistently produce the same principal regardless of the client used. +The Ethereum integration can be incorporated into dapps for several purposes, such as authentication, as shown in the [Sign In With Ethereum (SIWE)](https://github.com/kristoferlund/ic-siwe) example. The SIWE example showcases how to use an Ethereum wallet to sign into ICP applications. It creates a 1:1 correlation between Ethereum addresses and ICP principals within the scope of the application. It also guarantees that logging in with an Ethereum wallet will consistently produce the same principal regardless of the client used. ## Using ckETH diff --git a/plugins/utils/redirects.js b/plugins/utils/redirects.js index ff2d5b9630..3217b7a205 100644 --- a/plugins/utils/redirects.js +++ b/plugins/utils/redirects.js @@ -419,7 +419,7 @@ const redirects = ` /docs/current/developer-docs/integrations/bitcoin/local-development /docs/current/developer-docs/multi-chain/bitcoin/using-btc/local-development /docs/current/developer-docs/integrations/ethereum/overview /docs/current/developer-docs/multi-chain/ethereum/overview /docs/current/developer-docs/integrations/ethereum/evm-rpc /docs/current/developer-docs/multi-chain/ethereum/evm-rpc/evm-rpc-canister - /docs/current/developer-docs/integrations/ethereum/siwe /docs/current/developer-docs/identity/authentication/siwe + /docs/current/developer-docs/integrations/ethereum/siwe /docs/current/developer-docs/identity/authentication/overview /docs/current/developer-docs/integrations/bitcoin/bitcoin-how-it-works /docs/current/references/bitcoin-how-it-works /docs/current/developer-docs/integrations/bitcoin/ckbtc-reference /docs/current/references/ckbtc-reference /docs/current/developer-docs/integrations/https-outcalls/https-outcalls-how-it-works /docs/current/references/https-outcalls-how-it-works @@ -445,7 +445,7 @@ const redirects = ` /docs/current/developer-docs/smart-contracts/overview/development-cycle /docs/current/developer-docs/smart-contracts/overview/canister-lifecycle /docs/current/developer-docs/web-apps/user-login/internet-identity/integrate-identity /docs/current/developer-docs/identity/internet-identity/integrate-internet-identity /docs/current/developer-docs/multi-chain/ethereum/cketh /docs/current/developer-docs/multi-chain/chain-key-tokens/cketh/overview - /docs/current/developer-docs/multi-chain/ethereum/siwe /docs/current/developer-docs/identity/authentication/siwe + /docs/current/developer-docs/multi-chain/ethereum/siwe /docs/current/developer-docs/identity/authentication/overview /docs/current/developer-docs/multi-chain/bitcoin/ckbtc /docs/current/developer-docs/multi-chain/chain-key-tokens/ckbtc/overview /docs/current/developer-docs/multi-chain/bitcoin/read-state /docs/current/developer-docs/multi-chain/bitcoin/using-btc/read-state /docs/current/developer-docs/multi-chain/bitcoin/submit-transactions /docs/current/developer-docs/multi-chain/bitcoin/using-btc/submit-transactions @@ -523,8 +523,8 @@ const redirects = ` /docs/current/developer-docs/web-apps/user-login/internet-identity/integrate-internet-identity /docs/current/developer-docs/identity/internet-identity/integrate-internet-identity /docs/current/developer-docs/web-apps/user-login/internet-identity/alternative-origins /docs/current/developer-docs/identity/internet-identity/alternative-origins /docs/current/developer-docs/web-apps/user-login/nfid /docs/current/developer-docs/identity/authentication/overview - /docs/current/developer-docs/web-apps/user-login/email-password /docs/current/developer-docs/identity/authentication/email-password - /docs/current/developer-docs/multi-chain/ethereum/using-eth/siwe /docs/current/developer-docs/identity/authentication/siwe + /docs/current/developer-docs/web-apps/user-login/email-password /docs/current/developer-docs/identity/authentication/overview + /docs/current/developer-docs/multi-chain/ethereum/using-eth/siwe /docs/current/developer-docs/identity/authentication/overview /docs/current/developer-docs/build/cdks/motoko-dfinity/motoko/ /docs/current/motoko/main/getting-started/motoko-introduction /docs/current/developer-docs/defi/icrc-1/icrc1-index-setup /docs/current/developer-docs/defi/tokens/indexes /docs/current/defi/icp-tokens/icp-index-local-setup /docs/current/developer-docs/defi/tokens/indexes @@ -644,12 +644,12 @@ const redirects = ` /docs/current/developer-docs/smart-contracts/advanced-features/serving-http-request /docs/current/developer-docs/smart-contracts/advanced-features/handling-get-post-requests /docs/current/developer-docs/smart-contracts/write/default-template /docs/current/developer-docs/smart-contracts/write/overview /developers /docs/current/home - /docs/current/developer-docs/identity/authentication/email-password /docs/current/identity/authentication/overview - /docs/current/developer-docs/identity/authentication/nfid /docs/current/identity/authentication/overview - /docs/current/developer-docs/identity/authentication/siwb /docs/current/identity/authentication/overview - /docs/current/developer-docs/identity/authentication/siwe /docs/current/identity/authentication/overview - /docs/current/developer-docs/identity/authentication/siws /docs/current/identity/authentication/overview - /docs/current/developer-docs/identity/authentication/msq /docs/current/identity/authentication/overview + /docs/current/developer-docs/identity/authentication/email-password /docs/current/developer-docs/identity/authentication/overview + /docs/current/developer-docs/identity/authentication/nfid /docs/current/developer-docs/identity/authentication/overview + /docs/current/developer-docs/identity/authentication/siwb /docs/current/developer-docs/identity/authentication/overview + /docs/current/developer-docs/identity/authentication/siwe /docs/current/developer-docs/identity/authentication/overview + /docs/current/developer-docs/identity/authentication/siws /docs/current/developer-docs/identity/authentication/overview + /docs/current/developer-docs/identity/authentication/msq /docs/current/developer-docs/identity/authentication/overview /docs/current/developer-docs/web-apps/browser-js/js-request-api /docs/current/developer-docs/developer-tools/off-chain/agents/javascript-agent /docs/current/developer-docs/defi/tokens/asset_flow/index /docs/current/developer-docs/defi/overview /docs/current/developer-docs/defi/tokens/ledger/overview /docs/current/developer-docs/defi/overview From 578e5e3cba4b43fa8820c262abd75412af5fdb09 Mon Sep 17 00:00:00 2001 From: Jessie Mongeon Date: Thu, 5 Dec 2024 11:40:16 -0800 Subject: [PATCH 6/8] fix link --- blog/news-and-updates/2024-08-14-update.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/blog/news-and-updates/2024-08-14-update.mdx b/blog/news-and-updates/2024-08-14-update.mdx index 326605868f..49a024b7b4 100644 --- a/blog/news-and-updates/2024-08-14-update.mdx +++ b/blog/news-and-updates/2024-08-14-update.mdx @@ -27,7 +27,7 @@ The digital assets section of the developer docs has gotten an overhaul! Before, - [Token standards](/docs/current/developer-docs/defi/tokens/token-standards) -- [Asset flow](/docs/current/developer-docs/defi/tokens/asset_flow/) +- [Asset flow](/docs/current/developer-docs/defi/tokens/a) - [Ledger integration options](/docs/current/developer-docs/defi/tokens/advanced/direct_integration) From da0126a3e6e66900a43fb749459323d21e68ef53 Mon Sep 17 00:00:00 2001 From: Jessie Mongeon Date: Thu, 5 Dec 2024 12:23:15 -0800 Subject: [PATCH 7/8] fix link --- blog/news-and-updates/2024-08-14-update.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/blog/news-and-updates/2024-08-14-update.mdx b/blog/news-and-updates/2024-08-14-update.mdx index 49a024b7b4..79f178f4f3 100644 --- a/blog/news-and-updates/2024-08-14-update.mdx +++ b/blog/news-and-updates/2024-08-14-update.mdx @@ -27,7 +27,7 @@ The digital assets section of the developer docs has gotten an overhaul! Before, - [Token standards](/docs/current/developer-docs/defi/tokens/token-standards) -- [Asset flow](/docs/current/developer-docs/defi/tokens/a) +- [Asset flow](/docs/current/developer-docs/defi/tokens/overview) - [Ledger integration options](/docs/current/developer-docs/defi/tokens/advanced/direct_integration) From 78948baaa959a4d92f642bed6b8aea91dedaedf0 Mon Sep 17 00:00:00 2001 From: Jessie Mongeon Date: Thu, 5 Dec 2024 12:58:19 -0800 Subject: [PATCH 8/8] Fix links --- blog/news-and-updates/2024-08-14-update.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/blog/news-and-updates/2024-08-14-update.mdx b/blog/news-and-updates/2024-08-14-update.mdx index 79f178f4f3..19a6175e1a 100644 --- a/blog/news-and-updates/2024-08-14-update.mdx +++ b/blog/news-and-updates/2024-08-14-update.mdx @@ -27,7 +27,7 @@ The digital assets section of the developer docs has gotten an overhaul! Before, - [Token standards](/docs/current/developer-docs/defi/tokens/token-standards) -- [Asset flow](/docs/current/developer-docs/defi/tokens/overview) +- [Asset flow](/docs/current/developer-docs/defi/overview) - [Ledger integration options](/docs/current/developer-docs/defi/tokens/advanced/direct_integration)