Inspired by the discussion in this forum thread, I’ve realized the importance of establishing a shared knowledge base collaboratively built by community developers.
Why is this important?
Complexity of Official Documentation:
Currently, the official IC documentation is authoritative, detailed, and highly professional. However, for newcomers, fully reading and understanding this documentation can be quite challenging. The complexity and vastness of IC’s knowledge base often prevent developers from grasping its powerful features, increasing potential pitfalls and ultimately hindering broader adoption.
Scattered Community Discussions:
Questions raised on forums are typically fragmented, repetitive, and dispersed. We lack a central resource that consolidates these questions into a clear, structured guide—from root causes to best practices and solutions. While the official documentation’s “Best Practice” and “Troubleshooting” sections are excellent, their current scope is insufficient.
Need for a Trusted Repository:
The existing awesome-internet-computer repository, though helpful, mostly serves as a project index. We need to refine this further, highlighting core, reliable components validated by community security audits. This approach will help prevent issues similar to what we experienced with SIWB, which, in my view, lacked comprehensive community auditing.
Personal Motivation:
As someone fully committed (totally all-in) to ICP, my goal is to enhance IC’s widespread adoption. This initiative benefits me personally and the broader IC community.
Objectives
To create a clear and comprehensive infrastructure framework for Canister development:
Trusted Third-Party Libraries:
Libraries maintained by the Foundation and community developers.
Critical libraries audited for security by the community. (Reference: Forum thread)
Rapid DApp Development:
Methods for quickly deploying scalable canisters from scratch, covering identity management, cycle control, scalable storage, and cross-subnet interactions.
“Zero to Hero” development series.
Common Security Pitfalls:
Documenting and summarizing typical security issues and how to avoid them.
Community FAQs:
A compilation of common issues encountered by community developers.
How We Can Achieve This
Currently, this effort stems from discussions between me and @marc0olo . I’m uncertain if others are interested in collaborating on this public good, but I genuinely believe this initiative will significantly enhance IC adoption and help existing community projects mitigate risks.
My plan is to open a dedicated discussion thread within 1-2 weeks, starting with an initial draft. I warmly invite community members to collaborate on this series.
Planned Series (Initial Ideas)
Getting Started:
For developers new to IC (but experienced in Rust), highlighting potential issues and recommended tools or crates, such as instruction limits, payload size constraints, HTTP outcall costs, and common pitfalls.
Canister Storage:
Complementing official documentation, this series will focus on building efficient and scalable canister storage tailored to different application scenarios, addressing challenges and presenting best practices.
Exploring system-level canisters such as the Cycle Minting Canister, which many new developers overlook.
Frequently Encountered Issues:
Compilation of recurrent issues faced by community developers and their resolutions.
This is just an initial proposal, and I hope community developers can join in creating and contributing independently to topics of their interest.
Please feel free to discuss your ideas and point out any topics I might have overlooked! @jonas@marc0olo@StefanBerger-DFINIT1@yongsxyz@e274426380
I don’t know this is necessary but while building a multi-chain focus project, I might needed some help on chain fusion, what is the role of ICP in multi-chain infra.
It is very helpful if experience dev can provide some insight where ICP take place on multi-chain infra
Infura’s development of ChainFusion and Multichain, along with the related low-level technical support for the IC, certainly deserves its own dedicated topic. I’ll share my insights on this and summarize them in an article.
I think one big difficulty for entry developers is how to recover data.
I know the Foundation has developed a snapshot system for recovering data.
But what I want to discuss is how to move the old data to the new data structure with modifications to the data structure, and the snapshot system does not solve this problem.
For example, modifying the data structure when it already contains data can result in data loss.
This problem has tested a lot of entry-level developers I’ve encountered.
Hi, this is indeed an issue that many developers encounter.
I believe there are two main approaches to resolve it (both of which I’ve recommended to and successfully implemented for several projects):
Directly modify the existing data structure
Adding new fields: Define them as Option. Whether you’re using Candid or CBOR/bincode serialization, when the old structure is deserialized into the new type, the new fields will default to None, so migration during upgrade is unaffected.
Removing old fields: Simply delete the obsolete fields from the structure. This won’t interfere with deserialization of existing data during upgrade.
Renaming or changing the types of existing fields
The most reliable and convenient way is to transform the old structure into the new one in code:
In post_upgrade, iterate over the old structure and convert each entry to the new format. Note that if your dataset is large (stable memory access > 2 GB) or the transformation is complex, you may hit the instruction limit.
Implement a custom update method that migrates data in batches: write old-structure data into a new structure, then delete the old structure on the next upgrade. (This pattern also works in Motoko.)
Upgrades are always sensitive operations. No matter which method you choose, I strongly recommend taking a canister snapshot first—each canister can hold up to 10 snapshots, and it’s an invaluable safety net.
I’ll include this topic in the Canister Storage series as well. Thanks for the feedback!
I can help contribute to this, as co-founder of Aikin, I developed the first version of Nuance - one of the first applications that was up and running on the IC.
Aikin now develops Nuance & Distrikt - the team at Aikin have many years of experience developing on the IC.
I’m planning to publish the first article in the first week of June. The topic will be: Getting Started with IC Development – What Developers Need to Know When Building a Canister from Scratch and Deploying It to the IC Mainnet.
This article will cover the essential factors to consider when writing Canister code locally and running it on the IC Mainnet, including runtime concerns such as the instruction limit, freezing threshold, and more.
The topic is intentionally broad, with the main goal being to list all the technical aspects developers need to take into account when building a Canister, as well as the potential problems these issues may cause. By addressing all of these, a developer should be able to build a Canister that runs smoothly on the Internet Computer.
I’ll be drafting the article based on my own experience, and contributions are more than welcome!
If you have any topics you’re interested in—whether or not they’re already listed—feel free to discuss them here. Let’s work together to build this into a full series!
