We have been discussing adding a method
is_controller to the system API which would allow a canister to determine if a given principal is a controller of the canister.
During the discussions, we considered a more general API that would allow the canister to fetch the entire list of controllers. However, our internal consensus was that that API is more complex to implement and use and the canister can already get that information, asynchronously, from via the management canister. Furthermore, when this issue came up before,
is_controller was sufficient and no other compelling use cases came up in our discussions.
We’d appreciate any inputs into this discussion from the community.
It could be useful when creating new canisters and wanting to copy the parent controllers to the children. Less awaits are nice.
Since you linked my post, sure for me
is_controller would be suffisant from my point of view. e.g. I can imagine that I could use it in guards. Will the information be available synchronously? i.e. will I be able to use it in
Adding the method to the system API ensures that the method is available synchronously; it should also be callable in a non-replicated execution context so you can do access control in query calls.
Creating canisters happens rather seldomly and passing the controller list even more seldomly. So, although less awaits are nice is it worth the complexity?
Well…I don’t know the complexity…but I see a world where canisters are created and destroyed regularly, and it would be nice if a created canister inherited the controllers of its creator, but this likely much easier to implement at the replica level.
I would like to see something like
self_canister_status so that anything that is added to the canister status is synchronously available by default