RE: SteemPoll v2 beta release and improvements poll
How about a metric based on the MVESTS of the accounts (not delegated, but the amount actually owned) that upvoted (by any positive percentage) the option as of the time that they voted? Even with payout declined (I know 2 of the options didn't decline payout because of a bug) I don't think users should have to waste their voting power to vote on a poll. And a MVESTS metric would help the community understand what stakeholders in Steem think about certain issues in a way that actually corresponds to what changes may actually be approved (via witness voting for future hardforks for example). With this metric, however, it would be wise to close the poll within 7 days to avoid abusing poll results by moving Steem Power around to other sockpuppet accounts (for that matter the existing shares metric would also be vulnerable to that if the poll was open for several weeks). Speaking of which, there is no current capability to have the poll end by a specific date (and have the tallies frozen in steempoll.net at that time), is there?
By the way how do you handle the situation where a vote is removed (or downvotes for that matter)? In the case of the MVESTS metric proposed above, you would have to record the MVESTS at the time of voting for each vote so that if they were to later remove their vote you could properly deduct the right amount from the tally.
Thank you for input @arhag!
For now participation is major factor, we want user to be able to participate without hassle of using other site, but use what UI they are daily using. And vote with ease. Initially when I proposed bit different changes and plan was to use custom_json and have custom built-in voting mechanism and that in itself is not difficult task, but participation would be difficult. Current model is still not perfect and requires voting power! But poll owner/creator basically can decide what factor they want to make decision from (vote count means net votes, reputation is average reputation of voters, stake is delegated one for that vote). I am thinking to use external db (steemsql, steemdata) to get account stakes which should be easier than making dozen steemd requests for each account, that should be much better representation of Stake chart. db can also be used for deadline oriented polls to close data collection. I am really looking forward for more input and perhaps find better way of increasing participation. I have also thought of iframe embeddable polls but those are not reliable and secure. What would you propose to increase adoption and easy usage, participation? I thought of having token and giving them out to incentivize the participation, poll creators would create market for that token, still not sure if that would be viable.
Yes, I understand why you designed it this way. But if I understand correctly, the only metric that isn't Sybil vulnerable right now (well at least within a narrow time window like 7 days) is the Shares metric, which depends not only on the user's MVESTS but also their voting power at the time they vote and voting percentage they choose for the vote. A metric based only on MVESTS, although a little harder to calculate than Reward Shares, means that users can vote on each option of the poll with 1% voting weight (like I did for the option above) and have their vote fully counted while wasting the least voting power (actually technically voting weight of 0.01% would be the least allowed amount but the steemit.com UI currently does not allow that level of precision).
Yes, I think the DB approach is the right way to go. I think it would be nice to eventually have iframe embedded polls with nice UI. I'm not sure why you are saying that it wouldn't be secure. The problem with that, however, is that steemit.com and every other client would need to whitelist the domain. Another option that may actually be better could be to come up with a standard for describing various types of polls that Steem clients can adopt. The data, following the standard, that describes the poll could be encoded in JSON and set as a value to some attribute in the
divrepresenting the poll that you already ask the user to embed in the post. Then supporting clients (you could start with enabling it on eSteem and then if it gains popularity maybe steemit.com and other interfaces will also adopt it) could read that data and generate the poll UI, while non-supporting clients would just ignore thedivas steemit.com currently does. Even in non-supporting clients, users could always still vote manually on the comments as I did, or alternatively use your external website (in fact you could put a link to the external website hosting the poll within thediv, and for supporting clients they would simply render the poll UI rather than rendering the contents inside thediv). It would be important to define an appropriate and well documented standard for the polls and add versioning support so it can be upgraded over time without breaking clients that have not been updated to support the new version by having them think they can render the UI of a poll using new version features when they really cannot and should not.Personally, I am not a fan of the added complexity of a token. Perhaps if/when Community Tokens (CT) are supported on the Steem blockchain it will make sense to integrate support with those for the polls (for example polls weighted based on the amounts of a particular CT the voting accounts hold), but prior to that I am not sure it would add any value to add tokens into mix in terms of helping adoption or ease-of-use.
By not secure, I meant
iframeinjects the script that can be hacked and it is very sensitive subject. But you are right, if whitelisted it can be implemented. Communication between an iframe and parent document is not always possible, they should be within same cross-origin...there are some workarounds but I believe those communication layers are not supported by all browsers, which limits its usage to view only. I believe view only is useful to see statistics/result of the poll...