search

votingworks / electionguard-kotlin-multiplatform

An implementation of ElectionGuard version 2.0.0 in Kotlin.
MIT License
9 stars 5 forks source link

Manifest: add support for referendum contests #109

Open danwallach opened 2 years ago

danwallach commented 2 years ago

Currently tagged as a TODO. Might as well have it in there.

JohnLCaron commented 2 years ago

I havent added them because not sure how they are different from a regular contest.

danwallach commented 2 years ago

So far as I can tell, the only difference is having political parties optionally attached. Candidates sometimes have parties. Referenda never do.

JohnLCaron commented 2 years ago

Seems like its more of a contest label, rather than any change in the object schema.

Ive thought about the possibility of minimizing the Manifest schema, just keeping the elements needed for the crypto. It seems that a real election needs a rich and flexible schema, and a vender would likely be constantly tweaking it, maybe up to the last minute of an election. Currently those tweaks would change the manifest hash, which changes the crypto computation for no good reason.

So the idea would be to keep the full schema separate, and is a superset of the minimal electionguard schema.

  1. At a minimum you need Manifest, Contest, and Selection, and a small set of the VoteVariationType.
  2. Eventually maybe we want to expand the VoteVariationType. But mostly that involves how votes are counted and who is elected, and maybe should be external to electionguard as much as possible? Maybe only needed when it effects the votesAllowed? And even there, it may be redundant in the sense that electionguard doesnt need to do anything different.
  3. The BallotStyle and GeopoliticalUnit are used to assemble different ballots for different precincts. But its not obvious that electionguard needs to be the consistency checker for that. I moved all that into input package, for "separation of concerns".
  4. All the rest is just metadata.

see https://github.com/microsoft/electionguard/discussions/247

danwallach commented 2 years ago

The original (naïve?) hope was that by adopting a 'standard' schema, we might be able to become magically compatible with existing software that knows how to write that schema. I think it's fair to say that this could be done as a compatibility layer and the EG internals could then be a lot simpler.

JohnLCaron commented 2 years ago

+1