NNS Governance canister feature request: list_neurons by subaccount

Currently the NNS Governance canister has an endpoint called list_neurons, in Motoko it’s type is represented like this:

  public type ListNeurons = {
    include_public_neurons_in_full_neurons : ?Bool;
    neuron_ids : [Nat64];
    include_empty_neurons_readable_by_caller : ?Bool;
    include_neurons_readable_by_caller : Bool;
  };

This only allows fetching neurons by their Nat64 Neuron ID’s - not their subaccount. This is the only neuron fetching endpoint that doesn’t allow searching neurons by subaccount. For instance there are endpoints:

get_full_neuron_by_id_or_subaccount
get_neuron_info_by_id_or_subaccount

and even the manage_neuron neuron endpoint allows you to call a neuron by it’s subaccount:

  public type ManageNeuron = {
    id : ?NeuronId;
    command : ?Command;
    neuron_id_or_subaccount : ?NeuronIdOrSubaccount;
  };

So there is a clear discrepancy here between all other neuron endpoints and list_neurons.

A new endpoint can be exposed called list_neurons_by_id_or_subaccount similar to the ones mentioned above.

@daniel-wong

Edit: The benefits of adding this are: Consistency across the NNS Governance endpoints and also this would allow much quicker lookups of particular neurons in canisters if you know your neurons nonce’s (which you can then compute your subaccount with).

This seems reasonable.

I’m not sure how much priority this should receive though. As you said, there are already ways to get information about a neuron if all you have is its subaccount (not neuron ID). Therefore, it seems to me that this isn’t a very important feature?

Hi Daniel, thanks for responding.

Ye that’s true but only for one neuron at a time, which isn’t very efficient.

Well, it’s important to me that’s why I requested it. It would save me memory and instructions by not having to work with the Neuron ID’s for one endpoint and the subaccount for others - so for consistency I think it’s important.

By the way, working with the subaccounts is much easier (in canisters), as you can compute those yourself, whereas the Neuron ID looks like it’s just a random number, so you have to query it.

@lara is ooo right now, but let me tag her so she sees this later.

1 Like

Is the controller or hotkey of your neurons the caller? Can you give a us a better idea of your use case? TBH, this probably is not going to be a priority for us, unless we can figure out how this solves a big pain for many apps. FWIW, this is a sensible feature. The problem is that our resources are finite, you know?

Maybe we can get the lads at Dfinity to look at this again, there seems to be time to look at ListNeurons now: