litentry / squid

Litentry's Squid is a multi chain data indexer for Substrate based networks
Apache License 2.0
4 stars 2 forks source link

Additional data requirements for democracy proposal and referenda #118

Open ishrak-imam opened 2 years ago

ishrak-imam commented 2 years ago

Bases on what is currently displayed in the app following are some of the extra data requirements.

Referenda:

markdavison commented 2 years ago

Not sure what the use of the count of accounts that vote aye or nay. An account can split vote between aye and nay (goodness knows why)... but I think it means that fundamentally the number of accounts does not matter... it is about the staked value.

I see no issues with the other points. Will need to do some investigation to figure out how to get the dates .

ishrak-imam commented 2 years ago

Not sure what the use of the count of accounts that vote aye or nay. An account can split vote between aye and nay (goodness knows why)... but I think it means that fundamentally the number of accounts does not matter... it is about the staked value.

Your reasoning is justified from the point of one account being able to split vote. But at the same time "x amount of staked vote value is coming from either 10 or 1000 participants" this particular information could be important to the next voter.

I see no issues with the other points. Will need to do some investigation to figure out how to get the dates .

For end period and activate period, these are blockNumbers. So to figure out relative date (from now) form block number we will need the current block and that we can process in the custom resolvers of the litentry graph. Just returning the block number might also be ok.

markdavison commented 2 years ago

Your reasoning is justified from the point of one account being able to split vote. But at the same time "x amount of staked vote value is coming from either 10 or 1000 participants" this particular information could be important to the next voter.

But I think the reason for showing vote based on staked value is that there is no way of knowing how many people are voting. I could have 10 accounts and vote with each one. Its easy to do... but I wonder how useful it is.

How should a split vote be represented?

How should someone who votes one way and then changes their mind? (Only their last vote counts... so presumably it should represent their last vote).

silva-fj commented 2 years ago

But I think the reason for showing vote based on staked value is that there is no way of knowing how many people are voting. I could have 10 accounts and vote with each one. Its easy to do... but I wonder how useful it is.

Well, I think we are talking about two different things here, the staked value is used to determine if the proposal will be approved or not, but it does not represent participation.. Having both, staked value and participation (unique accounts that have voted) are important in different ways for us.

How should a split vote be represented?

I would say it should be represented as it is, same value for both

How should someone who votes one way and then changes their mind? (Only their last vote counts... so presumably it should represent their last vote).

That's correct, the last vote should be the one that counts. This is not an issue that needs to be resolved in the indexer, it should be resolved in the graph.. Eventually we will have some limitations when querying data from the indexer and we will have to do similar to what web3go does, talk with the database directly.

markdavison commented 2 years ago

Well, I think we are talking about two different things here, the staked value is used to determine if the proposal will be approved or not, but it does not represent participation.. Having both, staked value and participation (unique accounts that have voted) are important in different ways for us.

But I don't think the number of accounts necessarily represents participation - one person could have 100 accounts or 100 people could vote with one account. I think fundamentally the design of referenda voting ignores the number of accounts for this very reason.

I would say it should be represented as it is, same value for both

If they vote 10% aye and 90% nay we should add 1 to aye and nay?

silva-fj commented 2 years ago

But I don't think the number of accounts necessarily represents participation - one person could have 100 accounts or 100 people could vote with one account. I think fundamentally the design of referenda voting ignores the number of accounts for this very reason.

Don't think about people, think about accounts and votes.. If it was one person with multiple accounts, it does not matter to us. We just care how many accounts have voted (only for this particular bit of data we show in the app). We also show the staked value which matters the most.

I would say it should be represented as it is, same value for both

If they vote 10% aye and 90% nay we should add 1 to aye and nay?

Yep