SNS Generic Nervous System Function Restrictions

[wpb]

Cross posting here for visibility since @Lorimer continues to push this idea.
I am still opposed to the idea for the reasons stated below and in the original post.

@wpb

@Lorimer

DFINITY has proposed introducing a native nervous system function that should soon allow an SNS proposal to execute manage_neuron on its own governance canister).

Hey @lara will you please offer clarification on what you actually said on this topic? @Lorimer has claimed multiple times and in multiple chats that you explicitly said that DFINITY will implement his request for a manage_sns_controlled_neuron method. I don’t believe you actually said that, but he has interpreted it that way and has moved on to expanding the concept to the NNS. His design philosophy regarding all the D-QUORUM neurons that he plans to create center around DFINITY implementing this kind of method. Your full quote is below and you were providing a conceptual response to his leading question. You also indicate clearly in that post that you recommend he pursue the canister controlled neuron version of the options.

@lara

Hi @Lorimer thanks for breaking it down again.

if an SNS finds itself in possession of a neuron of its own token type (possessed by the governance canister), what options does the SNS DAO have for controlling and managing it?

These are the best two options that I see:

1. Extend the SNS governance canister to have a built-in proposal to do this.
2. Have a new canister control the neuron which is in turn controlled by SNS governance. The neuron can then also only be modified and managed by DAO proposals, possibly applying extra rules in the canister

Note that we will not have capacities to work on the first solution in the near future. So if you are looking for a faster solution, I would encourage you to consider the second option.

This conversation between you and Alex occurred before anyone expressed any opposition to the idea of an SNS governance canister controlling a neuron in it’s own SNS. You final remark to date in that thread (quoted below) is confirmation that he should pursue the canister controlled neuron route and that it is not clear that Alex’s preferred method should be implemented at all.

@lara

As there is some way to achieve what you would like to do (using an extra canister) and as there seem to be different opinions on whether this should be done at all, how about we take up this discussion again in the end of winter?
We could then take more time to discuss the pros / cons, also including new information that we learned from new features such as the named neurons.

I think Alex is going to continue to claim that you came up with the idea of manage_sns_contorlled_neuron method unless you offer clarification otherwise. I would actually like to know myself if he is right because it is predictable how it would change NNS and SNS governance. There is no sense in engaging in governance with independent known neurons if in the future the nervous system will directly control neurons within it’s own nervous system. I would rather not waste my time now if this is our future.

Clarification: In case it is not obvious from my comments, I fully agree with the governance framework that exists today that a nervous system can and should be able to control neuron(s) of another nervous system with the one exception that the NNS should not control an SNS neuron. My opposition here is related to a nervous system controlling a neuron within it’s own nervous system.

Below is the response (also linked here) provided by @lara to this concern raised above…

@lara

I think you understood me correctly.

• I was first just providing ideas on how the problem could be solved, mainly arguing why I strongly suggest not to lift the current restrictions on generic proposal (that they cannot target SNS canisters).
• In the end, after some people were for and others against the idea, I proposed that we should revisit this before committing to it.

While these comments were made in a different forum post, they are based on conversations that were held in this forum topic. The history of this conversation can now be found in this thread.