Fix docs links

motoko/dip721-nft-container/README.md

@@ -28,7 +28,7 @@ When upgrading canister code, however, it is necessary to explicitly handle cani
  ### 2. Certified data.
 Generally, when a function only reads data, instead of modifying the state of the canister, it is
 beneficial to use a [query call instead of an update call](https://internetcomputer.org/docs/current/concepts/canisters-code.md#query-and-update-methods).
-But, since query calls do not go through consensus, [certified responses](https://internetcomputer.org/docs/current/developer-docs/security/general-security-best-practices)
+But, since query calls do not go through consensus, [certified responses](https://internetcomputer.org/docs/current/developer-docs/security/security-best-practices/overview )
 should be used wherever possible. The HTTP interface of the Rust implementation shows how certified data can be handled.
 
  ### 3. Delegating control over assets.
@@ -47,7 +47,7 @@ In case an error occurs during any part of the upgrade (including `post_upgdrade
 
 The Rust CDK (Canister Development Kit) currently only supports one value in stable memory, so it is necessary to create an object that can hold everything you care about.
 In addition, not every data type can be stored in stable memory; only ones that implement the [CandidType trait](https://docs.rs/candid/latest/candid/types/trait.CandidType.html)
-(usually via the [CandidType derive macro](https://docs.rs/candid/latest/candid/derive.CandidType.html)) can be written to stable memory. 
+(usually via the [CandidType derive macro](https://docs.rs/candid/latest/candid/derive.CandidType.html)) can be written to stable memory.
 
 Since the state of our canister includes a `RbTree` which does not implement the `CandidType`, it has to be converted into a data structure (in this case a `Vec`) that implements `CandidType`.
 Luckily, both `RbTree` and `Vec` implement functions that allow converting to/from iterators, so the conversion can be done quite easily.
@@ -76,7 +76,7 @@ For a much more detailed explanation of how certification works, see [this expla
 - **Operator**: sort of a delegated owner. The operator does not own the NFT but can do the same actions an owner can do.
 - **Custodian**: creator of the NFT collection/canister. They can do anything (transfer, add/remove operators, burn, and even un-burn) to NFTs, but also mint new ones or change the symbol or description of the collection.
 
-The NFT example canister keeps access control in these three levels very simple: 
+The NFT example canister keeps access control in these three levels very simple:
 - For every level of control, a separate list (or set) of principals is kept.
 - Those three levels are then manually checked every single time someone attempts to do something for which they require authorization.
 - If a user is not authorized to call a certain function an error is returned.
@@ -88,7 +88,7 @@ Using this management canister address, we can construct its principal and set t
 
 ## NFT sample code tutorial
 
-### Prerequisites 
+### Prerequisites
 
 - [x] Install the [IC SDK](https://internetcomputer.org/docs/current/developer-docs/setup/install/index.mdx).
 - [x] Download and install [git.](https://git-scm.com/downloads)
@@ -108,7 +108,7 @@ cd examples/motoko/dip721-nft-container
  ### Step 3: Run a local instance of the Internet Computer:
 
 ```bash
-dfx start --background 
+dfx start --background
 ```
 
 **If this is not a new installation, you may need to run `start` with the `--clean` flag.**
@@ -123,7 +123,7 @@ This command deploys the DIP721 NFT canister with the following initialization a
 
 ```bash
 dfx deploy --argument "(
-  principal\"$(dfx identity get-principal)\", 
+  principal\"$(dfx identity get-principal)\",
   record {
     logo = record {
       logo_type = \"image/png\";
@@ -137,15 +137,15 @@ dfx deploy --argument "(
 ```
 
 #### What this does
-- `principal`: the initial custodian of the collection. A custodian is a user who can administrate the collection i.e. an "Admin" user. 
+- `principal`: the initial custodian of the collection. A custodian is a user who can administrate the collection i.e. an "Admin" user.
 
   :::info
   `"$(dfx identity get-principal)"` automatically interpolates the default identity used by dfx on your machine into the argument that gets passed to `deploy`.
   :::
 
 - `logo`: The image that represents this NFT collection.
 - `name`: The name of the NFT collection.
-- `symbol`: A short, unique symbol to identify the token. 
+- `symbol`: A short, unique symbol to identify the token.
 - `maxLimit`: The maximum number of NFTs that are allowed in this collection.
 
 You will receive output that resembles the following:
@@ -164,8 +164,8 @@ Use the following command to mint an NFT:
 ```bash
 dfx canister call dip721_nft_container mintDip721 \
 "(
-  principal\"$(dfx identity get-principal)\", 
-  vec { 
+  principal\"$(dfx identity get-principal)\",
+  vec {
     record {
       purpose = variant{Rendered};
       data = blob\"hello\";
@@ -208,7 +208,7 @@ You should see a principal returned:
 o4f3h-cbpnm-4hnl7-pejut-c4vii-a5u5u-bk2va-e72lb-edvgw-z4wuq-5qe
 ```
 
-Transfer the NFT from the default user to `ALICE`. 
+Transfer the NFT from the default user to `ALICE`.
 
 Here the arguments are:
 `from`: principal that owns the NFT
@@ -255,7 +255,7 @@ Output:
 
 ### `getMetadataDip721`
 
-Provide a token ID. 
+Provide a token ID.
 The token ID was provided to you when you ran `mintDip721`, e.g. `(variant { Ok = record { id = 1 : nat; token_id = 0 : nat64 } })` So, the token ID is 0 in this case.
 
 ```bash
@@ -410,7 +410,7 @@ Output:
 
 ### `ownerOfDip721`
 
-Provide a token ID. 
+Provide a token ID.
 The token ID was provided to you when you ran `mintDip721`, e.g. `(variant { Ok = record { id = 1 : nat; token_id = 0 : nat64 } })` So, the token ID is 0 in this case.
 
 ```bash

motoko/encrypted-notes-dapp/README.md

@@ -41,7 +41,7 @@ We wanted to build an example of a simple (but not too simple) dapp running pure
 1. Client-side **end-to-end encryption**. 
 2. **Multi-user** and **multi-device** support.
 
-To demonstrate the potential of the IC as a platform for developing such dapps, we implemented this example using two distinct canister development kits (CDKs). The Motoko CDK allows developers to implement actor-based dapps using the [Motoko](https://internetcomputer.org/docs/current/motoko/getting-started/motoko-introduction) language. The Rust CDK allows implementing dapps in [Rust](https://internetcomputer.org/docs/current/developer-docs/backend/rust/index). In both cases, canisters are compiled into WebAssembly files that are then deployed onto the IC.
+To demonstrate the potential of the IC as a platform for developing such dapps, we implemented this example using two distinct canister development kits (CDKs). The Motoko CDK allows developers to implement actor-based dapps using the [Motoko](https://internetcomputer.org/docs/current/motoko/getting-started/motoko-introduction) language. The Rust CDK allows implementing dapps in [Rust](https://internetcomputer.org/docs/current/developer-docs/backend/rust/). In both cases, canisters are compiled into WebAssembly files that are then deployed onto the IC.
 
 ## Architecture
 
@@ -110,7 +110,7 @@ Follow the steps below to deploy this sample project.
 
 ## Prerequisites
 - [x] Install the [IC SDK](https://internetcomputer.org/docs/current/developer-docs/setup/install/index).
-- [x] Download and install [Docker](https://docs.docker.com/get-docker/) if using the Docker option. 
+- [x] Download and install [Docker](https://docs.docker.com/get-docker/) if using the Docker option.
 - [x] Download the GitHub repo containing this project's files: `git clone https://github.com/dfinity/examples`
 
 ### Step 1. Navigate inside of the project's folder:
@@ -139,7 +139,7 @@ export BUILD_ENV=motoko
 
 - #### Step 1: Install and start Docker by following the instructions.
 - #### Step 2: For Motoko build/deployment set environmental variable:
-        
+
 ```bash
 export BUILD_ENV=motoko
 ```
@@ -247,7 +247,7 @@ npm run dev
 
 
 :::caution
-If you have opened this page previously, please remove all local store data for this page from your web browser, and hard-reload the page. 
+If you have opened this page previously, please remove all local store data for this page from your web browser, and hard-reload the page.
 
 For example in Chrome, go to Inspect → Application → Local Storage → http://localhost:3000/ → Clear All, and then reload.
 :::
@@ -320,9 +320,9 @@ Fig. 2. Basic single-device scenario for a user.
 
 - #### Step 3: Once logged in for the first time, your notes list should be empty.
 
-At this moment, your _Local Storage_ should be populated with additional variables (see Fig. 2(d)): **ic-identity**, **ic-delegation**. 
+At this moment, your _Local Storage_ should be populated with additional variables (see Fig. 2(d)): **ic-identity**, **ic-delegation**.
 
-These variables are used for storing/retrieving notes from the backend canister. 
+These variables are used for storing/retrieving notes from the backend canister.
 
 In addition, another two variables are generated in the _IndexedDB_: **PrivateKey**, **PublicKey**. These two variables are used for encrypting/decrypting the shared secret key.
 
@@ -341,7 +341,7 @@ Fig. 3. Scenario for a user with multiple registered devices.
 
 - #### Step 1: Perform steps 1-3 of Scenario I on Device A.
 
-- #### Step 2:. Perform steps 1-3 of Scenario I on Device B. 
+- #### Step 2:. Perform steps 1-3 of Scenario I on Device B.
 
 One subtle difference that you might observe on Device B is that the message "Synchronizing..." (Fig. 3(a)) appears for a short time. As Device A was the first to log in, it was also the first one to generate a shared secret. Device B has to retrieve it. To do that, Device B first uploads its public key (pub B) to the backend canister. Device A retrieves pub B using periodic polling. Device A then re-encrypts the shared secret with pub B and uploads it to the backend. Afterward, Device B can retrieve the encrypted shared secret and decrypt it with its private key.
 
@@ -380,7 +380,7 @@ Fig. 4. Scenario for a user adding/removing devices.
 
 ## Unit testing
 
-The unit tests are implemented in `src/encrypted_notes_motoko/test/test.mo` using the [Motoko Matchers](https://kritzcreek.github.io/motoko-matchers/) library. 
+The unit tests are implemented in `src/encrypted_notes_motoko/test/test.mo` using the [Motoko Matchers](https://kritzcreek.github.io/motoko-matchers/) library.
 
 The easiest way to run all tests involves the following steps:
 
@@ -508,7 +508,7 @@ This dapp uses the web browser's `_Local Storage_` and `_IndexedDB_` for storing
 
 :::
 
-A symmetric key for encrypting/decrypting the notes is stored in RAM (this key is shared between multiple devices). For a better understanding of the mechanics of the dapp, please see the `_Local Storage_`/`_IndexedDB_` windows in your web browser. 
+A symmetric key for encrypting/decrypting the notes is stored in RAM (this key is shared between multiple devices). For a better understanding of the mechanics of the dapp, please see the `_Local Storage_`/`_IndexedDB_` windows in your web browser.
 
 In Chrome, go to: _Developer Tools→Application→Local Storage_/_IndexedDB_.
 

rust/dip721-nft-container/README.md

@@ -2,7 +2,7 @@
 keywords: [advanced, rust, nft, dip721]
 ---
 
-# DIP721 NFT 
+# DIP721 NFT
 
 [View this sample's code on GitHub](https://github.com/dfinity/examples/tree/master/rust/dip721-nft-container)
 
@@ -28,7 +28,7 @@ When upgrading canister code, however, it is necessary to explicitly handle cani
  ### 2. Certified data.
 Generally, when a function only reads data, instead of modifying the state of the canister, it is
 beneficial to use a [query call instead of an update call](https://internetcomputer.org/docs/current/concepts/canisters-code.md#query-and-update-methods).
-But, since query calls do not go through consensus, [certified responses](https://internetcomputer.org/docs/current/developer-docs/security/general-security-best-practices)
+But, since query calls do not go through consensus, [certified responses](https://internetcomputer.org/docs/current/developer-docs/security/security-best-practices/overview )
 should be used wherever possible. The HTTP interface of the Rust implementation shows how certified data can be handled.
 
  ### 3. Delegating control over assets.
@@ -47,7 +47,7 @@ In case an error occurs during any part of the upgrade (including `post_upgdrade
 
 The Rust CDK (Canister Development Kit) currently only supports one value in stable memory, so it is necessary to create an object that can hold everything you care about.
 In addition, not every data type can be stored in stable memory; only ones that implement the [CandidType trait](https://docs.rs/candid/latest/candid/types/trait.CandidType.html)
-(usually via the [CandidType derive macro](https://docs.rs/candid/latest/candid/derive.CandidType.html)) can be written to stable memory. 
+(usually via the [CandidType derive macro](https://docs.rs/candid/latest/candid/derive.CandidType.html)) can be written to stable memory.
 
 Since the state of our canister includes an `RbTree` which does not implement the `CandidType`, it has to be converted into a data structure (in this case a `Vec`) that implements `CandidType`.
 Luckily, both `RbTree` and `Vec` implement functions that allow converting to/from iterators, so the conversion can be done quite easily.
@@ -76,7 +76,7 @@ For a much more detailed explanation of how certification works, see [this expla
 - **Operator**: sort of a delegated owner. The operator does not own the NFT but can do the same actions an owner can do.
 - **Custodian**: creator of the NFT collection/canister. They can do anything (transfer, add/remove operators, burn, and even un-burn) to NFTs, but also mint new ones or change the symbol or description of the collection.
 
-The NFT example canister keeps access control in these three levels very simple: 
+The NFT example canister keeps access control in these three levels very simple:
 - For every level of control, a separate list (or set) of principals is kept.
 - Those three levels are then manually checked every single time someone attempts to do something for which they require authorization.
 - If a user is not authorized to call a certain function an error is returned.
@@ -111,7 +111,7 @@ cd examples/rust/dip721-nft-container
 dfx start --background --clean
 ```
 
- ### Step 3: Install the canister. 
+ ### Step 3: Install the canister.
 
 Deploy the canister with the command:
 ```sh
@@ -145,9 +145,9 @@ The canister also supports a certified HTTP interface; going to `/<nft>/<id>` wi
 
 Remember that query functions are uncertified; the result of functions like `ownerOfDip721` can be modified arbitrarily by a single malicious node. If queried information is depended on, for example, if someone might send ICP to the owner of a particular NFT to buy it from them, those calls should be performed as update calls instead. You can force an update call by passing the `--update` flag to `dfx` or using the `Agent::update` function in `agent-rs`.
 
- ### Step 5: Mint an NFT. 
+ ### Step 5: Mint an NFT.
 
-Due to size limitations on the length of a terminal command, an image- or video-based NFT would be impossible to send via `dfx`. To that end, there is an experimental [minting tool](https://github.com/dfinity/experimental-minting-tool) you can use to mint a single-file NFT. 
+Due to size limitations on the length of a terminal command, an image- or video-based NFT would be impossible to send via `dfx`. To that end, there is an experimental [minting tool](https://github.com/dfinity/experimental-minting-tool) you can use to mint a single-file NFT.
 
 To use this tool, install the minting tool with the command:
 

rust/encrypted-notes-dapp/README.md

@@ -42,7 +42,7 @@ We wanted to build an example of a simple (but not too simple) dapp running pure
 1. Client-side **end-to-end encryption**. 
 2. **Multi-user** and **multi-device** support.
 
-To demonstrate the potential of the IC as a platform for developing such dapps, we implemented this example using two distinct canister development kits (CDKs). The Motoko CDK allows developers to implement actor-based dapps using the [Motoko](https://internetcomputer.org/docs/current/motoko/getting-started/motoko-introduction) language. The Rust CDK allows implementing dapps in [Rust](https://internetcomputer.org/docs/current/developer-docs/backend/rust/index.md). In both cases, canisters are compiled into WebAssembly files that are then deployed onto the IC.
+To demonstrate the potential of the IC as a platform for developing such dapps, we implemented this example using two distinct canister development kits (CDKs). The Motoko CDK allows developers to implement actor-based dapps using the [Motoko](https://internetcomputer.org/docs/current/motoko/getting-started/motoko-introduction) language. The Rust CDK allows implementing dapps in [Rust](https://internetcomputer.org/docs/current/developer-docs/backend/rust/). In both cases, canisters are compiled into WebAssembly files that are then deployed onto the IC.
 
 ## Architecture