"Wapps" aka fully owned canisters

Samer · January 28, 2024, 10:50pm

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

A single canister that serves its own frontend is preferable for simplicity
The only controlling principals of the canister should be solely owned by the user.
The user needs to be able to charge their canister via the frontend with cycles.
The user needs to be able to upgrade their canister
Canister creation should be user friendly and not require technical knowledge.

Possible solutions

The canister needs to serve its own certified frontend assets via query http_request to provide a UI for the canister in the browser.
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.

This one is trivial and possible through the frontend UI and the canister backend itself.
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.
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

icpp · January 30, 2024, 2:45am

Interesting!
Is it available in a github repo?

And how would I store and retrieve data?

Kjae · January 30, 2024, 4:03am

Is this Account Abstraction?

Kjae · January 30, 2024, 4:14am

Are kubernetes allowed?

Samer · January 31, 2024, 11:17am

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

Samer · January 31, 2024, 11:22am

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.

Samer · February 22, 2024, 10:02am

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.

Samer · February 22, 2024, 10:13am

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.

Severin · February 22, 2024, 10:29am

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

Samer · February 22, 2024, 10:36am

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

Samer · February 22, 2024, 12:52pm

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

Samer · March 1, 2024, 6:51pm

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?

Samer · April 1, 2024, 10:30am

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

dfisher · April 2, 2024, 7:13am

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.

Samer · April 2, 2024, 2:25pm

Full ownership and verifiable onchain AI.

Only on IC!

cryptoschindler · April 22, 2024, 7:17am

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

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

Samer · April 22, 2024, 8:48am

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

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

cryptoschindler · April 22, 2024, 9:27am

github.com

letmejustputthishere/icrc7_launchpad/blob/main/backend/factory.mo

import Ic "ic:aaaaa-aa";
import Icp "canister:icp_ledger";
import Cmc "canister:cmc";
import Cycles "mo:base/ExperimentalCycles";
import IcpLedger "canister:icp_ledger";
import Principal "mo:base/Principal";
import { principalToSubaccount; accountIdentifier } "mo:account-identifier";
import Result "mo:base/Result";
import Nat64 "mo:base/Nat64";
import Blob "mo:base/Blob";
import Error "mo:base/Error";
import Types "types";

module Factory {

	public func installCode(args : Types.install_code_args) : async () {
		let canisterId = await Ic.install_code(args);
	};

	public func updateControllers(controllers : [Principal], canisterId : Principal) : async () {

This file has been truncated. show original

Samer · April 22, 2024, 1:27pm

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.

cryptoschindler · April 23, 2024, 6:14am

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

Topic		Replies	Views
Non-revokable APIs Developers	10	1258	June 10, 2021
A standard for user owned data canisters? Education	9	1137	May 11, 2022
Feature Request: Provide easier access to canister_status Developers	10	887	October 7, 2022
How to deploy canisters from frontend code to mainnet? Developers	2	546	September 29, 2021
Proposal of Personal Canister Framework on IC: EGO Developers Discussing , community-consideration	3	1237	February 7, 2023