Apply PR feedback

blog/news-and-updates/2024-08-28-update.mdx

@@ -0,0 +1,50 @@
+---
+title: Developer weekly update August 28, 2024
+description: This week, we're excited to talk about the upcoming Beryllium milestone, a new episode of NNS explained, and a new release of the `ic-siwe` package.
+tags: [Devs]
+image: /img/blog/dev-update-blog-aug-28.jpg
+---
+
+# Developer weekly update August 28, 2024
+
+![August 28 2024](../../static/img/blog/dev-update-blog-aug-28.jpg)
+
+Hello developers, and welcome to this week's developer weekly update! This week, we're excited to talk about the upcoming Beryllium milestone, a new episode of NNS explained, and a new release of the `ic-siwe` package. Let's get started!
+
+## Beryllium milestone
+
+The Beryllium roadmap milestone is nearing completion and is expected to be released in early October! This milestone is focused on providing canister developer improvements and operation simplifications. Exciting features included in this milestone include:
+
+- Canister logging: Read and write canister runtime logs.
+
+- Canister snapshots: Rollback to previous snapshots to fix errors and recover data.
+
+- Canister lifecycle hooks: Canisters can receive notifications from ICP regarding lifecycle updates, such as low canister balance.
+
+- Actionable error messages and backtraces: Create a standard for response and error codes for better service composability.
+
+- Standardized canister response codes: Enhance error codes by providing actionable items and documentation explaining how to resolve errors.
+
+You can read the full details of this milestone on the [ICP roadmap](https://internetcomputer.org/roadmap#Developer%20Experience-Beryllium). 
+
+## ic-siwe v0.1.0
+
+The `ic-siwe` package enables developers to provide users with the option to login to an application with their Ethereum wallet. The latest release of `ic-siwe` introduces security improvements and reliability. Release notes include:
+
+- Breaking changes to the `prepare_login` and `login` functions.
+
+- Improved security through a nonce-based implementation and validated signature expiration.
+
+- Proper cleanup of SIWE messages through added logic to remove failed login attempts and prevent stale data. 
+
+[Learn more on the developer forum](https://forum.dfinity.org/t/announcing-ic-siwe-v0-1-0-security-fixes-making-nonce-required/34410).
+
+## New episode: NNS explained
+
+A new episode of the NNS explained series has been released! In this episode, [Verifying NNS Dapp Proposals](https://www.youtube.com/watch?v=J-aJFJ_4zIw), you can learn how to build the NNS dapp locally, obtain the proposed Wasm module hash included in a proposal, then verify that the proposed hash matches the hash of the NNS dapp you built and tested locally.
+
+You can learn more about the NNS explained series on the [developer forum](https://forum.dfinity.org/t/announcement-nns-explained-youtube-series/32337/12).
+
+That'll wrap up this week. Tune back in next week for more developer updates!
+
+-DFINITY

blog/news-and-updates/2024-09-04-update.mdx

@@ -0,0 +1,58 @@
+---
+title: Developer weekly update September 4, 2024
+description: In this week's update, we're excited to talk about the most recent update to the NNS, highlight an update on the community project Nauts World, and ask for your feedback regarding API changes for public and private neurons. 
+tags: [Devs]
+image: /img/blog/dev-update-blog-sept-4.jpg
+---
+
+# Developer weekly update September 4, 2024
+
+![September 4 2024](../../static/img/blog/dev-update-blog-sept-4.jpg)
+
+Hello developers, and welcome to this week's developer weekly update! In this week's update, we're excited to talk about the most recent update to the NNS, highlight an update on the community project Nauts World, and ask for your feedback regarding API changes for public and private neurons. Let's get started!
+
+## August 30, 2024 NNS updates
+
+On August 30, 2024, the following updates were proposed for three of the NNS canisters:
+
+- **Cycles minting canister**: Added more log visibility support, initialized `average_icp_xdr_conversion_rate`, and added support for `wasm_memory_threshold`.
+
+- **Governance canister**: Backfilled Neurons Fund data, removed `SetDefaultFollowees`, `SetSnsTokenSwapOpenTimeWindow`, and `OpenSnsTokenSwap` proposal types, disabled `UpdateAllowedPrincipals` proposal type, and added functionality where deprecated `*_pb` methods now fail.
+
+- **Genesis token canister**: Did not include any new features or fixes, but was updated as a general maintenance procedure.
+
+You can read more about these updates and verify the code for each by checking out the [forum post](https://forum.dfinity.org/t/nns-updates-2024-08-30/34620) with all the details.
+
+## Nauts World update
+
+A new season is starting at Nauts World! Nauts World is a collectible-based game featuring characters known as Nauts that players can mint, trade, and sell. There is exciting new functionality coming to Nauts World soon, including:
+
+- Mobile game: Nauts World will soon have an accompanying mobile game that will provide players a way to strengthen their arsenal of Nauts. 
+
+- NFT utility: Players can redeem a 3D printed variant of their Nauts NFT once certain criteria are met.
+
+- Game lore: Stories about the character's clans will be released to help improve world building and character development.
+
+- Nauts World staking sector will be released.
+
+Want to learn more? Read the full update on the [developer forum](https://forum.dfinity.org/t/nauts-world-season-update/34644/1).
+
+## Request for feedback: API changes for public and private neurons
+
+A request for comments has been opened on the forum regarding changes to the API for public and private neurons. These changes would include breaking changes, and your feedback is appreciated in helping to finalize the decisions regarding these changes. 
+
+Breaking changes would alter how an app reads neurons that do not belong to the caller, i.e., the caller is not a controller or hotkey of the neuron. Specifically, the fields `recent_ballots` and `joined_community_fund_timestmap_seconds` would not work, and would require a new field called `visibility` to properly interpret the values of either of these fields.
+
+Non-breaking changes include:
+
+- Allowing neurons to utilize the new `visibility` field.
+
+- Allow public neurons to be read without special privileges through changes to the `list_neurons` method.
+
+- Known Neurons will always be public.
+
+You can read the full details of these API changes and leave your feedback on the [developer forum](https://forum.dfinity.org/t/request-for-comments-api-changes-for-public-private-neurons/33360/1).
+
+That'll wrap up this week. Tune back in next week for more developer updates!
+
+-DFINITY

blog/news-and-updates/individual-spotlight-staff-researcher.mdx

@@ -0,0 +1,70 @@
+---
+title: Individual spotlight - Staff researcher
+description: In today's interview, we're chatting with Thomas from the Systems & Research team.
+tags: [Individual spotlight]
+image: /img/blog/indv-spotlight-6.jpg
+---
+
+![Product manager spotlight](../../static/img/blog/indv-spotlight-6.jpg)
+
+**Hello everyone, and welcome back to the individual spotlight series! In today's interview, we're chatting with Thomas from the Systems & Research team. Thomas is the research lead for multiple different engineering teams, and has worked on various important projects like the Bitcoin integration, the cycles ledger, and chain-key tokens. We're excited to learn more about Thomas' unique role at DFINITY and his perspective of the various different initiatives and features of ICP!
+
+**To kick things off, how is the role of a staff researcher different from other roles in the organization?**
+
+*Each researcher has the role of “research lead” for at least one engineering team. I’m the research lead for three teams: IC Integrations, SDK, and the Cross-Chain team, so I get to work on various different projects, such as the exchange rate canister (owned by the IC Integrations team), the recently released cycles ledger (SDK team), and everything related to Bitcoin, Ethereum, and chain-key tokens (cross-chain team).*
+
+**What responsibilities do you have as a staff researcher?**
+
+*As a staff researcher, one of my primary tasks is to lead and support bigger projects and features with a potentially large impact for the Internet Computer and DFINITY. A good example is the Bitcoin integration project, which was a significant cross-team effort to enable the creation of Bitcoin smart contracts on the Internet Computer. This integration is further the foundation of ckBTC, our first chain-key token.*
+
+**You’ve contributed to several of the different Chain Fusion projects, such as the Bitcoin integration and ckERC20 tokens. What was your role in the Bitcoin integration project?**
+
+*As the research lead for this feature, I was responsible for the technical specification. It was also my task to review the implementation to ensure that it conformed to the design. Of course, this was an iterative process, requiring many discussions with other researchers and the teams driving the implementation, and the design changed significantly throughout this process.*
+
+**What was your biggest learning or takeaway from working on the Bitcoin integration?**
+
+*Our Bitcoin integration is quite unique. Do you know any other smart contract on any blockchain that has a state size of nearly 100 GiB? I think the way Bitcoin blocks are ingested is unique too. Whenever you build something that has never been done before, there are many unknowns, which makes planning and estimating the required effort challenging. Maybe the biggest learning is that the challenges in such endeavors should never be underestimated—but this project also nicely showed that DFINITY has fantastic teams with the skill required to pull off such endeavors!*
+
+**Were there any challenges or hurdles that the team had to overcome during the Bitcoin integration?**
+
+*There were many challenges, small and large. One of the main challenges was to reach agreement across all involved teams and management about numerous important design decisions. For example, what information about the Bitcoin blockchain is stored? How many Bitcoin addresses can canisters have? Is the Bitcoin code part of the replica code, or does it run in a canister? And many more. Not surprisingly, many discussions were required, but in the end we converged on a fairly nice architecture, in my opinion.*
+
+**Let's talk about the ckERC20 project, that enabled ERC-20 tokens to be deployed on ICP as chain-key tokens. How was your role in this project different from your role in the Bitcoin integration project?**
+
+*It was actually quite different because, unlike in the Bitcoin integration project, the cross-chain team had already worked out a good design. So my focus was more on reviewing the specification and the implementation to make sure that they are consistent.*
+
+**You were also a contributor to the cycles ledger project that we did a [Project Spotlight](/blog/features/cycles-ledger) post on a few months ago. What has the community feedback been on the cycles ledger since launch?**
+
+*Before the launch, we were frequently asked when the cycles ledger would finally be ready. After the launch, there were a few positive comments, but that was it. I’d like to believe that the developers in our community are now happily using it, and we don’t hear anything because everything works as it should. But it is a good question. Maybe we should do a survey to figure out if the cycles ledger really lives up to the developers’ expectations.*
+
+**To switch gears a bit, let's chat about what projects you are currently working on.**
+
+*I currently work on multiple projects. In the future, we want to charge for query calls as well; that’s why we’re looking into accurately accumulating query statistics from replicas in a subnet. The challenge here is that the individual replicas are not trustworthy and may report completely wrong numbers!*
+
+*Of course, I’m also involved in current cross-chain activities. My main focus in that domain is currently the switch to a simpler know-your-token (KYT) mechanism for ckBTC. The new mechanism will result in lower KYT fees and reduce the risk of “false positives” where bitcoins get quarantined because of (overly) restrictive KYT rules.*
+
+*I’m also working on exposing recent Bitcoin blocks through the Bitcoin canister, which will help all projects that require more information about the Bitcoin blockchain state than balances and unspent outputs. This includes all projects that work with meta protocols such as Ordinals, BRC-20, and so on.*
+
+**Those are all exciting initiatives! We're excited to see each of those projects complete and available for our developers to use. Looking at the ICP roadmap, are there any other items from your team you are excited about?**
+
+*As far as the cross-chain team is concerned, I’m excited about all the work items that will make our Bitcoin integration more useful and accessible to developers. I also hope that our work on chain-key tokens will help grow our DeFi ecosystem.*
+
+*The SDK team has many cool roadmap items as well, which will help improve developer experience. For example, the work to provide more actionable information to developers, such as well-defined error codes and backtraces, is important to write correct canister code. I also like the `dfx` extensions feature as it makes it possible to reduce `dfx` to its core functionality while providing a flexible mechanism to integrate additional (DFINITY-made or third-party) functionality into `dfx`.*
+
+**What about roadmap items from other teams—are there any you're keeping an eye on?**
+
+*I’m excited about all features that bring substantial enhancements to the Internet Computer across all layers. For example, starting at the networking layer, I think having a synchronous message submission endpoint will be a nice feature for developers. Improving throughput on the consensus layer by only including hashes in blocks instead of large payloads is another roadmap item that I think will help the Internet Computer significantly, in particular once we start to see larger loads on the subnets. The roadmap item to support multiple terabytes of replicated storage is important for canisters that require a large state, for example, a canister that stores the full Bitcoin blockchain, a feature that has been requested numerous times!*
+
+**What advice would you give a new developer getting started on ICP?**
+
+*The Internet Computer has so many unique features, like HTTPS outcalls, code that can execute on a timer, whole frontends being served by canisters, and many more. I would advise a new developer to try out whatever feature he or she finds most interesting. Luckily, we have great documentation now, which should help anybody get started quickly!*
+
+**Are there any community projects or tools that you’ve been using recently?**
+
+*I don’t use any community project that is directly related to things that I’m working on. However, I do use some community tools for work, for example, OpenChat, and I try out various community projects privately. I think it’s definitely worthwhile to check out what our community is building.*
+
+**To wrap things up, what’s your favorite thing about ICP?**
+
+*I've used the word “unique” several times before, but its many unique features set the Internet Computer far apart from virtually any other blockchain project. My favorite thing about the Internet Computer is that it has the necessary features to build decentralized applications that can have a substantial impact in the real world.*
+
+**Thanks again, Thomas, for chatting with us and providing such great insight into several projects, especially the Bitcoin integration and cross-chain team initiatives! Be sure to tune in next time for another individual spotlight interview!**

docs/developer-docs/backend/rust/counter.mdx

@@ -49,55 +49,54 @@ Now that you have the files in place for your Rust dapp, you can replace the tem
 To replace the default dapp, open the template `src/rust_counter_backend/src/lib.rs` file in a text editor and delete the existing content. Then, copy and paste this code into the file:
 
 ```rust title="src/rust_counter_backend/src/lib.rs"
-use std::cell::RefCell;
 use candid::types::number::Nat;
+use ic_cdk::{query, update};
+use std::cell::RefCell;
 
 thread_local! {
-    static COUNTER: RefCell<Nat> = RefCell::new(Nat::from(0));
+    static COUNTER: RefCell<Nat> = RefCell::new(Nat::from(0 as u32));
 }
 
 /// Get the value of the counter.
-#[ic_cdk_macros::query]
+#[query]
 fn get() -> Nat {
-    COUNTER.with(|counter| (*counter.borrow()).clone())
+    COUNTER.with(|counter| counter.borrow().clone())
 }
 
 /// Set the value of the counter.
-#[ic_cdk_macros::update]
+#[update]
 fn set(n: Nat) {
-    // COUNTER.replace(n);  // requires #![feature(local_key_cell_methods)]
-    COUNTER.with(|count| *count.borrow_mut() = n);
+    COUNTER.with(|counter| *counter.borrow_mut() = n);
 }
 
-/// Increment the value of the counter.
-#[ic_cdk_macros::update]
+#[update]
 fn increment() {
-    COUNTER.with(|counter| *counter.borrow_mut() += 1);
+    COUNTER.with(|counter| *counter.borrow_mut() += 1 as u32);
 }
 
 #[cfg(test)]
 mod tests {
-    use super::*;
-
-    #[test]
-    fn test_get_set() {
-        let expected = Nat::from(42);
-        set(expected.clone());
-        assert_eq!(get(), expected);
-    }
-
-    #[test]
-    fn test_init() {
-        assert_eq!(get(), Nat::from(0));
-    }
-
-    #[test]
-    fn test_inc() {
-        for i in 1..10 {
-            inc();
-            assert_eq!(get(), Nat::from(i));
-        }
-    }
+    use super::*;
+
+    #[test]
+    fn test_get_set() {
+        let expected = Nat::from(42 as u32);
+        set(expected.clone());
+        assert_eq!(get(), expected);
+    }
+
+    #[test]
+    fn test_init() {
+        assert_eq!(get(), Nat::from(0 as u32));
+    }
+
+    #[test]
+    fn test_inc() {
+        for i in 1..10 {
+            increment();
+            assert_eq!(get(), Nat::from(i as u32));
+        }
+    }
 }
 ```
 
@@ -137,8 +136,8 @@ edition = "2021"
 crate-type = ["cdylib"]
 
 [dependencies]
-candid = "0.8.2"
-ic-cdk = "0.7.0"
+candid = "0.10"
+ic-cdk = "0.13"
 serde = { version = "1.0", features = ["derive"] }
 ic-cdk-macros = "0.8.0"
 ```

docs/developer-docs/backend/rust/intercanister.mdx

@@ -83,7 +83,7 @@ async fn publish(counter: Counter) {
 }
 ```
 
-In this code, you can see two inter-canister update calls: `fn subscribe(subscriber: Subscriber)` and `async fn publish(counter: Counter)`. The first method allows for the publisher canister to make a call to the subscriber canister and subscribe to topics. The second method allows the publisher canister to publish information on a topic in the subscriber canister.
+In this code, you can see two inter-canister update calls: `fn subscribe(subscriber: Subscriber)` and `async fn publish(counter: Counter)`. The first method allows for the subscriber canister to make a call to the publisher canister and subscribe to topics. The second method allows the publisher canister to publish information on a topic in the subscriber canister.
 
 ```rust title="src/subscriber/src/lib.rs"
 use candid::{CandidType, Principal};
@@ -154,7 +154,7 @@ dfx deploy
 First, let's subscribe to a topic. For example, to subscribe to the "Apples" topic, use the command:
 
 ```bash
-dfx canister call subscriber init '("Apples")'
+dfx canister call subscriber setup_subscribe '(principal "<INSERT_PUBLISHER_PRINCIPAL_HERE>", "Apples")'
 ```
 
 Then, to publish a record to the "Apples" topic, use the command:
@@ -166,11 +166,11 @@ dfx canister call publisher publish '(record { "topic" = "Apples"; "value" = 2 }
 Then, you can query and receive the subscription record value with the command:
 
 ```bash
-dfx canister call subscriber getCount
+dfx canister call subscriber get_count
 ```
 
 The output should resemble the following:
 
 ```bash
-(2 : nat)
-```
+(2 : nat64)
+```