That wasn’t my intended message. I have no issue with protest voting.
I low key have issue with protest voting. It could bring dfinity to a halt if it has more power than dfinity neuron. What if they can’t run their operations?
I didn’t know that being known and active on social media was a rule to be named neuron? Where does that new thing comes from?
Is there a new named neuron guide that I am not aware of?
Does privacy only apply to transactions now?
This is exactly what I am saying. Impossible to follow the logic.
@levi is active on this forum. He was voted out couple of months ago for a named neuron while being very serious and knowledgable in the programming. People were asking him how he voted in the past and, although I can be very wrong, looks like he was rejected for his conviction. If this was the case, it is very bad.
Is it better to have 20 named neurons that think the same way and follow each other or have 5 that have different views and convictions?
Where is the logic? I just don’t get it and this is why I am all in for the protest neuron to help the NNS governance to grow in a better way.
Personally, I am against sluggish voting but I am happy that @cryptoisgood a named neuron so people who like this way to vote can follow him.
While I see the value in this I do have a few thoughts as this would be the first named neuron that is set to vote programmatically using an external code base.
I don’t understand why voting every two hours is feasible but 24, 48, or even 70 hours is not. Technically speaking this should not be an issue. I’d like to see this ironed out.
Naturally the reliability of the voting mechanism will be proven over time for all to see. However, your language leads me to believe even you are not certain enough to let this run with your hands off yet. Why not wait a month and properly track progress before deploying too prod. I don’t see a super urgent need for this functionality that it can’t wait.
I understand from a cost perspective why you’re using AWS but injecting your seed into a lamba function sends the wrong message about what is and is not best practice. I don’t think you would have any issues receiving donations for cycles (even directly to the canister).
What is the ideal solution?
Bottom line is I don’t dislike this idea, but it does not feel ready. This is what I would like to see before you submit a proposal to add as a named neuron:
- Neuron controlled by a blackholed canister in which all logic is processed (you’ll need HTTP requests and ECDSAt signatures)
- Reject vote to occur only at the end of the voting period (or after significant amount of time from start)
- Significantly more voting history to prove reliability of the programatic voting.
- Code review/audit of the automation canister performed by established developers from the ecosystem.
You’ve clearly put a lot of work into this already and have a solid understanding of how governance works on the internet computer. I would love to hear your thoughts on the above.
I would argue that if a protest neuron can garner more voting power than the DFINITY Foundation & the ICA - there is probably an issue worth halting operations to protest.
Simultaneously, I don’t thinking lumping “stagnant” voting power & “protesting” voting power together is the right way to go about it, as it leads to a conflict of interests for the followee (I’m aware OP has a program to vote no, but it brings up some questions). Naturally, “protesting” voting power will have less regard for the short-term well-being of the NNS, as they’re discontent with something that’s happening. This is most likely not the case for stagnant voting power, in fact, it’s probable to assume that they’re simply trying to optimize rewards through following a neuron.
Optimally, I’d like to see this split into two seperate neurons; one targeted at representing the best interests of stagnant voting power, and another that is dedicated solely to protesting by voting no.
The scenario of gaining more than 50% seems so unrealistic to me that it’s not really relevant. The foundation controls pretty much 100% of the voting power on other proposals. The most contested recent proposal like the community fund had only like 25% of the voting power. Big investors are really not going to follow to this neuron they are better off sending an email.
In the FAQ I mention waiting till the end of the voting period is possible and that I want to go in that direction. Absolutely fine with only making the named neuron proposal only when that is the case.
Fine with waiting for a bigger voting history as well. Note that there is only 100 of ballots saved on the neuron though. To verify a bigger history we will need a third party to make screenshots or the dashboard or something for the ones that got deleted.
/// The maximum number of recent ballots to keep, per neuron. pub const MAX_NEURON_RECENT_BALLOTS: usize = 100;
The question is would any credible devs like you be willing to put in the effort of verifying this code? I would be happy to collaborate in a public repo but this takes time and effort and we would need to await those features.
I’m personally wouldn’t like to wait for outgoing http request, threshold EDSA and the writing of that complicated code. I would also rather have neurons just be owned by canisters if people are willing to go through alternative hoops. Proposal: Remove the is_self_authenticating restriction on Neuron Ownership - #23 by domwoe
I personally feel like there is a hurry because the fact the foundation doesn’t seem to take it like a signal at all that some of these proposals like maturity modulation or Community Fund that get rejected by all community neurons and barely make it and are still being pushed through. I would like for this neuron to exist before there is another contentious proposal.
I just scanned the forum a bit and we could also create a neuron like this:
Then have the following setup
Have you me and another trusted community dev setup a 2 out of 3 following relation for the manage neuron topic and have it follow my proxy neuron with the lambda function.
This way we would have checks and balances where the most important base neuron would be controlled by established community devs. The proxy neuron would be controlled by me and the lambda function. And we would have a roadmap towards fully trustless in the feature by adding a hotkey to a canister later.
I really don’t think having it not fully trustless from the start is a major problem because any yes vote wouldn’t hold any weight from a neuron called Always Reject. I’m not looking for power as their is no power with such a neuron. So I’m happy to hand over control to more established devs so I can stay anonymous.
If you would be willing to work together on this that would be fantastic, but I can imagine you don’t have the time. I’m already a bit demotivated at this point as it is far from clear whether it would pass with this additional effort .
Don’t be. You are clearly dedicated and processing something important at least for you and probably more. To me, it is far from clear that it would not pass. Thank you for this wide and brand new field of thought you submitted to everybody.
Be aware that I would vote in favor of it.
First off don’t be de-motivated. Personally I would vote in favor of this as it is now. I was simply providing some feedback on possible areas of improvement.
All in all great work.
Thank you for engaging in the deliberation on your proposal. I am becoming much more comfortable with your new anonymous identity because it is clear that you are an active participant in the IC ecosystem and governance discussions. I also appreciate how thorough you have been in scoping your plans and providing the justification. It has quickly elevated your credibility. I think you are addressing my two biggest concerns by changing the neuron name and by letting the community get to know you through this deliberation.
I think you are right that there is no credible scenario right now because all protocol changes happen in proposal topics that fall under All Topics Except Governance. However, my concern in bullet point 5 above was in reference to the day that individual topics are removed from All Topics since there will likely be far less total voting power casting votes until neuron owners are incentivized to select a Followee for that proposal topic (and since DFINITY voting power is going down daily). I recognize that your rebuttal was that we have no idea how proposal topics will be decentralized. However, I’d prefer to plan for it happening the same way that Governance was partially decentralized. There have not been any other ideas that have surfaced on how to decentralize individual proposal topics and it seems likely that they will follow the same model as Governance. Working with that assumption, can you programmatically stop voting NO to proposals when that proposal topic no longer falls into the All Topics Except Governance catch all category? Can you routinely scan the NNS code and look for the proposal topics that are included with All Topics? If the proposal topic is removed, would you be willing to change your automated action so you no longer vote NO on protocol changes? It would be helpful to know that your open source code has this feature.
I see so an example of your concern is:
- DFINITY removes the Network Economics Proposal topic from All topics besides Governance
- A much smaller pecentage is voting on this now
- Such a small percentage that Always Rejects now blocks any proposal
Honestly I would be wildly against such a thing happening. Doing this with motion proposals that don’t affect anything is one thing. Doing it with a topic that actually affect the protocol in such a way that this scenario seems even somewhat likely is bananas. I would be happy to be a detractor to such an idea.
I think everybody is far too eager to make changes to the NNS that affect staking or the way voting works. In any proper democracy there are checks and balances so that you can’t just affect the way the governance system works with a simple majority. Doing what you are suggesting should never be done in a way were people who were following the foundation are unfollowed.
I don’t think blindly rejecting every proposal is constructive for governance, so I’m not in favor of this as a known neuron and will vote to reject.
I like the idea, good lateral thinking, so I will vote to accept, though not sure I will follow. The conversation does bring up the fact that established named neurons now have some interest in blocking other named neurons to the extent that they are competitors for followers.
Perhaps we need a separate named neuron vote category which is reward-free, so nobody loses for not voting on it, but also accepts only individual votes rather than automatic ones. That will prevent block voting and level the playing field a little.
If I assume the best case scenario, stakeholders would only follow this neuron when they’ve lost faith in the network. This could be an interesting way to gauge sentiment. It would be interesting to see how quickly this neuron gains or loses VP over time.
Is the neuron from this post How to create a decentralized community neuron still available? I would love to just use that one instead of going through all those steps.
I will update the script to only vote at the end of a voting period before making my proposal so everybody can vote manually.
Indeed, no one has claimed that neuron so far.
TBH I am not entirely sure about the gains from having this decentralized setup for your proposed neuron:
- The decentralized setup primarily makes sense if your organization consists of multiple people and you want to make changes to the setup of the neuron by threshold voting. If you control this neuron through a single other neuron, there is really no advantage in doing so.
- If your neuron votes automatically through a script on AWS, then the voting (which seems to be the important part here) is centralized anyway, even if you had multiple people controlling the neuron.
To me, this seems to be a case where the “right” setup seems to be:
- Have a canister control the neuron.
- Instead of hosting the script on AWS, build the same functionality in that canister.
- Give up central control over your canister by (a) blackholing it, (b) putting it under DAO control, or (c) letting the canister control itself.
That said, if you think this is the proper setup for your neuron, I don’t mind sending you the one I created. Just send me the id of the neuron that you want to control it with, and I’ll configure it so it’s from then on exclusively controlled by your neuron. (And you can then again change the setup so that it’s controlled by multiple independent neurons.)
Note that the NNS frontend dapp currently does not support neuron management proposals, so you’d need to be able to use your existing neuron from
ic-repl in order to send management proposals.
Have a canister control the neuron .
Is the foundation going to enable this without using EDSCA and outgoing requests soon?
I was thinking the community neuron that you created could function as the basis for a decentralised ownership in the future.
So initially I would be the only followee on the manage neuron topic and it uses AWS lambda, but I think this way it is possible to make it progressively trustless in the future by:
- adding more neurons to “Manage Neuron” topic making it act as a sort of neuron multisig
- Change the following of other topics to a blackholed voting canister later.
Would this be possible?
They haven’t really commented yet .
That is possible.
A neuron cannot literally follow a canister, but the canister could be registered as a “voting hot key” for the neuron so the canister could cast votes.
It is possible to change the “voting” neuron to being fully controlled by the canister in the future: create another neuron that is controlled by said canister, then set up “voting” neuron management to follow the canister’s neuron, so the “canister” can control the voting neuron indirectly. It’s just a bit more complex than it would need to be, and each manage neuron proposal costs 0.01 ICP, but that shouldn’t really matter since I’d expect hardly be any changes to the neuron configuration in your scenario.
The proposal here:
Is indeed from me. I wanted to bring this named neuron fully onchain first, but decided that perfect is the enemy of good.
I think taking the noise out of motion proposals is by far the most important purpose of Always Rejects. And since motion proposals don’t affect the protocol directly it seems safe to have the automation running on centralised infrastructure.
If I ever vote Accept you can disregard the voting power that came with it. I updated the FAQ on my website but couldn’t edit the forum post anymore.