Using NnsCanisterUpgrade Proposal types

Of course you can push back :slight_smile: I think we don’t have a super clear view here as an NNS community how we want to go about this.

I think we agree on many points! I just wanted to bring up topics like “NNS fatigue” (I like this term btw :slight_smile: ) and also potential added complexity as issues. In my view, these aspects are often neglected and I just try to spread the awareness that we should think about them very well before adding more complexity and “responsibility to NNS users” - to make sure we don’t put things under NNS control just due to the lack of discussion of alternatives.

For a few applications that are for example niche and very relevant to some communities but not to others, it might for example also make sense to have new specialized DAOs or think about even other forms of governance / control. I totally get that we want to inherit the security of the NNS - but this security is only as good as the users behind the voting power being able to keep up with making good choices. What I mean: if in the extreme case there is one dapp that is just understood by one person and all users “have to” follow this one person even if it is not trusted (because no one else cares or knows about this dapp) - this is not much more secure than this person directly controlling the dapp. In this case, a lot of neurons might blindly follow this one person or choose to always vote no and then this application cannot actually be upgraded using the NNS. I know this is an extreme case, but I just use it as illustration.

That being said, I also see that we as an NNS community might still decide that other things should be added under NNS control - and probably for good reasons.
I really just want to advocate to have these conversations.
Maybe a solution is also to just having to “ask the NNS community for permission” when adding a canister to its responsibility (similarly to how one has to register a dapp in the SNS).