Open virgile-dev opened 5 years ago
Love the flexibility to set the tokens required per vote What are these transactions made of, used for?
I'm having a big internal debate on whether to by default make onchain voting and allow you to move tokens on the chain and tally that... or just use off-chain mechanism where you sign with your stake balance.... or allow customization in editor and support two options.
Even labeling the button Onchain - TOKEN
and Offchain - TOKEN
instead of Send
.
LMK your thoughts, asking you about it.
When voting on a ballot I'm sending tokens to the author's user's address (by default) or any other address (s)he might have specified. Looking at the logs when sending votes it looks like every transactions are now only delegations.
Yes.. the simplest route to launch is get every post having author's address as default.. if author wants to change address, she has that right. Plan B would be centralization: what a democracy.earth wallet holding all tokens? no thanks.
Also.. this dynamic effectively drives up delegation almost turning it into the default transaction of the system... but if we use token transactions, it's not a delegation it's a transaction. that's why I'm thinking about how we communicate this idea.. and how we implement it using code with our token at least that would allow for delegation.
Post are no longer ballots with binary options ? (Maybe we can include this in the transaction metadata)
Ballots are unnecessary. I think it's a much more flexible pattern the fact that every post is an option of itself .. so, if you want for example to have a decision being voted yes/no.. just make a post with that decision and two replies, one containing no, the other one "hell yeah". this also means the community can add options asked on a post.
bottom line is: we are doing AMA pattern for every post. hence the webapp has two views: the main feed as an infinite scroll.. and each specific posts feed which is a thread view (replies will be shown positioned on its place of the thread even in their own page).
Which results define outcome of a decision ? How post become approved or constitutional?
For the first release I'm thinkning of erasing the 'approved' and 'constitution' options.. and just leave there instead sorters that will order the feed according to the criteria of the avaialble options in each of them:
Those four metrics are really algorithmic scores for popularity, valuation, engagement and virality.
Let the user decide his/her own criteria of what to view on a democracy.
Also using this approach how can you revoke your vote / delegation in this approach?
We have to code specific smart contract functions inherent to our token for these dynamics. So we'll leave these options when we get to ship that. In the meantime token agnostic approach means we make best use of available options now.
Information is being written on Ethereum with Metamask transactions but we don't yet read the Ethereum blockchain to check the ballot count or show a voting activity stream.
That's correct, that's a big ongoing task which means how we persist votes with our existing legacy code and sync with the blockcain. I'm on it.
Hey @santisiri thanks for the clarifications.
About the specific point you raise about on-chain and off chain-voting. I'm not sure we wanna use those terms, as signing a vote with your balance is still a transaction you can make an on-chain.
First let’s list, define and name known options
Option 1 : send tokens to vote
: In order to vote on proposals user sends tokens to an address define by the ballot author. This is what we currently have in place in Sovereign.
Option 2 : balance vote off-chain
: In order to vote on proposals user signs a message with MetaMask client which specifies the option chosen and the balance of that account at given blocktime. That’s what Decentraland’s Agora is currently doing.
Option 3 : balance vote on-chain
: In order to vote on proposals user submits its vote by signing an on-chain transaction, and after the transaction has been mined, it is logged into the survey results. The transaction contains the chosen option and the user balance at a given block time (In Aragon’s case « the balance that account held one block before the survey was created »). This is what Aragon’s survey app had in place, the service is no longer accessible though.
Now let’s try to compare those options :
Send tokens to vote | Balance vote off-chain | Balance vote on-chain |
---|---|---|
Identity verification is carried out via Metamask. As simple as if you hold tokens for a given proposals you can vote. Sovereign can support all ERC20 tokens. | V | V |
Transaction is recorded on-chain, voting is thus decentralized and voting record is incorruptible | Voting is not recorded on-chain | Voting info is recorded on-chain |
Vote tally is harder and more insecure as we have to persist transactions in mongodb using Metamask callbacks | Tally is easy but centralized | Tally can be carried out in a secure and decentralized way by reading out the info on the blockchain |
User has to spend tokens and pay for gas in order to cast vote | User only signs a message with Metamask in order to vote | User has to pay for gas in order to vote |
Voting transactions and proposals carry value, but could repelling for users to spend tokens on not binding polls | Not binding for now. In this context makes senses to be off-chain | Not binding and on-chain |
Rewards authors for content published | X | X |
Tokens sent can be used to carry out proposals (address of ballot could be multisig to allow for collective action and transparency —> decentralized participatory budgeting) | X | X |
Most of the community polling / voting apps I'm seeing emerging from the space all use the same logic. You don't actually spend tokens to vote. Might be wise to at least include that logic at first so we can onboard more easily some the existing users of the apps mentioned above (both ERC20). I like your idea of leaving several options to the ballot author we’d have to find appropriate label easily understood by user. We should be careful not to introduce too much complex
Finally I iterate on my first comment I really liked the fact that in the prior version of the ballot editor you could specify the amount of tokens the user can send to vote. If we are doing the send tokens to vote
scenario it’s a must have feature IMO. In my last pull on master I noticed it was removed.
I hope this helps.
Finally I iterate on my first comment I really liked the fact that in the prior version of the ballot editor you could specify the amount of tokens the user can send to vote. If we are doing the send tokens to vote scenario it’s a must have feature IMO. In my last pull on master I noticed it was removed. I hope this helps.
Yes.. what for the sake of simplifying steps in UX with @paulamlb we thought it was better to cut out that step. All transactions are set by default to the equivalent of 0.01 USD
relative to their token decimal system (you can check /lib/token.js
to see how these where set, also nominalizing quantity to a single unit (ie: 1
, 0.001
or 0.10
).
Keep in mind that if you want to customize the transaction, MetaMask allows you to do that.. you can always edit the quantity. So keeping the freedom on the sender rather than the receiver is already there and I think a fairer deal.. plus the end-user should have sovereign control of that.
Option 1 : send tokens to vote: In order to vote on proposals user sends tokens to an address define by the ballot author. This is what we currently have in place in Sovereign.
Yes. And I think obvious simplest step that must be on this v1.2-beta
release.
Option 2 : balance vote off-chain: In order to vote on proposals user signs a message with MetaMask client which specifies the option chosen and the balance of that account at given blocktime. That’s what Decentraland’s Agora is currently doing.
Yes, I really like this approach. That's why I'm thinking what should be on the editor UX.
Token
Address
Vote with Balance
<toggle / boolean>On chain / Off chain
<toggle / boolean> Or.. this way of voting should be included as an option on every post anyway.
LMK your thoughts.
Option 3 : balance vote on-chain: In order to vote on proposals user submits its vote by signing an on-chain transaction, and after the transaction has been mined, it is logged into the survey results. The transaction contains the chosen option and the user balance at a given block time (In Aragon’s case « the balance that account held one block before the survey was created »). This is what Aragon’s survey app had in place, the service is no longer accessible though.
Anything that's on-chain should have a very clear damn purpose. We know ours.
Keep in mind that if you want to customize the transaction, MetaMask allows you to do that.. you can always edit the quantity. So keeping the freedom on the sender rather than the receiver is already there and I think a fairer deal.. plus the end-user should have sovereign control of that.
Trudat.
All transactions are set by default to the equivalent of 0.01 USD relative to their token decimal system (you can check /lib/token.js to see how these where set, also nominalizing quantity to a single unit (ie: 1, 0.001 or 0.10).
Why not making the default equivalent to a vote token : 0.12 USD which is one min of time right ? approx the amount that it takes for the all process to be completed by user (look at a proposal, click, sign, mined). After all the vote token aims to become the reference for political transaction in the crypto space. Just an idea but might be worth digging.
That's why I'm thinking what should be on the editor UX. (Token / Address / Vote with Balance <toggle / boolean> / On chain / Off chain <toggle / boolean>)
Yes let's put these config options on the editor. How you present it is a bit confusing to me. How about a tab view. (We need better labels!)
Tab 1 : "Send tokens to vote"
Tab 2 : "Vote with balance"
Why not making the default equivalent to a vote token : 0.12 USD which is one min of time right ? approx the amount that it takes for the all process to be completed by user (look at a proposal, click, sign, mined). After all the vote token aims to become the reference for political transaction in the crypto space. Just an idea but might be worth digging.
Interesting.. pegging every token in the network to our principle. Food for thought.
How about a tab view.
Never in a drop down :P ... anything that adds clicks is very expensive, will try to think it without it.
I would leave onchain balance voting for future versions.
I think we are unto something here. Thanks @virgile-dev for clearing my mind with this.
@virgile-dev I would argue that while we can't give access to $votes as a human right yet, we must do everything we can to make the platform as accessible as possible. also the lower the cost the more value we are providing with our software.
@santisiri congrats on this iteration ! There are lots of improvements here:
Questions around the Web3 transactions
Each post displays an etherscan transaction link. (Example: https://etherscan.io/address/0x883e2ab87033183d2ddab245f0678c64328290cb). Several post can have the same transaction id.
Love the flexibility to set the tokens required per vote
When voting on a ballot I'm sending tokens to the author's user's address (by default) or any other address (s)he might have specified. Looking at the logs when sending votes it looks like every transactions are now only delegations.
Information is being written on Ethereum with Metamask transactions but we don't yet read the Ethereum blockchain to check the ballot count or show a voting activity stream.
Questions around permissions
One can restrict the voters universe to a domain on the other hand I noticed that we no longer ask for emails when signing up.
Or maybe we could ask for the users' email after the Metamask signature and verify authenticity sending them the classic "Confirm your email by clicking on the link?". This way we will have the possibility to notify users of platform activity.
When drafting a post a user can choose from a list of
voting tokens
, I noticed that BTC was part of the list.Again looking at @LucasIsasmendi who's woking on a multi-currency wallet 😉
What's left to do for next release?
Let's try to collaboratively edit that list in this issue first which we can turn in a gh project or an epic later on. After we're a done fine tuning the new specs, should we go over the issue and make a big cleanup closing non-relevant ones like we did back in march this year at Blockstack berlin?
[ ] Connect Sovereign to Ethereum with an API to keep updated ballot count and feed the
Recent votes
andDelegates
sections (@LucasIsasmendi has been doing a lot of that in his work I'm sure he can help).[ ] Define rules for ballots to be
approved
andconstitutional
To explore
As mentioned by @medied it might be a little heavy to ask user to sign a transaction with Metamask everytime they vote. We can complete this list together 😊.