Hello all,
In short:
This year I started working on My Canister Dapp, a toolchain to develop single canister decentralized applications that are created and controlled by only using Internet Identity.
There’s a FAQ on mycanister.app and a small Hello World Demo. You can install the Hello World and be the sole owner of your Canister Dapp!
Request for comments
Developing canisters that function as both a frontend and a backend is very experimental. Any comments or feedback, help, suggestions are welcome.
Technical challenge: Dapp frontend
Canister Dapps live on the IC and are accessed via canister-id.icp0.io. Therefore, the user relies on a frontend to interact with and manage the canister. The II principal derived at canister-id.icp0.io is the only user-principal controller of the canister.
Therefore, if the frontend breaks for any reason, the user looses control over their canister. Rich frontends are built with advanced frameworks and assume updates are easy to make in case something breaks. To this end, I’m developing a vanilla JS minimal standard dashboard that is meant to be available at all times. A robust and reliable Canister Dashboard should be served to the browser by the canister if all else fails.
More advanced monitoring and management functionality can always be implemented in the ‘main part’ of the frontend.
Technical challenge: Onboard frontend assets
The canister needs to expose the http_request method and serve fronted assets as certified query calls. A big part of this is solved thanks to ic-asset-certification and ic-http-certification crates. To simplify this for Dapp devs, I’m developing my-canister-frontend crate to abstract away a lot of the networking complexities of adding onboard frontend assets to canisters.
Technical challenge: build and deploy pipeline for Canister Dapps
Canister Dapp frontends don’t know their canister id at compile time! A Canister Dapp wasm (with onboard frontend) is installed in a new canister for each new user. The frontend relies on the browser window origin to infer the canister id.
Furthermore, during dev we want to run the Dapp frontend in Vite and talk to a deployed canister on dfx. We also want to run only in dfx as a single canister dapp. The static dashboard frontend assets from my-canister-dashboard crate need to adapt to local dev environment, yet they are published to crates.io and are unaware of the local machine.
And on top of this: A Canister Dapp is deployed in special way, see this small note.
All this requires some tools and configurations that I’m currently fleshing out.
Next steps
Stable base tools
Most importantly is to get to a stable Canister Dashboard that implements cycle top-up rules on top of whats currently done. Second, a Dapp dev should be able to use a simple Rust macro or call one function with a path of their frontend assets and the my-canister-frontend crate should take care of all frontend requirements for the Dapp.
On the dev side
Vite plugin for development
Standard way of building and deploying (maybe cli tool)
create-canister-dapp package for starters
…
Ecosystem:
More examples should be provided.
A awesome-canister-dapps repo with real world examples should be available, perhaps with some applications using vetKD.
…
Docs:
A formal spec
Comprehensive docs
And much more! Maybe even a Dapp Store one day!
Wishing all happy dev days,
Samer
In closing from the FAQ:
Why do we need Canister Dapps?
The Internet Computer is a versatile blockchain that allows for varying degrees of security, user privacy and ownership.
For starters, it’s a publicly governed blockchain with a ‘liquid democracy’. Second, the security and authentication model of the IC together with Internet Identity are ahead of legacy Web2 technology by default, giving users more control over their data and on-chain assets. For example, the ICRC-1 standard uses the IC’s caller authentication model when sending funds. Furthermore, the ecosystem allows for SNS DAOs to give users more guarantees and ownership stake in certain projects.
Despite these advantages, in practice it is still nearly impossible for non-technical users to be in full control of a single canister that runs their app.
Canister Dapps allow non-technical users to create and fully own their decentralized applications. This allows for true decentralized software without any intermediaries.