I would like to be able to view a specific non-named neuron’s voting history, but the IC dashboard seems to only hold a “partial” recent voting history.
Is there an API or way that I can go back and query this data?
For example, in the case of deciding whether to follow/trust newer named neurons, it would be nice to go back and view that specific neuron’s voting history prior to the point that it became a named neuron.
This can be shown by looking at @ysyms’s named neuron - I can only see his governance votes right around the time that he became a named neuron, and no sooner.
@Dylan is able to explain exactly how this works, but my understanding is that the last 100 votes are retained for all neurons. This is for all proposals except exchange rate. The moment a neuron becomes a registered neuron the vote history is saved indefinitely.
I would imagine the dashboard could be configured to save this vote history in different ways if requested, but I haven’t tried very hard to put in a request. However, it has been a hardship for me because I track vote history for all voting members of the Synapse neuron and I have to go save the data every couple days to avoid the votes getting lost.
When we get the CrowdGov.org website functional, we will begin saving governance topic vote history for any neuron that users request we save. So hopefully there be multiple ways of solving this problem in the future.
@wpb explained it well. The Governance canister keeps a maximum of 100 recent (non exchange-rate) ballots per neuron. Here is the constant in the code that controls this:
The reason this is so low is because of Governance canister memory considerations.
For known neurons, the IC dashboard back end persists all ballots after the first Register Known Neuron proposal for a neuron is executed. This is done outside of the IC, and anyone can write code to do this, you’d just need to poll Governance periodically for those 100 most recent ballots and save them.
@justmythoughts, I agree that it would be great to see a longer voting history for any neuron, but no one is doing that because it would be a lot of data (number of voting neurons * number of proposals of the types you want to track).
This makes sense - I’m curious though, how many named non-named neurons are there in total currently? @Kyle_Langham do you have access to this data, or an estimate of the # of distinct neurons (or at least voting neurons)that are out there?
The dashboard currently seems to pull this data from ic-api.internetcomputer.org, so is the API for this the dashboard directly powered by the IC, or indirectly power led by the IC in that a job polls the governance canister and then stores this data in a view (the ic-api) houses off of the IC?
I don’t think it’s a terrible thing to have this data stored somewhere off-chain, the most important thing to me is that the data exists somewhere.
HI @justmythoughts. Your first question is about quantity of named neurons… I’m guessing you meant non-named neurons? Unfortunately that data isn’t available and won’t be until DFINITY creates the code for neuron indexing. I do know that neuron indexing is a low priority compared to SNS and NNS upgrades. However, there are known neurons (as in neuron ids known by the dashboard)… that number is 17775 found here: Internet Computer Network Status.
I would love to see some movement by DFINITY to provide developers the ability to easily paginate through all neurons that have been created instead of guessing neuron ids (DFINITY wouldn’t need to store all votes, just make all neurons accessible via this paginated API).
Currently the ic-api.internetcomputer.org is hosted off the IC (via Cloudflare), so if we already have a CDN that’s meant to protect load hitting the main IC canisters, why not just store this data off-chain (with no storage constraints)?
@dsarlis where is the repo for the ic-api code in case developers want to extend this and store the data off-chain?
What actions make a neuron “known” to the dashboard instead of hidden, and is it possible for NNS app/wallet user to create a neuron that is “known” vs. hidden?
One solution here would be to differentiate by proposal type, and then to keep track of the last 1,000 governance proposal votes. If we have 17,775 known neurons, that ends up being on the order of tens to hundreds of MB of data, which can definitely be bumped up - especially if this is stored in stable memory. If a single canister is able to hold more than 8GB of memory in the future, then this shouldn’t be a problem (as long as the IC continues to be successful and there’s more capacity in subnets).
With 1-2 governance proposals per week, we’re talking 50-100 proposals per year, so the last 1,000 governance proposals should fit the use case for a significant amount of time, and this limit could always be bumped up or lower if it runs into issues (like mass IC adoption overnight, for which this same storage limitation would become an issue as well if the IC had hundreds of millions of neurons).
Searching for the neuron id in the dashboard’s search bar makes the neuron “known”. Neuron indexing would make the neuron “known” when it is created by simply adding the new id to a list.
The root cause of the “hidden” neurons is that a neuron id can have up to 15 (?) digits. You can query the governance canister for a neuron id and, if the id exists, you’ll get the neuron info back. The problem is that if you started at id=1 and worked your way up to 15digits, it would take thousands of years to try all those numbers. The dashboard solves this by keeping a list of neuron ids searched for and routinely pulling the neuron data for those ids.
@Dylan Thanks, I was wondering why I couldn’t find the source code anywhere
Is there something technical keeping the ic-api code from being open source? How much, and what type of work would it take to open source it?
Since this API powers the dashboard that we are all using to understand metrics about the NNS and the IC ecosystem, open-sourcing this code would go a long way in ensuring that certain neurons/data aren’t being hidden/manipulated by the API or CDN/infrastructure that API is using to pull data from the IC.
For example, right now I could (**frivolously, not backed up by proof**) make the claim that DFINITY or large seed investors are hiding neurons from the cloudflare cache the API is pulling from, or that the cycles burned/transactions per second statistics are padded by the API.
I meant to reply but it slipped my mind. I’ve shared your feedback with the team. I agree that the ic-api code should ideally be open sourced at some point, but there are no plans to do so at this time.
found here: 
Yes I meant to tag Dylan, sorry!