voteflux / digipol

An app to allow Australian Voters to vote on current issues and bills in the parliament.
https://digipol.app
GNU General Public License v3.0
60 stars 9 forks source link

Getting more info in the members/api resplose #109

Closed KipCrossing closed 4 years ago

KipCrossing commented 4 years ago

@XertroV When hilling "https://api.blockchain.suzuka.flux.party/members/api" with 'method': 'ballot_publish'

Could I get more back than just the billCreationTxid? It would be good to also get the:

XertroV commented 4 years ago

No. The API will ALWAYS return the MINIMUM information, and will only return things which were 'chosen' by the handler (like txid)

  1. The API would just do the same work the client should do anyway (i.e. it still needs to make the web3 calls) so you're just moving where it's done
  2. The client needs to look up that stuff ANYWAY to be secure
  3. Once web3 stuff is working it should be trivial to add equiv of const blkNo = (await w3.eth.getTransactionReceipt(txid_1)).height so moving the work doesn't do anything but hide problems (note: don't know why you'd care about the block height anyway; reorgs are still possible for example, so the answer from API are not authoritative)
  4. ballotID is also decided by SC, not API, so any response is not authoritative, plus the ballotID should only ever be a (convenience or implementation) detail, the specHash is the definition of what we're voting on, so should always be the anchor point
XertroV commented 4 years ago

Addendum: when moving quickly like we are, the only real "hard no" type thing to implementation is unsafe architecture (which would also have highest techdebt). Like relying on the API returning things could mean lots of refactoring later.

The way the system should work from a redux-esq PoV: (at least this is how I've done it)

  1. Load democ-level parameters (index address, democ hash, etc) so the mutation / data added to state would look like: => {_networkParams: NetworkParams}
  2. Enumerate ballots => {specHashes: Set<bytes32>}
  3. Get details of each ballot => {ballotSpecs: Dictionary<bytes32, BallotSpec>}

So most/all of the functions to do with voting-level ops should basically take the networkParams (note: can be omitted with some designs), a specHash as their second param, and then operation-specific stuff

KipCrossing commented 4 years ago

Looks like hexlify doesn't take str:

Error pushing to chain: a bytes-like object is required, not 'str'

['  File "/home/kipling/Programs/voting-app-api/update_ballotspecs_db.py", line 75, in update_ballotspecs\n    "specHash": render_spec_hash(id),\n', '  File "/home/kipling/Programs/voting-app-api/update_ballotspecs_db.py", line 69, in render_spec_hash\n    return "0x" + ("00" * (32 - len(_s)) + hexlify(_s).decode(\'ascii\'))\n']

CONTINUING