democracyearth / old_dapp Goto Github PK

Current implementation doesn't handle cycles. If there is a delegation cycle it would get stuck in an infinite loop spending the maximum gas allowed to spend.

How does the token plugin to liquid democracy smart contracts? Look into minime token as well as current zeppelin-solidity vote token implementation

• add radio buttons to filter ballots
• filtering logic linked to radio button
• add voting percentages on option (can be done later on)
• add contextual user information on ballot feed (delegated votes available, votes made etc.)

Implement a simple UI for developers, to test every action possible of the contract and to have something to show

When user clicks on revoke button it should trigger a metamask transaction.

• implement API call with web3.js and construct transaction.

Implementation must come with its respective tests in the corresponding test file

When user clicks on the button Sign up & Login it triggers a metamask transaction

• app generate user json with input data from the form to send it to IPFS
• signup button triggers to call registerNewVoter() with API call with web3.js and construct transaction.
• API getter queries to get the info from Ethereum and IPFS --> show status of registerNewVoter() transaction and show user name in nav bar.

The UI should show the state of the transaction.

Exploring the idea of letting a voter change or update her vote once she's already voted

In this article
https://medium.com/blockchannel/how-to-save-your-ethereum-dapp-users-from-paying-gas-for-transactions-cfc665891ab4
they mention ways of shifting the gas consumption from the user that is interacting with the contract to the contract itself, which could be beneficial for us as we don't want voters to have to spend tons of gas just for a single delegation change.

Ballot information that we need to query:

• title
• author name
• date of creation
• transaction status

The transaction status is only needed when the user creates the ballot. I'm thinking to construct the page we don't really have to get title, author name, date of creation if we just cache them and construct the page with the info. That way the only getter we'd need would be the transaction status. What do you think @LucasIsasmendi @aecc ?

For now the revoke() function in LiquiDemocracy.sol only works for delegations. It would be nice to implement one for votes as well. See #55

Create a getter that sums all the votes available for each option and retrieves the results

When user selects chooses an option ( yes or no) and then clicks on the vote button it triggers a metamask transaction. Vote function parameters are vote(aremsg.sender, ballotId, voteOption)

• implement API call with web3.js and construct transaction.
• The UI should show the state of the transaction.

Discuss with team and set up actionable issues we can work on to move forward with basic quadratic voting implementation

@aecc just logging this here so we can keep everyone in the loop, feel free to provide more context if needed.

Idea is to take the initial work below into a separate branch for this repo and continue testing from there.

https://gist.github.com/anonymous/7e55d694d3b1a118a8bc3a1d3dcb608c

Cores features are for a user to be able to 1) cast a vote directly on a issue, 2) revoke a vote previously cast, and 3) delegate a vote to a peer.

Need to break down what workload these features translate to, the idea is to give structure to milestone Contracts v0.1.0

I'm getting the following when doing testrpc.

/usr/local/lib/node_modules/ethereumjs-testrpc/build/cli.node.js:30305
function VM (opts = {}) {
                  ^

SyntaxError: Unexpected token =
    at exports.runInThisContext (vm.js:53:16)
    at Module._compile (module.js:387:25)
    at Object.Module._extensions..js (module.js:422:10)
    at Module.load (module.js:357:32)
    at Function.Module._load (module.js:314:12)
    at Function.Module.runMain (module.js:447:10)
    at startup (node.js:139:18)
    at node.js:999:3

Shall we have an ethereum daemon or something else running?

When user creates ballot it triggers a metamask transaction to create a ballot calling createNewBallot(). createNewBallot parameters are createNewBallot(address from, bytes32 ipfsTitle)

• send json to IPFS to get hash
• implement API call with web3.js and construct transaction
• implement getter to get the transaction status
• dedicated page for create ballot

The UI should show the state of the transaction.

Parent #69

THE BALLOT

• Layout CSS
• Style to designs
• Get a ballot title
• Get posted by
• Add time stamp for posted date
• vote % on yes and no
• vote data on yes and no
• get cast votes data
• get number of undecided votes data

YOUR ACTION

• Layout CSS
• Style to designs
• Add tooltip
• vote tab and delegation tab
• radio buttons for yes and no options
• vote button
• revoke vote button
• get list of potential delegates in dropdown
• You delegated x votes to [user] for this ballot
• revoke delegation button
• transaction status

LIQUID DEMOCRACY REPRESENTATION

• Layout CSS
• Style to designs
• add tooltip
• add tabs
• vote graph for yes
• vote graph for no
• vote graph for undecided

See #57 for delegate tab.

Currently, the implementation is limited to a single vote per person, according to the paper and Sovereign, we should make possible to vote more than a single owned vote

Currently, delegate and remove delegation are not modifying the ballot[ballotOption].voteCount according to the weight and votersData[voter].voted attribute. It should update it and keep an up-to-date view of voteCount(s).

Needed to add metamask to the UI so we can be able to create transactions on the blockchain

• add signup button in nav bar
• create signup page
• create profile page

Change scope of functions to private in order to have them as internal APIs, and create as public/external the required ones that need the prove the identity of the voter (by account/signature).

How does Lightning⚡️fit into liquid democracy?

Deploy contract to the testnet

should LiquidDemocracy.sol have a function to de-activate the contract and refund any outstanding ETH to owner i.e. like this?

// constructor
function LiquidDemocracy()public {
contract_owner = msg.sender;
}

//deactivate the contract
function kill () public {
    //only allow contract owner
    require (msg.sender == contract_owner);
    selfdestruct(contract_owner);

}

When user has chosen a delegate by clicking on the radio button and then click on the delegatebutton it should trigger a metamask transaction. delegate function parameters are: delegate(address from, address representative)

• implement API call with web3.js and construct transaction.

For ballot X:

• (1) getters for all voters to populate possible "representatives" list
• (2) getters to get delegation data
• (3) getters to get voting data
• (4) getters to get revoking data
• (5) implement third graph area proposed by @AlexJupiter

Params for delegate() function are : delegate(address from, address representative)
Params for vote() function are : vote(address voter, uint ballotId, uint voteOption)

Currently, a single ballot is supported. In reality, there should be space for more

Read up on ERC20 dynamics, implement Truffle/Zeppelin tutorial, debug and learn

Only 2 options are currently available, hardcoded as "yes" and "no". They should be flexible, and their name/description should live outside the blockchain (IPFS, etc)

Santi has good relationships with the RSK team. They have reached out to us to begin integrating DEF with RSK and exploring possible collaboration.

Para comenzar, pueden acceder al nodo / code de RSK en el repositorio de GitHub. En el link de Getting started van a tener toda la info para conectarse a la TestNet y hacer todas las pruebas necesarias. Después de la instalación, me pasan la BTC address de TestNet y los agregamos al whitelisting para que puedan usar el RSK Bridge. Cualquier consulta o dificultad, no dudes en escribirnos y los ayudamos.

https://github.com/rsksmart/rskj/wiki

Need to dive into that getting-started, connect to the TestNet, there should a BTC address we pass to them, they can add us to the RSK Bridge whitelist after that, Henry said they can help us if we have any questions.

This feature can take from PR #7. Implementation must come with its respective tests in the corresponding test file

Implementation must come with its respective tests in the corresponding test file

Luke (Aragon) shared with us the initial Liquid Democracy specification. Currently the doc is being discussed and reviewed, we waiting on Luke to specify next steps.

@virgile-dev @herbstephens @raulk feel free to leave comments about the doc in this this thread or within the doc itself.

Delegate tab:

• Users list
• Radio button to choose the person you delegate
• Delegate button

See #9 for context. Idea is to start from a more abstract perspective and only modularize later as needed. This entails consolidating some functionality currently spread between Ballot.sol, Delegation.sol, Organization.sol, Member.sol into a single smart contract. This responds to initial architecture questions, intention is to keep things simple and allow us to stay more agile

From the Liquid Democracy Specification doc:

Giveth’s liquid pledging contracts combined with a token snapshot (either by locking token balances during the vote or using something like the minime token) can be used to allow votes to flow through delegates to a final tally. If a user chooses to re-delegate or override their delegates choice the current tally is updated. When the poll ends the values are locked in and result can be returned.

Let's look into this and learn about it.

Resources

https://github.com/Giveth/liquidpledging
https://medium.com/giveth/the-minime-token-open-sourced-by-giveth-2710c0210787

Add IPFS hash to ballot title and voter name/email

When user clicks on revoke button it should trigger a metamask transaction.

• send json to IPFS to get hash
• implement API call with web3.js and construct transaction.

Update README to represent new repo status

From IPFS:

• title
• author name
• date of creation

From Ethereum:

• number of yes votes on ballot (option1)
• number of no votes on ballot (option2)

Contextual information that we need to retrieve based on the users' eth address:

• number votes on ballot + selected option
• available delegated and not cast votes on ballots

at the moment we are sending a file to ipfs per transaction. might be more efficient to put everything in a single file that gets updated (hash would change everytime).

Might not be that accountable as it won't be as easy to retrieve info as we would break the rule 1 transaction = 1 input data ipfs hash