Great, thank you for looking into this and providing feedback. Any opportunity to simplify things is good. Let's see if we can. This setup was made so that it can allow more features to be added in the future.
Let's go over what you mentioned one by one to see if it makes sense how it is currently specified or we can improve.
end_time- it is not meant to be the same as the post payout time. Someone creating a poll may decide to have the poll running for 30 days, or one year, or without end. So this field allows for that.content_type- we can remove it, sure. But the point is to have a unified standard for all of Hive. Make a post withcontent_typein the json_metadata, so all frontends know how to recognize that it is not a regular blog post. HafSQL has also added an index for this.content_typecan bepoll, and in the future we can havejob-opening,productand so on. Let's think about how to create standards and processes for all of Hive, to facilitate future growth and ease of development.filters- this field gives the ability to add various kinds of filters. The one we have already is a restriction on account age - votes of accounts under the minimum age will not be counted. There are also filters planned for membership in a community and so on. So poll creators can pick any filters they want.preferred_interpretation- indeed the name seems too long. The point is to make it clear that this is the interpretation preferred by the poll creator. But it is planned to add to the UI the ability to see other interpretations. For example, the poll creator chose to interpret votes by HP, and to filter out account under 1000 HP, but the UI will allow people to see what the poll results would have been if there was another interpretation and other filters chosen. This can help with decentralized governance decisions. For example, there is interest from the Splinterlands community in using this system for making and voting on proposals.- There can still be any arbitrary fields in the json_metadata besides the poll fields. So it doesn't restrict from adding anything. But if for some reason it would be better to nest all the poll data under its own field, then we could do that, for example
content_type: poll: {}. actionin the custom_json gives us flexibility for other actions in the future. One planned action is to add new choices to a poll. It is planned to make a poll setting that allows users to add choices to the poll.- custom_json id could be just
poll, sure. It seems more polluted already, whereaspollsseems unused. And it seems to better refer to the Open Polls Protocol.
Also would be beneficial if UI sends token data at the time of casting
Which token data - the user's token balance?
Also perhaps instead of poll id, use author/permlink as it is already part of unique post?!
Sure, probably a bit of a matter of taste whether to use trx_id or author/permlink. One consideration is which one would be shorter (so that we keep blockchain bloat to a minimum, as much as possible), and trx_id would seem shorter on average.
end_timebetter wording perhapsexpires,content_typecould stay as an expansion idea I agree.preferred_interpretationjustinterpretationconveys the same meaning I think.Filters and actions still over complicating the system, imo.
Yes, as it is easy for UI to fetch and send that data instead of backend handling it which wouldn't be optimal.
But then the user can just manually submit a custom_json with whatever token balance they want, no?
The backend has to get the token balance of the user, and it has to do it at the time the poll ends. This way the backend stores the poll results (all user votes and token balances) at the time the poll ends.
Yes, you are right, user could submit modified balance. Backend should have stake/balance realtime that's why I thought UI submitting would be more effective. Avoid manual entry, backend can check/process maybe during storing vote into db. 🤔