Yesterday I described my first ideas at mapping the preferential voting method used in Liquid Feedback, to an approval voting method as supported by Helios Voting.

After writing it I had a Heureka moment and went back to check some details on how Liquid Feedback, and in particular the Schulze method actually works. It turns out it is not necessary at all to keep a record of the +N ... 0 ... -N scores given to each vote, this is merely an implementation approach used in Liquid Feedback. The only thing that is really needed is just the pairwise comparisons of all alternatives. This is stored in Liquid Feedback in the battle table. In fact, that is precisely what Solon delivers back to Liquid Feedback as results of the voting.

The battle table is very simple, using our (A, B, C, Q) example of yesterday:

The good news is, encoding this as a Helios election is both feasible and straightforward. We can create a referendum with multiple 1-out-of-N questions, each question allowing to compare one alternative pair:

Question 1: How do you compare alternatives A and B?
[ ] Prefer A over B
[ ] A and B are equal
[ ] Prefer B over A

Question 2: How do you compare alternatives A and C?
[ ] ...

Tallying the results of such a Helios referendum will immediately produce the results that can be written back to the battle table of Liquid Feedback.

There is still a small thing that with this approach it would be possible for a voter to cast votes containing "circular paths" that contradict each other. E.g. voting A as better than B, then B as better than C, and then C as better than A. Of course, this can be prevented by the user interface, but ultimately of course it would have to be enforced by the cryptographic algorithm. Probably there could be some zero-knowledge-proof that enforces this property.

Otoh, I don't know how harmful such circular / contradictory choices are to the Schulze method. Maybe it's not an issue. I suppose this is a good topic for further study.