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:
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).
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?
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.
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?