RE: SteemPoll v2 beta release and improvements poll
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 div
representing 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 the div
as 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 the div
, and for supporting clients they would simply render the poll UI rather than rendering the contents inside the div
). 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
iframe
injects 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...