Is your feature request related to a problem? Please describe.
Currently there are parameters of applications which are only available at initialization. The parameters may sometimes need to be reset, but it is currently impossible. For example it might be reasonable for an organization to adopt a new vault or switch a vault to the agent app, and then they might want to migrate their existing finance app to the new vault/agent instances rather than deploying a new finance app.
Describe the solution you'd like
I would like to be able to re-initialize an application.
Describe alternatives you've considered
Making each parameter that is included in the initialization process also able to be set by a separate privileged function.
Additional context
One of the arguments for having some parameters set only at initialization is that they are sensitive and should always be immutable. If there are legitimate security issues with changing these parameters after initialization, then the re-initialization process can be assigned a role and have that role discarded.
One of the arguments for having some parameters set only at initialization is that they are sensitive and should always be immutable. If there are legitimate security issues with changing these parameters after initialization, then the re-initialization process can be assigned a role and have that role discarded.
We have certainly taken that security stance and offloaded some of the parameters to their own privileged functions.
The easiest path forward would be to expose more privileged functionality to change currently immutable state in the apps (e.g. the vault a Finance app is attached to), but this will present difficulties for frontends. If you switched a Finance app's vault, almost all of its prior information is useless for the new vault and we'd have to separate them into a historical view.
Perhaps a different pattern could be "archiving" apps, such that you could revoke and burn all permissions from an app and the UI would show it in a read-only, greyed-out state?
The easiest path forward would be to expose more privileged functionality to change currently immutable state in the apps (e.g. the vault a Finance app is attached to), but this will present difficulties for frontends. If you switched a Finance app's vault, almost all of its prior information is useless for the new vault and we'd have to separate them into a historical view.
I think this is a reasonable justification for an init only function. If this becomes the norm and there is a way to uninstall applications then in the event that you need to make the adjustment it is probably reasonable to install a new instance and uninstall the old instance.
Does make sense to add a new namespace under the kernel for uninstalled apps? And we consider the addresses "blacklisted" from the ACL if they are part of this namespace
May be a wild idea and as far as I understand is a big change 馃槄
@0xGabi Having an uninstalled namespace would be useful if we needed to query this on-chain, but my hunch is that it's unlikely (for the foreseeable future). It makes it a little bit easier for the frontend to reduce this, but I think it should be pretty easy to add in removals without any contract changes.
Going to close this, since it's unlikely we'll be supporting reinitializations and instead work towards being able to uninstall/reinstall applications.