Functional questions regarding upcoming release

[virgile-dev]

@santisiri congrats on this iteration ! There are lots of improvements here:

• the simplified UI looks great
• the threaded comments bring a lot of clarity
• the app is running faster !
• the multi-token integration is looking great
• permissions are looking great too
• the integration with Metamask is really great
  👏👏👏

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

What are these transactions made of, used for?

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.

Can you explain your thinking here ?

Post are no longer ballots with binary options ? (Maybe we can include this in the transaction metadata)

Which results define outcome of a decision ? How post become approved or constitutional?

Also using this approach how can you revoke your vote / delegation in this approach?

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.

Correct?

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.

Should we hide this possibility for now ?

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.

Should we only display Ethereum tokens for now since Metamask cannot interact with non ethereum crypto-currrencies?

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 and Delegates 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 and constitutional

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 😊.

What other options can we explore?

• Ethereum events ?

[santisiri]

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:

• Most Voters (this means sorting list by item with most individual voters or one person one vote view)
• Most Valuable (ordered according to the quantity of tokens on each)
• Most Replies (most debated)
• Most Tweets (most shared).

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.

[virgile-dev]

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.

[santisiri]

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.

[virgile-dev]

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"

• Token (list)
• Address (I think we should signal when the address is the author's and when it's something else, giving an opportunity to explain where the funds go. Don't you ?).

Tab 2 : "Vote with balance"

• Token (list)
• On-chain / Off-chain (binary option)

[santisiri]

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.

• Token (list)
• Toggle: Vote with Balance / Send tokens to Vote
• Address options appears if sendtokens set to true..

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.

[paula-berman]

@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.