"Wapps" aka fully owned canisters

Showcase
21

The current flow is to use II auth at an alternative origin. This solves both challenges mentioned above

22

Maybe I’m misunderstanding you but afaik you cannot use unlimited alternative origins at your service frontend canister, so how would that work? I don’t think you’re able to set the alternative origin on the “wapp” canister, only the other way around.

1 Like
23

As I understand, (and have implemented and tested in the current setup) the ‘wapp canister’ or in this case the Web3Disk that is spawned for each user, should have an alternativeOrigin listed in its /.well-known/alternativeOrigins

That alternative origin could be the spawning service and indeed up to 10 entries.

I was thinking of having these alternative origins listed:
spawning_service.com domain
spawining_canister_id.icp0.io
user_added_domain.com backup domain added by user
user_added_alternative_canister_id.icp0.io backup domain added by user

Then at any of these alternative domains, we could authClient.login with derivationOrigin set to the user owned ‘wapp’ canister at user_owned_canister_id.icp0.io

The alternative origins can be set by the user. If for any reason the user can’t acces his user owned canister at user_owned_canister_id.icp0.io they could use another origin from which they can manage and possibly reinstall their canister wasm.

The user only needs to auth with II. Never copy a principal. In fact never even see their principle.

1 Like
24

Then you can derive the same Principal from the wapp canister on the service canister, but not the other way around. So how would that flow look like if you first need to sign into the service canister with II to be able to spawn the wapp canister in the first place?

25

You create another instance of authClient with custom storage.

After the principal is obtained and used by the spawning service, we drop the principal from browser storage.

26

I’ve been working on a similar idea. I think IC is a great concept for small applications that can be completely owned by the user and require minimal storage and processing on the server side.

A big problem with crypto applications does always seem to be recovery. I wonder if some kind of DAO could be established that uses multisig keys to provide a knowledgeable recovery option for these types of containers, so no single individual has superuser capability over the canister but you could request a restore from several if necessary.

I like to think of it like notaries in the USA. Trusted individuals that buy into the system to provide the service of proof of identity in exceptional cases.

1 Like
27

I agree. And a DAO may be able to solve some of the issues related to canister recovery if there is a community to support it. A more simple intermediate solution may also be a ‘blackholed’ canister that is publicly known.

Consider these recovery related problems:

  1. A user spawned a canister and forgot their canister id and thus the URL at which to access it
  2. A user wants to use a (stand alone) frontend that spawns canisters without storing any info about the canister creation event.

Both could be solved with a publicly known blackholed registry canister.

  1. During canister creation, the user may choose to register their canister id with the blackholed registry. The blackhole will only reveal this canister id to the owner after auth with II.

  2. This is subtle but there exists a time window where the canister is created with user principal at spawning domain, but not fully owned by user principal at new canister domain. To take full ownership of a canister with II at its own icp0.io domain, one must know the canister id in advance, thus the canister needs to exist. If for whatever reason, the creation process is interrupted after canister creation and before full ownership, the user may loose ICP / cycles and not able to recover the freshly spawned canister. The spawning application must then rely on browser storage to temporarily remember this new canister, which we want to avoid. A blackholed registry can solve this.

Another solution to this might be a fresh empty canister buffer in the blackholed registry. Each new user could immediately take ownership of a pre existing canister owned by the blackholed registry. The user will also cover the creation fee to fill the canister buffer with a new canister plus a small fee to keep the blackhole funded.

1 Like