I’m implementing the Canister snapshots API in order to facilitate safer delivery of upgrades to the various Personal DAOs deployed to the internet computer.
The snapshot functionality has the potential to streamline the creation of the “Wapps” or “Wallet Apps” that @dominicwilliams has been such a proponent of. To do so, the snapshot functionality would need to be extended to include one feature.
currently, snapshots can only be taken, loaded, and deleted. Is it possible to make it so the wasm module stored within a snapshot can be queried by the same actor(s) authorized to take, load, list and delete that snapshot?
The addition of this feature would allow for ease of propagation of updates across multiple replicas of a single application.
Can you be a bit more explicit about what you want to achieve? Canister controllers can take and load snapshots, but that still means that they will load the snapshot into the canister where the snapshot was originally taken, it does not allow moving state from one canister to another.
If you want to apply the same wasm module update to different canisters (but not the data), then what exactly is the relation to snapshots?
My goal is to be able to query a canister’s wasm module so that I can retrieve it and programmatically install that wasm module to other canisters.
I suppose the functionality I’m looking for doesn’t have to bare any relation to the canister snapshot functionality. I just imagined that since the canister snapshot functionality already captures the wasm module of a canister that it may be easier to add the ability to query the wasm module to the snapshot function.
Nevertheless, the feature i need is the ability to query wasm modules. That’s what’s most important
Well, I guess the difference is that if it were integrated with the canister snapshot feature, the expected semantics would be that one retrieves the wasm module in that snapshot, whereas outside of the module one may expect to get the wasm module that is currently installed.
Note that the hash of the wasm module is already exposed through the canister_info API method and the subnet state tree. So if you expose the canister module in some other way – such as on the application layer – then verification of integrity can be achieved easily. You can also use the canister’s chunk store to store the wasm module, including installation on other canisters by specifying a store_canister in when installing the module.