Problem

There are sometimes situations where the results of elections are surprising, and candidates do not receive as many votes as maybe expected. This is not really a core problem in itself, but it does indicate that due to the nature of our voting system it requires quite a lot of coordination. It can also create issues where people end up voting heavily for someone who basically already has an almost guaranteed chance of getting elected in the top spot and not directing their votes to potential 2nd/3rd candidates

Solution

When a vote is submitted, a secret salt is generated. If someone has this secret salt they can determine which candidate was voted for--but importantly they cannot trigger the actual reveal of the vote (this can only be done by the voting account itself. They also can't change who the vote is for.

This means that it is possible to add functionality to Pioneer where a voter can choose to publicly show who they are voting for in advance of the revealing stage--this may be a very useful and interesting feature to have. It would not guarantee that the voter would reveal their vote though, but may still help to better inform voters of who to vote for.

This change can be done without any changes to the runtime and it seems a simple metaprotocol message indicating the voter desires to make public their intended vote.

This would need some thinking before it could actually be implemented, namely:

Is this a feature that people would want and would it make elections better?
How should it be designed/worded so it is clear that these votes aren't actually guaranteed until the voter reveals them
--Could a bad actor abuse the metaprotocol feature and put in another salt and pretend they're voting for someone else?--
(apparently "fake salt can be verified by checking if the revealed salt + choice hashes to the same value as published on-chain") which means this type of attack isn't possible.

Joystream / pioneer

Idea: pre-reveal votes (`Vote Intentions`) #4717

Problem

Solution