Explore voting closure

[oliverbarnes]

While looking at updating voting results on updates done to global delegations (#44, #52), the issue of post-voting results updates came up.

We need a lightweight way to freeze voting results so they don't change after the fact.

A possible solution might be added a closed flag to the results table. A more involved solution would be having the higher concept of a Voting, with timed periods and such, but if possible we'd like to keep lean and leave that to the consumer platform to define.

[niklaslong]

I've had a quick discussion with @jinjagit relating to this, I thought I'd share a few thoughts.

I think we should focus on implementing a flexible core, which could be used with different voting strategies. The core should only handle the mechanical actions such as db transactions and calculations. Handling the different voting strategies would be built on top of the core and would involve keeping track of voting state. This portion of the application would need to be configurable as different consumer platforms might have different requirements in terms of data persistence and deletion, voting rules, etc...

For now and focussing on the core, I like the the closed flag idea as it's easily extensible with a state-machine to handle voting rules (Genservers perhaps...?) and would allow us to close votes in a rudimentary way.

More broadly speaking, we'll also need to figure out what we can propose to consumer platforms in terms of handling application data (deletion, voting rules, encryption & zero-knowledge, etc...)

Thoughts?

[oliverbarnes]

I think we should focus on implementing a flexible core, which could be used with different voting strategies. The core should only handle the mechanical actions such as db transactions and calculations. Handling the different voting strategies would be built on top of the core and would involve keeping track of voting state. This portion of the application would need to be configurable as different consumer platforms might have different requirements in terms of data persistence and deletion, voting rules, etc...

👍 agree 100%

For now and focussing on the core, I like the the closed flag idea as it's easily extensible with a state-machine to handle voting rules (Genservers perhaps...?) and would allow us to close votes in a rudimentary way.

👍 ...but I'm fuzzy on how we'd use Genservers for this :)

More broadly speaking, we'll also need to figure out what we can propose to consumer platforms in terms of handling application data (deletion, voting rules, encryption & zero-knowledge, etc...)

Agreed - and might be worth discussing these in separate issues

[niklaslong]

...but I'm fuzzy on how we'd use Genservers for this :)

I was thinking about storing state in memory, rather than in the DB for voting rules. Genservers would be a great way of doing that. We'd need to flesh out what the looks like to see if it's feasible/the best approach after the closed flag field is added.

[oliverbarnes]

Or ETS :)

[niklaslong]

I was thinking a combination of both: https://kaiwern.com/posts/2020/05/21/what-you-might-want-to-know-about-genserver/ (When you should use GenServer? 3.)

[oliverbarnes]

Ah I see, making more sense now.

I also have this vague idea in my mind for a config-less scenario, using request flags to signal different kinds of votings (condorcet etc), which would trigger different kinds of validation for the fields submitted. So we don't have to mess with config states. But haven't thought it through, really.