We get rewarded for contributing our voting power. We can either do that manually, or by empowering a followee. All of these extra definitions and unwritten bylaws that people throw around on the forum is just conjecture until it’s been ratified by the NNS. Proposal 55651 is the first time a reset period has been defined. This implies a minimum level of participation and I think it’s good for the network; but this didn’t exist when the follower settings changed.
To be clear, i agree that changing the follower settings was a necessary evil in order to help decentralize the NNS. At the time, it helped break stakeholders away from the foundation.
I am just tired of all these excuses for why it was okay. The most annoying being our attempts to label these individuals as passive or negligent simply because they may take a long-term approach to managing their investments. It also annoys me that we continue to label them and use their behaviour as justification for further change. If our only reason for suggesting a change is because “we deserve it more” then I’m probably not going to be for it.
I didn’t realize a few months was equivalent to an entire lifetime.
If you have millions of dollars invested in an asset and can’t even bother to check it out once in a while and even end up losing a considerable sum due to lost interest then I don’t want your voting power in the NNS, if you can’t even do what’s best for your own interest how can I entrust you to do what’s best for the network as a whole? We get paid for providing voting power but this situation has made it quite evident not all VP is the same
Without periodic confirmation it might as well be.
I make the assumption that any person who is dissolving their neuron is perfectly capable of meeting a minimum definition of active participation just like everyone else. There is no effort to prevent anyone from participating in governance. Default followee configuration had utility to bootstrap the network, but it is stifling decentralization at this point. In case you have not been paying attention, DFINITY and ICA have voted on all governance proposals for well over 2 months now. They are an excellent choice for a followee, but perhaps even they should be an intentional choice made by neuron owners. We also need more named neurons, which is acknowledged and encouraged by everyone, yet nobody has stepped up to provide new options. I would still love to see The Fools Court in this role. I was very happy to learn that Psychedellic will pursue this role in their town hall recently. There are so many other people and organizations in the IC community that could do the same. Contrary to what you seem to want everyone to think, I by no means believe that active voters only follow ICPMN, ICDevs, or cycledao.
Which part makes you sad? Here is the most recent Subnet Update as an example. Proposal executed less than 1 hour after it was submitted…98% of total voting power in the NNS already cast…3 days 18 hours left in the voting period. This is routine business executed quickly and rightly so. Any desire for the public to be able to vote on these types of proposals or review them with capacity to stop them at this stage of the IC just doesn’t make sense.
Whose definition? Where did this definition come from and when did we ratify it prior to proposal 55651?
Never said there was an effort to do this.
I agree, see my earlier statement:
Not sure where this is coming from but ok, i don’t disagree
This will be up to the community to decide once we’ve achieve a decent size. I am not the end all be all of TFC, nor is @Pwoseidon or @weedpatch2.
What makes me sad is that you want to change the protocol so that there’s almost no chance for any orther organization to push back on these proposals. What if an organization with the power and competency to challenge one of these proposals chooses to do so? Your proposal would give them an extremely small window to build support and almost guarantee Dfinity the deciding vote.
Just because this is the standard today does not mean we should resign to it always being this way. We changed follower settings in order to increase decentralization; yet, we chose not to do the same for non-governance topics. It doesn’t make sense.
What would happen when a bad actor controlling > 3% of the voting power submits a malicious proposal and DFINITY for some reason doesn’t vote on it within that one-hour voting period? Your suggestion depends on a quorum of humans at DFINITY monitoring and voting on proposals 24/7.
This is no different than today. You can go to the dashboard and open any subnet management proposal and see that they are executed shortly after they are submitted by Absolute Majority.
I agree. When that day comes, adjustments will need to be made. This is why we have a mutable governance system. Change is necessary and the NNS provides that flexibility. My point is that today there is no chance for any other organization to push back on these proposals, so I don’t see the need for the larger voting period window. DFINITY is the deciding vote and there is nothing anyone can do about it today. Nor do I think anyone wants to do anything about it today. It will take time to get to the point where that is relevant.
Would you please clarify further? Are you suggesting follower settings should be adjusted for non-governance topics? That’s what proposal 55651 would do. Do you agree with that mechanism or did you have something else in mind?
This is an excellent point. The idea will need additional consideration because we cannot let that happen.
@Dylan I modified the original comment to 24 hours instead of 1 hour. Take a look and let me know if you still see a gaping issue. I suggested 24 hours since that was the original voting period for all proposals. I would think the question that needs to be considered is if we really need to be able to implement changes to these proposal types faster than 24 hours. If so, then the idea still requires additional consideration. Perhaps there is utility in limiting the neuron IDs that can submit proposal types that are of certain critical nature or maybe there is already a limitation on who can submit that code to GitHub. I think my main point is just that we should consider a much shorter Voting Period for proposals where is is important to consider Reactivity. I don’t think that Voting Period needs to be the same as it is for Governance proposals.
I think a 24-hour voting period addresses the concern that I had about bad actors, but then you’re back to the situation where you may have to wait 24 hours to pass important proposals. That’s better than 4+ days, but a lot longer than the current ability to pass these proposals essentially immediately. The ability to pass proposals fast is important. Imagine if some security vulnerability needs to be fixed, and every minute it’s not fixed bad things are happening.
Just thinking out loud, perhaps this concern could be addressed by changing the (proposal 55651) proposed way that the confirmation would work. For example, say that all neuron holders had to confirm their followees once a year before January 1st, but that the NNS wouldn’t actually remove followees from any neurons on January 1st unless (or until) a certain threshold of voting power had confirmed their followees. You would then set that threshold in a way that virtually guarantees the effective voting power of DFINITY with following doesn’t drop below 50%. In other words, a Periodic Confirmation of Neuron Followees would be implemented, but if not enough neuron holders confirmed their followees, nothing would happen. This way the functionality could be implemented without relying on the hope that neuron holders would indeed confirm their followees.
I agree 1000%. Also, I always said that dead voter (or many of them), who could be a whale, providing their vote to make a proposal to pass or not is 100% non sense, and is looking really bad for the entitre governance system. Dead voter need to be eliminated from voting, the sooner the better.
I agree that we should focus the discussion on the criterium reactive, as this is currently the main drawback of the proposal on periodic re-confirmation of followees. So essentially, how can we ensure that very urgent fixes can be implemented immediately.
One possible solution (based on a discussion with @Manu) could be to vote on granting hotfix update permission to trusted developers on a temporary basis (e.g. for 2 weeks or a month). This way the urgency of the update would be decoupled from the prior vote. @Manu: Did I summarise your idea correctly and would you have further points to add?
I like that idea a lot. It probably opens up the opportunity for the public to perform more code review on non critical updates while still enabling critical hot fixes. Seems like a move toward decentralization.
Building off of @Manu’s point, if we’re talking hotfixes/patches, what about a model where there’s ~10 developers that have the privilege to review and approve a hotfix/patch, and that only a certain fraction of them need to respond in order to push out the change? Maybe there’s some sort of Pagerduty integration for these chosen few.
Btw, how is the DFINITY neuron currently managed for pushing out hotfixes? What happens when it’s the middle of the night in Switzerland and an on-call alert goes off that requires an immediate patch fix? A developer submits a code change proposal, but then does someone wake up the person (or people) in charge of the DFINITY neuron?
I can’t imagine that Dom or Jan are the ones pressing the accept/reject button on all of these proposals.