# Dot voting

[Dot voting](https://en.wikipedia.org/wiki/Dot-voting) consists on multiple agents being able to vote on a same issue with multiple options, but where each agent only gets a certain amount of votes. An agent can vote as many times as they want for the same option, but summed their votes can't exceed the number of votes they have.

This is a less consensus, more "flexible" way of signaling importance of interest. It presents some of the same challenges as traditional voting, so I'm going to use it as an example.

Technically, this is a reusable zome that does not need any membranes (maybe one to make sure that no two agents belong to the same person, like social triangulation, but unlikely because we are already filtering who can vote on the side of the proposer). It can be used in different contexts and DNAs.

>To transform this into normal "majority" voting, we should:
>1. Make each vote its own DNA.
>2. Pass in as properties of the DNA the list of nodes that will play the role of "ballot boxes".
>3. Make a membrane that allows only the people that are in the census list,
>
>And we also still need a mechanism to anonymize the votes, which I can't think of unless we *trust* the ballot boxes to never disclose our identity (maybe ZK-snarks could be used here)

## User stories

* Any agent should be able to propose a vote, specifying a list of options, list of authorized users to vote, a max number of votes for each agent and a time limit.
* An agent authorized to vote should be able to vote for the options they want, but those votes should never exceed the number specified by the proposer of the vote.
* The proposer of the vote should be able

## Entry structure

This first anchor type is from [holochain_anchors](https://github.com/holochain/holochain_anchors)

Entry "anchor" {
    struct Anchor {
        anchor_type: String,
        anchor_text: Option<String>
    }
}

Entry "vote_proposal" {
    struct VoteProposal {
        proposer_address: Address,
         // These can either be titles for the options or
         // addresses of entries in the DHT for more complex data structures
        options: Vec<String | Address>,
        authorized_agents: Vec<Address>,
        max_dots: usize,
        // Just for info
        closing_time: Timestamp,
        // For actual validation purposes
        closed: bool
    }
    Links: {
        agent_id->vote_proposal, link_type: "proposed_vote"
        agent_id->vote_proposal, link_type: "voter"
        
        // The tag in this link is where the vote info will be stored
        vote_proposal->agent_id, link_type: "vote"
    }
}

The tag inside the vote_proposal will be a serialized struct of this form:

struct VoteTag {
    vote: {
      voter_address: Address,
      vote_address: Address,
      options_voted: {
          [index_of_option]: [number_of_votes_for_that_option]
      }
    },
    proposer_signature: Signature,
}

With this design we optimize for query efficiency on the "get_all_votes_for_this_proposal" function, but it will be a little slower for a "get_all_votes_that_this_agent_has_made" (you have to make more hops).

## Flow of voting

To know when a vote is valid or when it is not, we are going to use the proposer's time, as they are the valid authority that everyone trusts when accepting to participate in the vote. To make sure that the proposer's time was not passed when a vote was cast, the proposer will need to sign the vote.

This is how it would work:

1. A proposer creates a vote proposal.
2. A voter inputs their vote for that vote proposal, and sends it to the proposer.
3. The proposer checks if the vote proposal is still not closed. If it's closed, it rejects to sign the vote.
4. The proposer hashes the info, signs it and returns the signature to the voter.
5. The voter creates the vote with `add_link`.

> This method has the downside that the proposer has to be online at all times for the votes to be signed, maybe there are other patterns which do not require it.

## Entry relationship diagram

graph TD
  subgraph postszome
    subgraph anchors
        all_votes
    end
    subgraph agent_ids
      alice_id
      bob_id
    end
    subgraph vote_proposals
      vote0
      alice_id-->|proposer|vote0
      bob_id-->|voter|vote0
      alice_id-->|voter|vote0

      vote0-->|vote|alice_id
      vote0-->|vote|bob_id
    end
    
    all_votes-->vote0  
  end

## Validation

### Entries

* `anchors`:
* Create valid if the agent_address that is creating it is signing the entry
* Update or Delete is not valid
* `vote_proposal`:
* Create or Update is valid if the agent_address that is creating it is signing the entry
* Delete not valid

### Links
* `vote`:
* AddLink: valid if:
* The agent_addres in the anchor from which we are linking is signing the entry
* The signature of the tag is from the proposer address of the vote proposal that is the base entry for the link, and it's signing the hash of the "vote" portion of the tag.
* The indexes of the options inside the votes do not exceed the options vector length in the vote proposal that is the base entry for the link.
* The vote address is equal to the base entry address
* The sum of the votes is less or equal to the maximum allowed votes in the vote proposal
* There is no other link from this vote to the same voter address
* RemoveLink not valid

Future optimization: remove vote_address and voter_address from the tag, requires that the signature is made with those properties inside the content that's hashed and then signed.