Periodic Followee Confirmation Follow-Up

[kusiyo]

Maybe it is time for somebody to make a new proposal to abolish this stupid proposal.

[Accumulating.icp]

@kusiyo

Maybe it is time for somebody to make a new proposal to abolish this stupid proposal.

What is it about the decentralization of voting power that is stupid to you?

I’m not sure if you’re aware, but DFINITY enacts 98%+ of voting power when they cast votes on “all except” topics.

Not saying they shouldn’t have some degree of control, but an indefinite 98%+ control over code based changes (the only thing that enacts change on the protocol), is not acceptable after 2 years. It inherently strips all decentralization claims.

[kusiyo]

It is not about decentralization at all.
They just assume people to be stupid so that they can teach people to do things.

[krzysztofzelazko]

It is enough to reset the initial followees of the neuron 27, which was set without the decision of their owners (as the initial settings) and the problem of decentralization and excessive voice power of the ICA (Dominic W.) will be solved without having to reset all settings every few months (which, at some point, could itself create unspecified NNS instability).

[Accumulating.icp]

@krzysztofzelazko

It is enough to reset the initial followees of the neuron 27, which was set without the decision of their owners

While I don’t disagree that you could stop at resetting the followees of specifically DFINITY neurons, I don’t think it’d have the negative affect on the network you imply, but rather, a beneficial one.

@krzysztofzelazko

which, at some point, could itself create unspecified NNS instability

This feature would ensure that neurons are conscience of who and where they’ve assigned their voting power, with periodic re-affirmations that they’re still confident doing so.

If DFINITY is the best option for people to follow, they will still follow them. This isn’t advocating for the removal of DFINITYs voting power.

Could you please explain to me how you see this leading to network instability?

[bjoernek]

Thank you very much for your follow-up @Accumulating.icp on how to achieve further decentralization. I will review this with the relevant parties within DFINITY and get back to you.

And thank you @ZackDS for your side comment, I was indeed out for an extended weekend

[Accumulating.icp]

@bjoernek

I will review this with the relevant parties within DFINITY and get back to you.

Thanks for the response @bjoernek , I appreciate that DFINITY will be assessing where “it” is at with this.

If we’re back at the “resources” thing we’ve been hearing for the last year, I will happily write the code myself. The source code for the governance followee reset is available.

I would just like confirmation that it truly is a resource thing, and not a lack of desire for.

If a Followee Reset Proposal comes into existence, will the foundation honour the outcome of previous proposals - and vote to pass the code based changes?

Also, I hope you had a nice weekend

[diegop]

@Accumulating.icp

I would just like confirmation that it truly is a resource thing,

Fwiw, I asked @Jan (CTO of DFINITY) and he confirmed what I suspected:

it’s in the NNS team roadmap (the “governance” section IC Roadmap), but there are a few projects ahead of it.

There used to be 9-10 projects ahead of it in Q4 2022, and now there are 3-4 projects ahead in Q2 2023. So making progress, but still on the queue…

Completed Projects that used to be ahead:

1. Service Nervous System
2. Community Fund
3. Enhance Replica Version Management
4. NNS spam protection (remove financial incentive)
5. Carbon Footprint and Sustainability Policy
6. SNS Core Canisters

In progress:

7. Restriction for SNS swap participation
8. One proposal SNS initialization

Upcoming:

9. Safe guards for the access to the SNS treasury
10. NNS Neuron ID Indexing
11. Periodic Confirmation of Neuron Followees <— here it is
12. Manual Voting

cc @bjoernek @samuelburri (VP of Eng at DFINITY) @georgi (Eng manager of NNS) in case they have anything further I may have missed.

[Accumulating.icp]

Thanks for the reply @diegop .

Based off our previous conversations, I was under the impression it was a resource thing - was just curious where DFINITY was at with it. I believe this adequately addresses the “Follow-Up”.

@Accumulating.icp

If we’re back at the “resources” thing we’ve been hearing for the last year, I will happily write the code myself. The source code for the governance followee reset is available.

I would just like confirmation that it truly is a resource thing, and not a lack of desire for.

If a Followee Reset Proposal comes into existence, will the foundation honour the outcome of previous proposals - and vote to pass the code based changes?

Given you have confirmed, it is a matter of time;

If the community provides the code, and submits it manually, or provided it to the NNS team for review for their own submission

Would DFINITY honour the previous governance proposal that has approved this implementation , and vote to approve the code based changes, ahead of the provided schedule?

[diegop]

@Accumulating.icp

If the community provides the code, and submits it manually,

If anybody submits any code for an update, I am pretty certain engineers at DFINITY would review it (all code is reviewed). More directly: I have not heard any problem with the desire of feature, only in urgency at others and resource allocation.

That said, my personal opinion (based on general experience, not this proposal in specific) is there are many design questions and edge cases in this proposal that will reveal themselves in code/implementation, as in any proposal or project. So it is not just a matter of coding it up, but likely a matter of coding it up… and then iterating on design and edge cases decisions in a dialogue with the community.

[bjoernek]

For completeness, I would like to add that a design issue related to periodic confirmation of following was already raised, see here. Hence, proposed changes to foster decentralization should consider this aspect.

[Accumulating.icp]

@diegop

If anybody submits any code for an update, I am pretty certain engineers at DFINITY would review it (all code is reviewed).

Reasonably, thanks for updating me on this.

@diegop

I have not heard any problem with the desire of feature

Thanks for clarifying - it seems as though many within this discussion, fear that DFINITY losing their super majority, results in the insecurity of the network.

Glad to know that DFINITY doesn’t share these views.

@diegop

design questions and edge cases in this proposal that will reveal themselves in code/implementation

Regarding the actual implementation, I thought it was rather straight forward and thorough, as passed via NNS. Please reference the initial proposal;

[Accumulating.icp]

Upon review; it seems your “design flaw” is the mechanism working exactly as intended - decentralizing voting power, and reinforcing the reaffirmation of followees …?

If the super majority execution of proposals with available VP is the concern, it seems like something that could be solved by making the amount of VP required to enact a super majority, relative to the average amount of VP used within each governance proposal (as it’s one of few reliable samples of active voting power, after a reset) across the last, year, for example.

This would also make governance proposals more than a glorified poll, as they’d directly impact the “super majority weight”.

EDIT: Reflecting, I see a flaw with this, but I believe the workaround is arguably beneficial to governance aswell.

Will publish a draft prop on this soon

EDIT 2: Drafted Resolution Proposal

Absolute Majority Weight Proposal Draft

Proposal As a solution to the “design flaw” referenced by @bjoernek , in response to the Periodic Followee Confirmation Proposal, I propose two modifications to the “Absolute Majority” functionality within Proposals. Primarily, I propose that the calculation to determine an Absolute Majority is altered. Currently, it considers all voting power, and executes an Absolute Majority if 50%+ of total voting power has been exerted on “yes” or “no” votes respectively. I reccomend that rather than con…

[Ivan]

But you proposed this and adopted this over a year ago along with other proposals that were adopted so quickly without due diligence.

Let me get this straight

1. DFINITY creates a problem
2. DFINITY creates a solution for that problem
3. DFINITY adopts the problem
4. DFINITY still hasn’t adopted the solution and is making excuses about Roadmap?

For every dependency we encounter, we have to contact DFINITY.
How do you expect us to trust and rely on DFINITY when they can’t keep their word?

[wpb]

@Ivan

But you proposed this and adopted this over a year ago

An important clarification…the community proposed the periodic confirmation of neuron followees and the NNS voters adopted it. DFINITY did not propose it and they did not adopt it. They voted for it as a voting member of the NNS, but there was no promise to implement it. They simply said it’s a good idea.

[Zane]

Unless I’m missing something the only reason not to implement period reset of followees in the immediate future is it might impact Dfinity’s ability to quickly push replica upgrades in case there are vulnerabilities to be fixed or any other kind of issues which requires quick interventions.

So what if it were initially rolled out only for the governance topic? Governance proposals are non binding and aren’t needed in the scenarios Dfinity mentioned, by doing so at least the governance topic will reflect more accurately community’s stance and it will act as a testing ground for the feature.

[Accumulating.icp]

@Zane

So what if it were initially rolled out only for the governance topic? Governance proposals are non binding and aren’t needed in the scenarios Dfinity mentioned

I agree with you @Zane , this would be a great way to test the feature, and ensure sound implementation of functionalities.

However, I believe this leads into the greater question of, how do we ever get to the point in which DFINITY feels comfortable relinquishing the 98% super majority they’ve assigned themselves? Should they be the ones to decide when they should relinquish this self assigned voting power?

In my opinion, that should be the responsibility of the neurons who own the voting power, not DFINITY - which is why I believe Periodic Followee Confirmation for all topics is crucial.

I’ve written a draft proposal that I believe, if implemented alongside the Periodic Followee Confirmation proposal, would be a valid solution to the proposed “Design Flaw” with this proposal. Would love to know your thoughts on it;

Absolute Majority Weight Proposal Draft

Proposal As a solution to the “design flaw” referenced by @bjoernek , in response to the Periodic Followee Confirmation Proposal, I propose two modifications to the “Absolute Majority” functionality within Proposals. Primarily, I propose that the calculation to determine an Absolute Majority is altered. Currently, it considers all voting power, and executes an Absolute Majority if 50%+ of total voting power has been exerted on “yes” or “no” votes respectively. I reccomend that rather than con…

[justmythoughts]

@diegop

One proposal SNS initialization

What is the purpose/feature description of this? Isn’t there a benefit for projects to test out the SNS canister flow on main net after the first deployment?

Additionally, how will this one-step process be communicated to voters (many currently vote yes on proposal1 and no on proposal2)?

[Apollon]

@wpb

An important clarification…the community proposed the periodic confirmation of neuron followees and the NNS voters adopted it. DFINITY did not propose it and they did not adopt it. They voted for it as a voting member of the NNS, but there was no promise to implement it. They simply said it’s a good idea.

You literally proposed multiple proposals along with this. Stop trying to undermine your actions and take up the responsibility.

You engaged and made others engage with this topic as it was related to other proposals which were accepted by DFINITY, submitted by you.

Plausible Deniability does not work all the time…