Skip to content

Update application-architectures.mdx #5567

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Update application-architectures.mdx #5567

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 4 additions & 4 deletions docs/building-apps/best-practices/application-architectures.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -45,8 +45,8 @@ This architecture is based on the vision that Web3 users should have full contro
The idea is to create a canister per user and make the user the controller of their canister.
The main canister of the application would then orchestrate user canisters to implement the application’s functionality.
Since users are controllers of their canisters, they can install their own code, decide how to participate in the application, and determine what data to share.
These user benefits come at large development costs because the main canister needs to be programmed in such a way that it can handle all possible actions of potentially malicious user canisters.
Still without a package manager for creating such software easily, these user benefits come at large development costs because the main canister needs to be programmed in such a way that it can handle all possible actions of potentially malicious user canisters.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Still without a package manager for creating such software easily, these user benefits come at large development costs because the main canister needs to be programmed in such a way that it can handle all possible actions of potentially malicious user canisters.
Without using a package manager for creating such software easily, these user benefits come at large development costs because the main canister needs to be programmed in such a way that it can handle all possible actions of potentially malicious user canisters.

This is a new and unprecedented way of programming.
**There hasn’t been a successful implementation of this vision yet.**
A couple of projects that opted for this architecture, but only [NFID Vaults](https://nfidvaults.com) have given the ownership of canisters to the users.
A common misconception is that the canister-per-user architecture is the most scalable; actually, canister-per-subnet is more performant because it can utilize multiple subnets without having the overhead of too many canisters.
It is being implemented in [IC Pack package manager](https://docs.package-manager.com/) (the MVP is expected soon) - the software that allows to do canister-per-user architecture easily, making the user self-sovereig over their software.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
It is being implemented in [IC Pack package manager](https://docs.package-manager.com/) (the MVP is expected soon) - the software that allows to do canister-per-user architecture easily, making the user self-sovereig over their software.
One example is the [IC Pack package manager](https://docs.package-manager.com/) (MVP coming soon), which can be used to create a canister-per-user architecture.

A couple of projects that opted for this architecture by themselves (without using an universal package manager), but only [NFID Vaults](https://nfidvaults.com) have given the ownership of canisters to the users.
A common misconception is that the canister-per-user architecture is the most scalable; actually, canister-per-subnet is more performant because it can utilize multiple subnets without having the overhead of too many canisters.