It would be beneficial if you would change what you are currently calling Public neurons. Most of them are known to not cast public votes on specific proposal types and many of them are not even Public neurons today. The fact that you represent all neurons IDs that you know today as Public neurons is very misleading. Below are some examples…
-
You are currently including Adnan - MonkeyCruise (@Monkeycruise), Steve Erickson (@EasySteve), The ICP Maximalist (@icpmaximalist), LightningLad (@LightningLad91), Christian Muller (@christian), Brian Galler (@BrianGaller) in the Public Neurons list because they were all prior voting members for the Synapse neuron and we list their neuron IDs and bio on our Wall of Fame section on our website out of respect for their prior contributions to our known neuron. They do not make any attempt to publicly disclose or promote themselves as a Followee for any proposal topics. Hence, it is not clear why you would want to include them in your list of Public neurons unless they explicitly tell you that they would like to be represented as a Public neuron for specific proposal topics.
-
Similar to point 1 above, you are listing Nathan McGrath and Icdev2dev, and me (Wenzel Bartlett) because we are members of the CodeGov team. However, it is clearly stated in the Neuron section of our website that we are not voting members for the CodeGov neuron for the Replica Version Management proposal topic. We were Followees in the past, but we were also removed a while ago because we no longer actively participate in reviews and voting for these proposal topics.
-
You are showing two different votes cast on every proposal for people identified as Zane and John Wiegley in your Vote History timeline. This is because they each use two different neurons IDs in their participation on the Synapse and the CodeGov teams. One is used for voting on Governance and SNS proposals for the Synapse neuron and the other is for voting on Replica Version Management proposals for the CodeGov team. They believe it is important to use separate neuron IDs for their participation in these groups, which is their prerogative. Neither of them has ever committed to using both neuron IDs to vote on all proposal types, yet you are treating all Public neurons as equally engaged in voting on all proposal types.
-
In fact, nobody in the Public neuron list that you have identified based on their participation with Synapse and CodeGov has ever committed to voting on all proposal topics. Yet you present their votes as though they are Public neurons for every proposal. They have only committed to vote on specific proposal topics and only for the duration when they are still Followees of the known neurons. These Followee neurons are for governance participation only. This was done for privacy and is modeled after the precedent set by DFINITY, ICA, ICDevs, and CycleDAO (prior to renaming Arthur’s Neuron) at the time the known neurons were created.
-
That last point should be emphasized again. If a neuron ID is listed on the Synapse or the CodeGov websites, then that person is only making a commitment to vote on the proposal type for which they are listed. They do not intend to make a commitment that they will use that neuron for any other proposal type. Hence, they should not show up as a Public neuron for any other proposal type. Neither Synapse or CodeGov is intended to be staffed with people who make a lifetime commitment to voting on NNS proposals in a public way. People come and go based on the commitment level that they are able to make at any point in time. I would appreciate if you will accurately reflect this commitment in your Public neuron registry and voting history.
-
We have made considerable effort to set up both the Synapse (NEW) and the CodeGov neurons so anyone in the ICP community can programmatically know at all times who is configured to vote on each proposal type for these known neurons. You can write code to read our Neuron Management proposal history to know the exact configuration of Followee relationships for each known neuron at the time of every proposal is submitted. This code could execute after every single proposal is created so you can verify who has a ballot to vote for the Synapse and the CodeGov neurons on the proposal topic. These details are outlined on each respective website, but once you have the algorithm figured out then it no longer matters what I post on the websites. You can check for yourself how we are configured without having to trust the accuracy of the websites. Both of these neurons are intentionally controlled by a principal that has no known private key. Hence, the only way to change Followee configuration is by Neuron Management proposals. These proposals are recorded indefinitely and can be queried using an ic-api. Proposal 127767 is an example of the latest Followee configuration for the Replica Version Management proposal topic for the CodeGov neuron.
-
Members of your dev team for Geek Factory (my assumption based on their Twitter profile) have posted inaccurate interpretations of the voting history trends that you have built. It almost sounds like he doesn’t fully understand how liquid democracy works. Regardless if this is intentional or based on a lack of understanding, the fact that you do not clearly show the follow relationships in your voting history timeline makes it possible to confuse the ICP community. Any time Synapse or CodeGov votes on a proposal for which we claim for offer an independent and objective voice, that vote occurs by majority opinion of all Followees we have configured for that proposal topic. Hence, the Synapse and the CodeGov neurons follow these voting members. There is only one voting member that will ultimately trigger the Synapse or CodeGov vote for each proposal, but that Followee is different for every proposal and their vote only triggers the known neuron vote if a sufficient number of our Followees have already voted. Hence, every current voting member for these known neurons has an equal voice in the outcome of the vote. The votes of past voting members are irrelevant to how these known neurons vote.
-
The vpgeek.app Vote History trend also do not clearly point out that Synapse and CodeGov do not own the votes that are triggered by the known neuron vote that we cast. Those votes are owned by people who have chosen to follow our neurons, which means there are hundreds or thousands of neurons (as far as I know, it is impossible to know how many) who have decided for themselves that they trust Synapse and CodeGov to cast a vote for them. It is not a truthful to claim that “just 5 voices could decide everything for everyone” If you want to clearly track and demonstrate the follow relationships of known neurons so you can add the higher level of transparency for ICP governance, then I believe you need to fix how you present the data.
I know it is more work to develop the code that would correct these issues. However, you have started promoting vpgeek.app as a tool to “monitor each vote, know every voter, and delegate with confidence”. You are also claiming that you are making it “easier to analyze the amount of voting power accumulated by known neurons, either directly or via followships”. Yet your current implementation of these features obfuscates the truth about these follow relationships. As you know from the very first post I made in this thread, I am interested in seeing you get the details right so this really is an accurate and beneficial tool for the ICP community. I’m more than happy to help clarify any details you want to know. I just ask that you make an attempt to get it right. Don’t trust me. Please verify what I am saying and update your app to more accurately reflect how known neurons and follow relationships work so it can’t be easily misinterpreted and misrepresented.
Pinging @alexeychirkov @alexander @dmitry from the Geek Factory team.