"Wapps" aka fully owned canisters

A concept that deserves more attention is that of the canister that is fully owned by the user.

In this post I want to open the discussion around “user friendly fully owned canisters” (perhaps UFFOCs or FOCs), their security risks and implementation strategies. I will also share some achievements so far with my little pet project web3disk.app

Problem

Enabling the end user to create, own and fully control a single canister assuming the user only wants to use a frontend in a browser and II authentication.

Currently, fully owning a canister requires technical knowledge and isn’t straight forward from only a frontend in a browser.

Full ownership risks

If the canister serves its own frontend and is only controlled by an II principal, then the domain at which the canister is accessed is a central point of failure. Furthermore, if the frontend breaks or isn’t accessible for whatever reason, access and control of the canister is lost.

Challenges

  1. A single canister that serves its own frontend is preferable for simplicity

  2. The only controlling principals of the canister should be solely owned by the user.

  3. The user needs to be able to charge their canister via the frontend with cycles.

  4. The user needs to be able to upgrade their canister

  5. Canister creation should be user friendly and not require technical knowledge.

Possible solutions

  1. The canister needs to serve its own certified frontend assets via query http_request to provide a UI for the canister in the browser.

  2. Ownership should be fully controlled by the user and thus the minimal approach is that

  • The canister is controller of itself
  • User II principal at CANISTER_ID.ICPDOMAIN is a controller
  • The user may add their NNS frontend principal as an extra controller under “my canisters”
  • The user can add and remove any controller via the UI

If the user for some reason has issues accessing the canister via its frontend UI, they could use a user friendly service or tool to (temporarily) authenticate to the canister using its domain as the “derivation origin” and perform emergency actions like upgrading their canister.

This off course only works if the user consciously chose beforehand to add this “backup” service to their canister’s “alternative origins” list.

  1. This one is trivial and possible through the frontend UI and the canister backend itself.

  2. This is only possible through the frontend because a canister cannot upgrade itself. Therefore, the frontend needs to fetch an updated wasm from a trusted source and upgrade the canister.
    Since an upgrade either succeeds or fails, the user can’t ‘get stuck’ in the upgrade process and will always be able to reload the frontend, be it from the old version or the new one.

  3. See below

Ownership means responsibility

After canister creation, the user will have full responsibility over the canister, its cycle balance and whatever functionality it offers.

Even if the user used a service or tool to create the canister, the service is not responsible for what the user does with his/her canister.

Implementation

Web3Disk.app is a blockchain storage solution that enables fully owned secure e2e encrypted storage accessed in the browser and controlled by an II.

Anyone can create a Web3Disk and own it in seconds (free of charge) using the Web3Disk Service. A user creates and takes ownership of his/her canister by authenticating to the Web3Disk Service first and then to their own canister by using its domain as the ‘derivation origin’.

The service then grants full ownership to the user. The user then can access and manage their canister at its domain.

This all happens in a easy-to-use UI without any technical knowledge required by the user.

Next steps

Launching an early version for initial feedback.

Implementing vetKey e2e encryption would make web3disk a serious alternative to secure online storage for small data sizes. The focus would be on security and less so on advanced file management and large data features.

Open sourcing. Then technical users could build and deploy their own Web3Disk without using any service.

Looking forward to hear your thoughts!

Canister creation via Web3Disk Service

Fully owned user canister

Minimal frontend deps for robust and reliable frontend

15 Likes

Interesting!
Is it available in a github repo?

And how would I store and retrieve data?

2 Likes

Is this Account Abstraction?

1 Like

Are kubernetes allowed?

It is not open source yet.

Uploading files initially one by one or in batch. I’m, also looking at File System Access API in the longer term for directory sync feature from the browser

No, not really.

Web3Disk is not a wallet or DeFi service of any kind. The storage part is as boring as any other online storage.

The exciting part is that the owner fully owns the Web3Disk storage canister and controls it with an Internet Identity only at its frontend domain in the browser.

2 Likes

The cycles-ledger opens up new possibilities for Fully Owned Canisters.

A service could serve a frontend that enables the user to:

→ Login with II and obtain a principal valid at the service frontend
→ Direct the user to deposit ICP or cycles
→ Create their own canister
→ Install a wasm that also serves certified frontend assets (and most importantly, has the service domain listed in the /.well-known/alternativeOrigins file)

→ And finally, take full ownership of the canister by obtaining a principal through II again, with this time the new canister domain as the derivationOrigin.

This allows the service frontend to update the controllers of the canister to only the user II principal (and the canister itself should also be a controller of itself)

I’m also working out some safety mechanisms to allow the user ownership options ranging from ‘full paranoid mode’ to shared ownership with the service used.

3 Likes

Also, lately I’ve been marketing this as follows:

“Allow users to own a piece of the Internet”

A full User Owned Canister serving its own frontend is like a little piece of software hosted by the Internet and fully owned and managed by user without any technical knowledge, through easy UI.

The asset canister that’s shipped with dfx for example has multiple permission levels defined in user space. You could e.g. only give the user controller rights over the canister and then give some other system some other level of access

1 Like

That is in fact exactly what I was doing with Web3Disk, which was a fork of the assets canister.

There are good reasons for forking the asset canister, one of them being permissions built in, the other being certified assets and batch uploading system.

But it does make the project heavy because of the whole sdk repo as a dependency (custom build of the asset canister)

I’m slowly moving towards an NPM lib and Rust crate that have all you need to develop a FOC service

2 Likes

Canister wallets, another name for fully owned canister or wapp is a clear rrend on IC

4 Likes

If the idea of Wapps / Fully Owned Canisters / NFID Vaults catches on, it could 10.000x IC usage very quickly.

Perhaps it could be marketed as “owning a piece of the internet”

What do you think?

3 Likes

Update:

The initial setup for this project included a backend service provided by me. This was a solution to create a canister for the user before granting ownership.

With the new cycles ledger, the process of creating a canister on behalf of the user can be improved. The user now only needs to rely on a frontend that creates, manages and grants ownership to the created canisters.

No developer service required

Also, Web3Disk depended on the certified asset canister and had to pull in the whole dfinity sdk repo. This will be deprecated as well, making the project more light weight.

The project is also moving away from the specific use case of file storage to a more general framework of user owned canisters.

Currently Im thinking of a NPM package and Rust crate that together provide everything you need to develop services that could be installed and owned by the user

3 Likes

Sameer, this is the future. Thanks for your efforts.

Canister wallets are more convenient, offer better security, and will be the majority of all wallets in the future.

2 Likes

Full ownership and verifiable onchain AI.

Only on IC!

1 Like

If you serve the service interface from a canister anyways, you can achieve your functionality without the cycles ledger as well. You can seen an example of a canister factory that creates user owned canisters on demand here.

To my understanding in your scenario the service frontend canister would need to list the newly spun up user canister as an alternativ origin, not the other way around. It also seems like there is a limit of 10 alternative origins and a number of other caveats in the the spec. But maybe @frederikrothenberger can share his thoughts on this approach.

You could maybe

  1. log into the service interface with II to create a new canister owned by that principal
  2. log into the user owned canister with II, copy the principal
  3. through the service interface, transfer ownership to the principal from step 2.

Correct. There are several ways now including sending ICP to CMC and then notify_create_canister.

I could not immediately find the code that spawns canisters in that starter example. Can you give a more specific link?

Nice starter btw! The stack of the future :slight_smile:

Correct. The ability to set an alternative origin allows one to manage their canister from another frontend domain. This might be important in case the frontend breaks for whatever reason.

Security
It’s important to consider the risks when creating canisters for the user that serve their own frontend. The icp0.io domain is a central point of failure for instance.

Several security policies can be implemented ranging from ‘super paranoia mode’ to ‘I trust the developer more than I trust myself’.

In any case, the user should be well informed about these possibilities

1 Like
1 Like

Yes, this is possible, but it also means:

  • Its a bit less user friendly because the user needs to copy and paste a principal
  • A (possibly irrevocable) error can be introduced if the user accidently pastes another principle.

Maybe you can come up with a more user-friendly flow :thinking: Like scanning a QR code or smth