Objective
This is a governance motion proposal describing a proposed mechanism for preventing proposal spam via user determined whitelist blocking. That is we propose a rough mechanism for preventing proposal by allowing users to optionally configure the neurons they control to automatically reject all proposals from neurons that are not part of a user configured whitelist.
This is a motion proposal and does not directly result in changes to the IC. Rather voting to support the proposal is an indication that work should begin on turning this into actual code. If it passes, then I shall work with Dfinity or other parties to propose specific code changes, which will then be submitted as a new proposal to modify governance canister code.
Background
Recently we have seen a large number of spam proposals which have become a nuisance. @ Kyle_Langham and Wenzel Bartlett @wpb have called for actionable proposals to resolve this issue. This proposal will be deliberated until the 18th of April and will then (unless there are strong arguments against it or that indicate strong opposition) be submitted to the NNS as a governance motion proposal.
What we are asking the community:
- Provide feedback on this proposal within this thread.
- Vote accept or reject on NNS Motion
- Participate in technical discussions as the motion moves forward
3. Proposed mechanism and implementation
Mechanism
Users may optionally configure their neurons
-
With a ‘whitelist’ of neuron IDs that they will consider proposals from.
-
To automatically reject all proposals from neurons that are not part of a user configured ‘whitelist’. All proposals from whitelisted neurons will be subject to voting as per normal.
Proposed changes
-
Modify the Governance canister to allow NNS neurons to be configured with a whitelist.
-
Modify the Governance canister to allow auto rejection of proposals by neurons.
-
Modify the NNS interface to allow whitelist and auto-rejection settings to be easily configured and edited within the interface.
suggested UX and implementation details
-
[Suggested UX] This list should have sensible defaults. e.g. all named neurons should be whitelisted by default.
-
[Suggested UX] The user should be able to edit the list for all the neurons they control in a single operation.
-
[Suggested UX] The user should be able to toggle auto-rejection on or off for all the neurons they control in a single operation.
-
[Implementation Detail For discussion] Where the neuron follows another neuron for a given topic these liquid democracy based follow relationships should override any auto-rejection. That is if you follow cycleDAO and cycleDAO votes approve on a proposal from a non whitelisted node your neurons still vote approve even though you have selected automatically reject.
-
[Optional additional feature for discussion] If the Auto-filtering is adopted we should consider making it possible for a proposal to be submitted by a canister rather than just by a neuron. This will allow named on-chain processes like DAOs or Aedile board managed by a working group to submit proposals.
Discussion
The impact of the proposal has a number of nuances and second order effects. I lay these out here so as to guide discussion.
-
Positive First order effect: Essentially we automate the process of rejecting spam proposals people are currently doing manually. This will stop spam proposals being annoying for those that apply whitelist based filtering. Furthermore if most people opt in spam proposals will no longer have an impact on the distribution of NNS rewards.
-
Positive First order effect: If large numbers of people opt into this auto filtering system it will become almost impossible for a proposal by an unknown bad actor to be ‘accidentally’ approved.
-
Negative first order effect: If large numbers of people opt into this auto filtering system whitelisting will tend to exclude proposals from unknown parties and privilege proposals from known parties. That is this proposal itself would be automatically rejected if submitted by me as my neuron would not be known ahead of time.
I do not consider this to be a serious problem because I would argue that In most circumstances proposers of credible proposals are likely to be known or able to convince some known party to submit a proposal on their behalf. Even where it is important for a proposer to be anonymous for example due to legal risk they will still be able to advertise the neuron though some means and ask to be added to the whitelist. Furthermore if follow relationships should override any auto-rejection then it should still be possible for credible anonymous proposals to be approved
-
Positive Second order effect: If large numbers of people opt into this auto filtering system people will be discouraged from submitting spam proposals in the first place as they will have no financial or nuisance value.
-
Positive Third order effect: In most cases a proposer will have to build community reputation over time or convince a well known organisation or DAO to submit on their behalf. I predict that this will have the effect of encouraging the the formation of [multiple] secondary chambers, DAOs, processes or working groups which vet proposals prior to submission. That is working groups or other processes will tend to be the main entities submitting proposals. However since users are free to edit their whitelists none of these processes will be enshrined. We thus push governance innovation to the edges. When combined with the optional additional feature of allowing proposals to be submitted by a canister I think this could lead to a lot of innovation for example onchain workflows for vetting and workshopping proposals prior to submission.
It is also worth mentioning a possible argument against all anti proposal spam proposals, that proposals spam is a mere irritant that has not actually risen to the level at which it is a serious issue and therefore we should not make any changes to combat it at all especially if these changes complicate the governance protocol.
Security concerns
No security concerns have been identified at this time.