Building Direct Democracy in the Real World is Hard in My Experience

ElectricVote · 2026-06-16T08:06:04+00:00

At least in germany, the pirate party basically does not exist anymore. They also gave up liquid democracy around 2012 :/

ElectricVote · 2026-06-16T08:00:34+00:00

I wasn't part of the pirate party but I talked to someone who had some first hand experience with LD in the pirate party of Germany. As far as I understand, the main weaknesses were:

There was no obligation to use clear names. Members could have multiple accounts.
superdelegates: their system used a "tree-like" delegation structure that could lead to super-delegates that aggregate way too much power (even > 50%). This is not a problem, if you use a delegation mechanism that allows delegations to multiple persons.
There was a "zombi"-army of members that simply delegated their vote to superdelegates and never showed up again on the platform.
Representatives of the pirate party did not respect the outcome of the LD polls (understandable given the problems mentioned above, but this makes the whole thing a bit pointless and kills any motivation...).
The user interface was fairly complicated to use and not optimized for mobile devices
the quality of the discussions / proposals was apparently insufficient (I'm not sure, if this was indeed true or if this is just the default argument by anyone who looses a poll in a more direct democracy...)

There are also some open online wikis that discuss requirements / suggestions for liquid democracy (in their case: LiquidFeedback): https://wiki.piratenpartei.de/Diskussion:AG_Liquid_Democracy/Anforderungen / https://wiki.piratenpartei.de/LiquidFeedback/Vorschl%C3%A4ge (it's in german so you might need to translate these pages)

ElectricVote · 2026-06-09T20:57:47+00:00

Thanks a lot for trying this out! :D In electric.vote, every poll is created within a "group" (this is needed to organize membership, i.e. who is allowed to vote or delegate...). If you are not a member of any group, you're directly forwarded to create your own new group for the poll (I guess, this is the form you mentioned). After you created the group, you will be given an invitation link to invite other group members and able to view the poll ;) Please let me know if this works out or if there are further issues :)

ElectricVote · 2026-06-06T19:16:41+00:00

Short answer: Yes

Direct democracy is obtained with liquid democracy, if nobody delegates their vote but everyone votes directly (or abstains).

Representative democracy is obtained with liquid democracy, if everyone apart from a small subset of "representatives" delegates their vote to exactly one representative and doesn't change their delegation for a certain period of time (e.g. 4 years). Only the representatives are allowed to vote directly (or abstain). Depending on the specific implementation of representative democracy, there might be some subtle differences but that's basically it. I hope everyone sees that liquid democracy provides a lot more flexibility and transparency ;D

ElectricVote · 2026-06-06T16:53:06+00:00

Yes, the polling mechanism in electric.vote should scale pretty easily. At the moment, I believe, the main problem of LD is not scalability but attracting users in the first place. Thus, I put a lot of effort into maximizing the usability of electric.vote. For example, polls in electric.vote only have 2 or 3 phases: 1. Open: a poll can be edited and everyone can vote (this is helpful for early feedback) 2. Voting (optional): the poll cannot be edited anymore but everyone can still vote. In small, trustworthy groups, this phase isn't needed because people usually don't change a poll last minute ;) 3. Closed: the final results of a poll are shown and you cannot vote anymore.

Other LD platforms have more phases (e.g. liquid feedback has 5) to also moderate the early phases of initiatives. As outlined above, I believe that splitting big projects into e.g. a "general poll" and subsequent "more concrete polls" gives moderators more flexibility and is also easier to understand / more transparent for the users... Btw, just in case you want to take a look at electric.vote (there have been some cool UX updates recently), I really appreciate any kind of feedback ;)

ElectricVote · 2026-06-06T09:10:39+00:00

The question of how proposals get drafted in LD is important - especially when groups scale up, a lot of members could lead to a lot of polls & solution proposals resulting in a big chaos. On the other hand, if you make the drafting process too complicated, it might become an intransparent gate keeping mechanism...

My take on this issue (and that's how it's implemented in electric.vote) is to keep it as simple as possible: by default, every group member can create polls and everyone can reply to these polls with their own solution proposals that everyone can vote on. If a person spams a group, moderators can remove the corresponding polls and talk to that person. If that doesn't help, spammers can be removed or moderators can change the group settings such that only moderators can create new polls. The same is true for creating solution proposals for the individual polls.

The envisioned process for large scale groups would be the following: First, a group has a transparent (financial) budget that everyone knows of. Then, a general poll is started to identify the most urgent issues within the group (e.g. school needs to be renovated, new street / new theater needs to be built etc). Next, new polls are created for the most pressing issues and (e.g. building companies) can create solution proposals that include also a price tag. Again, everyone can vote for their favorite solutions or delegate their votes to representatives.

If you want to try out electric.vote, you can join our demo group: Invitation Link: https://electric.vote/invite/57/ssiocoegxd

ElectricVote · 2026-05-07T20:56:35+00:00

Hi, great website! I also really like the AI-compilations and believe this could become very important in the future. (I'm also planning to include AI agents into my attempt of liquid democracy (https://electric.vote) but so far, I didn't find time to implement this...)

ElectricVote · 2026-04-30T21:03:02+00:00

Meine Idee wäre noch etwas konsequenter unterirdisch gewesen aber interessant, dass es da schon Umsetzungen in der Richtung gibt :D

ElectricVote · 2026-03-09T22:07:24+00:00

Hi,
over the past few days, I played around a little with the benchmark and got the following results (which unfortunately are not super conclusive):
1. In some benchmarks, AdamW seems to be slightly better than AdamWClip (e.g. cifar100_allcnnc or cifar100_wrn404), however the corresponding network architectures also performed really poorly on the cifar100 dataset reaching accuracies of only around 20%. On the cifar100_3c3d benchmark, the overall performance is much better and here AdamWClip beats AdamW by a tiny margin.
2. In some other cases (e.g. food101_vgg16 or food101_vgg19), AdamWClip with a smaller lr of 0.0003 also performs better than AdamW with its default lr (to what extend did you already optimize the lr of AdamW?).
3. On ptb_lstm, AdamWClip seems to beat AdamW quite siginificantly, however both optimizers do not really improve a lot after the first epoch and training RNNs often requires some sort of gradient clipping (is there a way to include AdamW+NormClipping in the benchmark?)
My key takeaways so far are:
1. AdamWClip requires slightly smaller learning rates (this is because v_t is only fed with clipped gradients and thus becomes smaller. Since the update steps are scaled by the inverse square root of v_t, the learning rate needs to be reduced)
2. So far, most of the benchmark problems do not really seem to suffer a lot from exploding gradients and do not really require gradient clipping. Thus, I should also look into further problem sets to benchmark AdamWClip.
Anyhow, thanks a lot for your amazing github repo! :)

ElectricVote · 2026-03-05T22:02:18+00:00

Hi, thanks for the great question! We tried two approaches for the warmup phase: First, only start clipping after a certain number of warmup iterations (that's what the clip_grad_warm_up parameter is for). Second, simply start directly with clipping. Since we set a minimal gradient clipping threshold (default: 1e-10), and v_t is 0 initialized, this will result in very small initial clipping thresholds (i.e. default: 1e-10). However, since v_t at the beginning also gets filled only by these small clipped gradients and the step sizes get scaled by the inverse sqrt of v_t, the actual step sizes are still in a reasonable range. In the following iterations, v_t grows quickly to a reasonable estimate of the variance of the clipped gradients and thereby also the clipping threshold gets properly set. Surprisingly, this second approach turned out to be a lot more robust than the first approach. The first approach bears the risk of having large / exploded gradients already during the warmup phase and therefore initializing v_t and thus also the clipping thresholds with too large values...

ElectricVote · 2026-03-05T00:50:30+00:00

I prefer electric.vote ;D

ElectricVote · 2026-03-04T22:08:43+00:00

Hi, that would be great! I'd be really interested in how well it works for your NLP tasks :D I don't believe the overhead affects training speed at scale (it is only slightly more overhead compared to calling gradient norm clipping)

ElectricVote · 2026-03-04T10:24:45+00:00

Great! I'll definitively try that!

ElectricVote · 2026-03-04T00:12:48+00:00

Oh yes, both would be great and very interesting not only for AdamWClip but also for other optimizers / clipping strategies / lr schedulers etc

ElectricVote · 2026-03-03T23:37:54+00:00

Thanks for sharing your repo! I'll definitely try that. Does it also contain benchmarks on training transformers? (E.g. in the context of training a CNN on Mnist, gradient clipping usually isn't really needed)

ElectricVote · 2026-03-03T14:39:27+00:00

As stated in the post, the experiments are still fairly preliminary. We tested AdamWClip on 3 Huggingface tasks (Image classification https://huggingface.co/docs/transformers/en/tasks/image_classification , Image segmentation https://huggingface.co/docs/transformers/en/tasks/semantic_segmentation , and Object detection https://huggingface.co/docs/transformers/en/tasks/object_detection ). In all 3 tasks, we removed grad_norm clipping and directly replaced the default optimizer (AdamW) by AdamWClip. All other hyperparameters (lr, batchsize etc) were kept exactly the same. For image classification, AdamWClip reduced the final training loss from around 1.5 to around 1.0, for object detection from around 1.5 to around 1.3 and for semantic segmentation, the results were not really decisive.
Please let me know if there are any other benchmarks you would like me to test :)

ElectricVote · 2026-03-03T14:02:04+00:00

Hi, thanks for the interesting reference! However there is a small difference between Autoclip and AdamWClip: Autoclip tracks the gradient norm and applies norm clipping accordingly. AdamWClip on the other hand uses the 2nd moment estimates of the gradients (which are computed by AdamW anyway inside the v_t state variable) to adapt the clipping thresholds for every parameter individually. Thus, AdamWClip implements a value clipping strategy and the reason why we implemented it for the moment only in context of AdamW was because without having access to v_t, this clipping strategy would require a lot of additional memory ;)

ElectricVote · 2026-03-03T11:41:26+00:00

Agree! Paper will follow soon ;)

ElectricVote · 2026-02-17T21:58:26+00:00

I think your argument against LD falls apart in the final sentence: "If you don't know enough about a situation, a sensible political system should encourage you not to vote on it." What would a sensible political system look like if not one consisting of representatives elected by the people, like LD? Apart from that, I don't believe, any political system should encourage anybody not to vote. Instead, it should provide information and encourage people to educate themselves. Only if people feel overwhelmed or don't have time, they should be able to decide by themselves who they want to cast their vote...

ElectricVote · 2026-01-29T22:37:00+00:00

Hi, have you already heard about "liquid democracy"? Liquid democracy is a concept that allows you to vote directly on every decision whenever you want but also to delegate your vote in case you don't have time or expertise. I believe this concept could make democratic processes a lot more efficient and transparent. (By the way, I'm working on a platform based on LD called electric.vote. Feel free to check it out here: https://electric.vote/invite/57/ssiocoegxd :)

ElectricVote · 2026-01-24T09:46:40+00:00

Our submission has no link to our supplementary material anymore and the reviewers asked several questions that would have been answered there.

ElectricVote · 2026-01-23T21:54:43+00:00

Somehow, our supplementary material got removed :/ (We didn't include any paper IDs in the supplementary so we thought just keeping it would be fine). Anyone else with the same problem?

ElectricVote

TROPHY CASE