Should SNS controlled ICP neurons be public by default?

While adding some features to the toolkit so that SNSes can manage neurons from other SNSes through proposals I ended up in a discussion to do the something similar for ICP neurons, while exploring the possibilities in ran into the following issue;

In relation to SNS neurons, ICP neurons are not public by default and can only be fetched based on the caller. Because the SNS governance canister is be the owner of these neurons it’s not possible to retrieve them.

There was an big discussion going on regarding public ICP neurons but i didn’t spot any mention of SNSes that own ICP neurons. For sake of transparency I would expect that these SNS controlled ICP neurons are public.

Did notice that @GOLDDAO :1st_place_medal: has a custom implementation for this by creating a canister that also holds references to their ICP neurons (creating semi-transparency themselves).

If i’m off with my findings, please correct me, if not, I think the least invasive approach to make this happen is by adding a call to the SNS governance canister that fetches the neurons from the NNS governance canister by caller.

1 Like

If the SNS governance canister is the controller or hotkey for the NNS neuron, the neuron information should already be exposed to it, shouldn’t it?

Perhaps you could facilitate (using your Toolkit) a generic nervous system function that queries the NNS governance cansiter for these neurons (making the information ‘public’ to that SNS, which can use that information however it needs to).

I think the functionality you’re after may be something that the Toolkit could implement. What do you think?

Longer term, with the public neuron index, I guess this will be less necessary.

1 Like

I’m not sure if the generic_nervous_system_function to query the NNS governance canister would work in this scenerio, but might need to dive a little deeper.

Regarding the quote from @bjoern, i guess that would solve it if both public and private neurons are fetch-able by controller or hotkey passed in as an argument.

1 Like

I guess because generic_nervous_system_functions can only be executed via proposal? That makes sense. I think I was having a bit of a brain fart, imagining that an SNS governance canister could be prompted to execute a generic_nervous_system_function without using a proposal (which would defeat the point of the DAO :sweat_smile:).

My understanding is that you’d like to be able to programmatically detect the NNS neurons owned by the governance canister in order to display them in the Toolkit UI?

For the time-being at least, if you’re an SNS user and you’d like to raise a proposal to manage an NNS neuron owned (or hotkeyed) by the SNS governance canister, as long as you know the NNS neuron ID then you should be fine (it just means the UI won’t be able to display the neuron to you up front). If the NNS neuron in question is made a known neuron (particularly with a naming convention), then this shouldn’t be too difficult to manage from a user perspective, but I understand you want to make the UX as smooth as possible.

If I’m understanding this suggestion, I think it is technically possible to add a list_nns_neurons method to SNS governance. Not sure what actual problem that solves. In other words, this might be a YAGNI feature.

list_nns_neurons would not actually force an SNS to make its neurons public, because an SNS can do what GOLDDAO did: they can create another canister to be the controller of their NNS neurons. Then, list_nns_neurons would return nothing.

At the same time, SNSs that actually want to make their neurons public can do that already without adding list_nns_neurons to SNS governance. One option is for the SNS to set the visibility of its NNS neurons to Public.