Merge pull request #2228 from dfinity/update-ic-to-icp

Update 'IC' to 'ICP'

README.md

@@ -2,7 +2,7 @@
 
 # Internet Computer developer portal
 
-The IC developer portal brings together all the resources needed for developers to build on the
+The ICP developer portal brings together all the resources needed for developers to build on the
 Internet Computer.
 
 https://internetcomputer.org
@@ -11,7 +11,7 @@ https://internetcomputer.org
 
 ## Contributing
 
-The IC developer portal uses [Docusaurus](https://docusaurus.io/docs).
+The ICP developer portal uses [Docusaurus](https://docusaurus.io/docs).
 
 ## Format and style guidelines
 
@@ -191,9 +191,9 @@ Here is a description of how a contribution should be made to the developer port
 1. The contributor creates a fork/branch where the changes are made.
 2. A pull request (PR) is created from this branch to `master`. the preview is generated and the reviewers can directly check
    the preview website.
-3. After the pull request is merged into master, CI/CD will deploy the contents to the IC. The changes made will appear
+3. After the pull request is merged into master, CI/CD will deploy the contents to the ICP. The changes made will appear
    on the webpage under the version in the dropdown named "Current".
-4. Optional: When a repo maintainer tags a commit on master as $TAG, then CI/CD deploys the contents to the IC. The
+4. Optional: When a repo maintainer tags a commit on master as $TAG, then CI/CD deploys the contents to the ICP. The
    webpage will default to the new "$TAG" version, visible in the versions dropdown, and allow users to view the
    contents pinned at that tag.
 
@@ -231,7 +231,7 @@ We therefore invite other projects to:
 
 ## Community-created developer tools
 
-We invite developers to add their IC-focused developer tools to
+We invite developers to add their ICP-focused developer tools to
 the [developer tools page](https://internetcomputer.org/tooling) by appending an entry to the `communityToolingItems`
 array in `src/components/Common/toolingItems.ts`.
 

blog/features/composite-query.md

@@ -79,14 +79,14 @@ To start, let's set up our development environment. Make sure you have [dfx](htt
 DFX_VERSION=0.15.0-beta.1 sh -ci "$(curl -fsSL https://internetcomputer.org/install.sh)"
 ```
 
-Then clone the IC sample apps as follows:
+Then clone the ICP sample apps as follows:
 
 ```bash
 git clone https://github.com/dfinity/examples.git
 ```
 
 ## Deploy the example canister
-We first need to start a local IC instance via dfx and then create and build our frontend canister:
+We first need to start a local replica instance via dfx and then create and build our frontend canister:
 
 ```bash
 cd rust/composite_query/src

blog/features/dfx-deps.md

@@ -13,7 +13,7 @@ Today we're excited to announce a new dfx feature: dfx deps!
 
 ## What is `dfx deps`?
 
-`dfx deps` is a new set of subcommands designed to provide a consistent developer workflow for integrating and testing third-party canisters within local environments. Third-party canisters can be canisters created by DFINITY, such as the Internet Identity or NNS canisters, or they can be canisters created by members of the IC community that provide a public service at a *static canister ID*. 
+`dfx deps` is a new set of subcommands designed to provide a consistent developer workflow for integrating and testing third-party canisters within local environments. Third-party canisters can be canisters created by DFINITY, such as the Internet Identity or NNS canisters, or they can be canisters created by members of the ICP community that provide a public service at a *static canister ID*. 
 
 Testing third-party canister integrations locally is important to verify the third-party canister's integration functionality without paying cycles or using production environments. 
 
@@ -93,7 +93,7 @@ For example, the following `dfx.json` file configures two dependencies for the c
 }
 ```
 
-Then, these dependencies can be pulled using the `dfx deps pull` command. By default, the `dfx deps pull` connects to the IC mainnet. To deploy locally, the `--network local` flag can be used. 
+Then, these dependencies can be pulled using the `dfx deps pull` command. By default, the `dfx deps pull` connects to the mainnet. To deploy locally, the `--network local` flag can be used. 
 
 When this command is called, several things happen in the background, including:
 

blog/features/index.md

@@ -1,12 +1,12 @@
 ---
 title: Features
-description: Updates about features being developed on the IC
+description: Updates about features being developed on ICP
 sidebar_position: 1
 ---
 
 # Features updates
 
-Here you will find updates about the ongoing development of features on the IC. You can see what is currently in development by looking at
+Here you will find updates about the ongoing development of features on ICP. You can see what is currently in development by looking at
 - The [roadmap page on the website](/roadmap/)
 - The [roadmap tag on the forum](https://forum.dfinity.org/c/roadmap/29) - this is a great place to see discussions as they develop
 - [Community conversations playlist](https://youtube.com/playlist?list=PLuhDt1vhGcrdQu9Hw8eLDV9OTZXE5lklI) on Youtube

blog/features/replica-signed-queries.md

@@ -21,7 +21,7 @@ Having a single replica signature in a query response doesn't completely solve t
 
 First, a list of node IDs and their corresponding public keys is put into the subnet's state tree so that they can be certified by the subnet. Users can obtain the certificate to validate the node's keys through an HTTP `read_state` call that includes a timestamp value. 
 
-To support replica-signed queries, the query response format has been changed. The response to a query call adds a list with one signature for the returned response produced by the IC node that evaluated the query call.
+To support replica-signed queries, the query response format has been changed. The response to a query call adds a list with one signature for the returned response produced by the ICP node that evaluated the query call.
 
 If the call is replied to, the `reply` field is included. If the call is rejected, the `error_code`, `reject_code`, and `reject_message` fields will be included in the response. 
 
@@ -55,7 +55,7 @@ The query's signature (whose type is denoted as node-signature) is a [CBOR](http
 
 The actual parts that are signed include the query response from the execution layer, the timestamp and the request ID of the query, which is a SHA256 hash of the query's contents. With this `request_id` value, signatures for one query cannot be confused or exchanged for another.
 
-Query response verification is done via agents, such as agent-rs and agent-js, and other agents developed by members of the IC community. Agents now introduce a new `AgentError` type that indicates a verification failure. 
+Query response verification is done via agents, such as agent-rs and agent-js, and other agents developed by members of the ICP community. Agents now introduce a new `AgentError` type that indicates a verification failure. 
 
 replica-signed queries are supported in agent-rs [versions v0.30.0](https://github.com/dfinity/agent-rs/releases) and newer.
 
@@ -69,7 +69,7 @@ Then, to verify the certificate, the timestamp stored at `/time` of the node key
 
 ## How to use replica-signed queries
 
-On the IC, the replica has already begun producing signatures on query responses. 
+On ICP, the replica has already begun producing signatures on query responses. 
 
 To use agent-rs, signature verification on query responses is enabled by default on versions v0.30.0 and newer. Tools such as dfx will be updated to use the latest version of agent-rs in the next release (v0.15.2). 
 

blog/features/vetkey-primer.md

@@ -1,6 +1,6 @@
 # VETKeys Primer
 
-The **VETKeys** feature is in ongoing development on the Internet Computer (IC). It stands for ‘**V**erifiable **E**ncrypted **T**hreshold Keys’ and enables a number of cryptographic functionalities on the IC. The primary motivation for VETKeys is to facilitate onchain encryption, as such we focus this primer with that example in mind. 
+The **VETKeys** feature is in ongoing development on the Internet Computer (ICP). It stands for ‘**V**erifiable **E**ncrypted **T**hreshold Keys’ and enables a number of cryptographic functionalities on ICP. The primary motivation for VETKeys is to facilitate onchain encryption, as such we focus this primer with that example in mind. 
 
 One thing less discussed about the VETKeys feature is how we got here in terms of cryptography. The goal of this post is to lay some crypto background so that you can better understand the VETKeys talks, paper, and future posts. Note that understanding these foundations of VETkeys will *not* be necessary to use them for building applications, but we explain for those who are interested to dive deeper and want to understand the background. Let’s start at the start. 
 
@@ -72,11 +72,11 @@ Suppose Alice wants to send an encrypted message (across a public blockchain) to
 
 * Nodes in the network participate in the $\mathsf{DKG protocol}$ to obtain shares of a master secret key ($\mathit{msk}$) and a master public key ($\mathit{mpk}$). This results in each node $i$ holding key shares $(\mathit{msk_i, mpk_i})$.
 * Alice encrypts a message under Bob's identity $\mathit{id_{bob}}$ and the master public key $\mathit{mpk}$ and sends the resulting ciphertext to Bob.
-* Bob wants to decrypt and authenticates $\mathit{id_{bob}}$ to the IC and requests to derive a decryption key. Stop! 
+* Bob wants to decrypt and authenticates $\mathit{id_{bob}}$ to ICP and requests to derive a decryption key. Stop! 
 
 Note that if we continue in this scenario, the nodes will derive a decryption key and send the shares to Bob.. but, in a public network, those shares can be seen and can be combined by an observer. We require that derived key shares are encrypted for transport so that any observer or malicious nodes cannot combine them to obtain $\mathit{sk_{bob}}$. So, let’s continue.
 
-* Bob wants to decrypt and authenticates $\mathit{id_{bob}}$ to the IC. He uses a transport key generation algorithm $\mathsf{TKG}$ to generate and send a transport public key $\mathit{tpk}$ and requests to derive a decryption key. By sending $\mathit{tpk}$ Bob gives the nodes a way to encrypt their responses to him.
+* Bob wants to decrypt and authenticates $\mathit{id_{bob}}$ to ICP. He uses a transport key generation algorithm $\mathsf{TKG}$ to generate and send a transport public key $\mathit{tpk}$ and requests to derive a decryption key. By sending $\mathit{tpk}$ Bob gives the nodes a way to encrypt their responses to him.
 * If Bob’s authentication to $\mathit{id_{bob}}$ passes (likely performed by a dapp), nodes in the network use an $\mathsf{EKDerive}$ algorithm derive decryption key shares using $\mathit{msk}$ and $\mathit{id_{bob}}$ and encrypt them under $\mathit{tpk_{bob}}$. Note, this is the **E** requirement in VETKD.
 
 In a threshold system, sufficiently many key shares are required to produce a valid key. In this case it is useful to know when or if we have sufficiently many valid key shares so that the process can stop.
@@ -108,7 +108,7 @@ BLS signatures are a particular type of digital signature introduced in by Dan B
 
 The main feature of BLS signatures is that they’re very short, unique, fast to compute, aggregatable, and easy to port to the distributed setting (relative to other signature schemes at least..). This makes them a great candidate signature scheme for the blockchain setting. 
 As with any signature scheme, BLS comprises three algorithms; a (potentially distributed) key generation algorithm ((D)KG), a signing algorithm (Sign) and a verification algorithm (Verify). In the threshold setting, this is extended to include a fourth combination algorithm (Combine).
-Threshold BLS signatures are used a lot on the Internet Computer, so let’s use that as the motivating example for the scenario. Suppose nodes in a subnet want to convince Alice that a particular message is being sent from the IC. At a very high level, the scenario will run as follows:
+Threshold BLS signatures are used a lot on the Internet Computer, so let’s use that as the motivating example for the scenario. Suppose nodes in a subnet want to convince Alice that a particular message is being sent from ICP. At a very high level, the scenario will run as follows:
 * Nodes in the network participate in the DKG process and obtain (private) key shares.
 * Each node computes a signature share on a message $m$ using its share of the signing key. 
 * Nodes participate in a $\mathsf{Combine}$ process to combine signature shares and produce a single signature which is then sent to Alice.
@@ -128,7 +128,7 @@ VETKD is a new primitive that can be used to extend identity based encryption in
 Having these VETKeys opens a goldmine of functionality. There are further descriptions the VETKey family, i.e. extending VETKD to VETIBE, to VETSigs, to a VETPRF, and VETVRF. Future posts can go into details on these.
 
 ## Remarks
-This page contains a high level view and description of VETKD and its building blocks. The goal of this page is to build intuition for developers building on the IC, who are interested to know more about the technical choices, but who may lack the cryptographic background necessary to read research papers (for now). 
+This page contains a high level view and description of VETKD and its building blocks. The goal of this page is to build intuition for developers building on ICP, who are interested to know more about the technical choices, but who may lack the cryptographic background necessary to read research papers (for now). 
 It also shows one possible way of building VETKD, there are others, some with fancy features, that are described more in the paper. There are many use cases and motivations for building VETKD, these are discussed in [the video](https://youtu.be/baM6jHnmMq8) and can be written up if you like. There are also extensions that could be built depending on what is needed in the community. Finally, note that this page is hosted onchain.
 
 ## References

blog/features/wasm-native-stable-memory.md

@@ -80,7 +80,7 @@ fn insert_many(entries: Vec<(u128, u128)>) {
 }
 ```
 
-After deploying this dapp to the IC, we then execute multiple messages that bulk insert many key-value pairs (close to maxing out the ingress message size limit). The following graphs show the execution time for each of these messages.
+After deploying this dapp to ICP, we then execute multiple messages that bulk insert many key-value pairs (close to maxing out the ingress message size limit). The following graphs show the execution time for each of these messages.
 
 First, without Wasm-native stable memory:
 

blog/news-and-updates/2022-12-19-update.mdx

@@ -21,7 +21,7 @@ post [here](https://forum.dfinity.org/t/generational-gc-on-playground-and-new-as
 We are excited to announce a new collaboration which brings
 runnable [Motoko code snippets](https://embed.smartcontracts.org/) directly into the [Medium](https://medium.com/)
 social publishing platform.
-As a part of an ongoing effort to overhaul Motoko’s documentation, we wanted to make it easy for anyone in the IC
+As a part of an ongoing effort to overhaul Motoko’s documentation, we wanted to make it easy for anyone in ICP
 community to create interactive tutorials and code examples across the Internet.
 You can see the full
 post [here](https://forum.dfinity.org/t/embed-motoko-interactive-code-snippets-directly-in-your-medium-story-or-blog-post/17433).

blog/news-and-updates/2023-01-30-update.mdx

@@ -35,8 +35,8 @@ canisters’ performance and informs you on how you can fine tune your code to a
 
 There’s a new kid on the block - @rvanasa just released a new JavaScript library for interacting with Internet Computer.
 From the repository description,
-The ic0 package is a simple, straightforward way to interact with canisters running on the Internet Computer (IC).
-With ic0 you can instantiate representations of local, dev, or IC canisters in JS, make calls to them, and evaluate
+The ic0 package is a simple, straightforward way to interact with canisters running on the Internet Computer (ICP).
+With ic0 you can instantiate representations of local, dev, or ICP canisters in JS, make calls to them, and evaluate
 their responses. You can also create mock canisters for testing or running experiments.
 Give it a try and let us know what you think.
 https://github.com/dfinity/node-ic0

blog/news-and-updates/2023-03-21-update.mdx

@@ -38,10 +38,10 @@ Composed of a mere 200 lines of Motoko, this canister exemplifies the unique adv
 and robust code. Feel free to adopt a shared threshold voting scheme for your use-case by deploying with an initial
 signers list. We welcome any feedback you have on this canister in the public repository.
 
-## Canister-profiling: uncover the secrets of IC canister performance
+## Canister-profiling: uncover the secrets of ICP canister performance
 ![Motoko](../_assets/race-track.webp)
 
-Eager to compare data structure performance on the IC, or perhaps the performance of entire languages or canisters? Look
+Eager to compare data structure performance on ICP, or perhaps the performance of entire languages or canisters? Look
 no further than our [canister-profiling](https://github.com/dfinity/canister-profiling) repository.
 
 There, you'll find cycle usage per benchmark (linked under the "Performance" section of the README). Additionally,

blog/news-and-updates/2023-03-31-update.mdx

@@ -36,7 +36,7 @@ continue to prioritize bugs as we go into the next quarter, so keep an eye out f
 See the [release notes](https://github.com/dfinity/sdk/releases/tag/0.13.0) for everything that went into the latest release of dfx.
 
 ## Looking ahead
-Q2 will bring us a refined focus on developer experience. We will be taking a holistic look at the IC stack and applying
+Q2 will bring us a refined focus on developer experience. We will be taking a holistic look at the ICP stack and applying
 fundamentals of user experience research to help us understand how we can better improve our tools and services for you.
 
 Of course, there is no magic bullet, and this will be an ongoing, iterative process. But we are really excited to dive in to the next quarter with a renewed focus on

blog/news-and-updates/2023-04-03-update.mdx

@@ -1,6 +1,6 @@
 ---
 title: Motoko update April 3, 2023
-description: Today, we’re excited to discuss Motoko’s new Stable Regions and a new IC Certification library! If you want to weigh in on the direction of stable memory developments in Motoko or checkout a new certification library, then keep reading.
+description: Today, we’re excited to discuss Motoko’s new Stable Regions and a new ICP Certification library! If you want to weigh in on the direction of stable memory developments in Motoko or checkout a new certification library, then keep reading.
 tags: [New features]
 image: https://lh6.googleusercontent.com/oXZMmHoSuaIlOCVxpJZROCnpevVBA57VY9lKjl59bixEvpNtNJm_D0ZszNsam2dcAgI_cb2E9_jbcNQ2ZNZjKoWBlsG3z3wII0-abpK1x36pvl2tg4P0g0ovGZG-toDY3QVnmuk2FNpWyAdQzrOezWI
 authors:
@@ -14,7 +14,7 @@ Hey Motoko developers! 👋
 
 Welcome back to the latest Motoko update post!
 If you happened to miss our previous update you can find the post [here](https://forum.dfinity.org/t/motoko-update-part-9-threshold-canister-benchmark-insights/19040). Last time we discussed performance benchmarking of Motoko and the recently released threshold canister.
-Today, we’re excited to discuss Motoko’s new stable regions and a new IC certification library! If you want to weigh in on the direction of stable memory developments in Motoko or checkout a new certification library, then keep reading.
+Today, we’re excited to discuss Motoko’s new stable regions and a new ICP certification library! If you want to weigh in on the direction of stable memory developments in Motoko or checkout a new certification library, then keep reading.
 
 ![|624x416](https://lh4.googleusercontent.com/Vbnd4HtSiYn0O7WBhOa59ids6A9e6wkrWtvwuuET2gw_wQAsop88oZDaE5Lt74JzhugaGkNND-DE4aZrKnuMy7o4AeU5mUXR7J7uJM9nPiHgMpbhisoe1P3nSaNmPBvTqSQpNOSOD1lf2y1ajd09xXA)