Non-revokable APIs

[Steve]

From the FAQ - “…share their user data and functionality with other internet services using permanent APIs that can never be revoked, eliminating “platform risk”…”

I’ve been tinkering around a bit, but where does this actually come into play? At least on my local instance (which might be the explanation) I can blow away all methods in my canister. When I deploy to the tungsten network, does it verify I’m not removing any APIs during upgrades?

[bengo]

@Steve That’s a great question. I just asked around, and it sounds like there will be a feature where the original canister author can basically abdicate their ownership over it, making it uncontrolled by anyone, and preventing future deploys that might change its behavior. You may hear this referred to as unsetting the canister’s ‘controller’. It’s not live yet, but someone’s working on it targeting the Sodium launch on September 30, 2020.

[Steve]

Thanks for the explanation, that actually sounds really neat. Sounds like teams could work on a project, iteratively build out features and then “lock” the project. Awesome!

[jzxchiang]

Is this feature ready to use yet?

[nomeata]

You can set a canitsers controllers to something non-existant (e.g. `aaaaa-aa) or – since Interface spec version 0.18 – to the empty set. Then canister code cannot be changed anymore. A first step towards fully immutable canisters.

[dave]

@nomeata, why only a first step? Combined with being able to confirm the module_hash, isn’t this then pretty comprehensive, or am I missing something?

[nomeata]

It’s in a way complete, but I think you might want to consider additional steps:

• only the controller can read the cycle balance via aaaa-aa.canister_status(). So if you have no controller anymore, you probably want the app to report its cycle balance somehow so that you (or other donors) can top it up if necessary.

• unless you are 100% sure that your canister is not buggy and never needs a code fix, you probably want to have some governance system in place.

[flyq]

@nomeata

unless you are 100% sure that your canister is not buggy and never needs a code fix, you probably want to have some governance system in place.

It may also need a DAO canister as the controller, and a group of people to manage the application canister. For complex applications, it is too difficult to have no bugs at all

[flyq]

@nomeata

non-existant (e.g. `aaaaa-aa)

I have some questions about canister id aaaaa-aa.

1. Its generation method is different from other canisters. Is it done to reflect its special status? Does it have more different functions than nns canister?

dfinity/ic/blob/master/rs/types/base_types/src/canister_id.rs#L35-L37

dfinity/ic/blob/master/rs/nns/constants/src/lib.rs#L19-L27

2. The ic-mangement deployed on this canister, but unlike other most nns canisters, I can’t get the source code from ic, so it will be open source? Or it is just a “virtual” canister. In fact, its methods are built into the Internet Computer platform.

[nomeata]

@flyq

Or it is just a “virtual” canister. In fact, its methods are built into the Internet Computer platform.

Exactly. To quote the section on the management canister from the Interface Specification:

The IC management canister is just a facade; it does not actually exist as a canister (with isolated state, Wasm code, etc.).

[ComputerInternetMan]

“Virtual canisters”!
Got fractals?