We would simplify this by removing end_time, content_type and filters, rename preferred_interpretation to plain interpretation. Also interpretation kinda already does the filtering, end_time could be when post payout which means 7*24 hours from time of publish, so no need to over complicate the logic. Also this json should inside json_metadata, not entire json_metadata but part of it
json_metadata:{..... poll: {} }
{
"version": "0.1",
"question": "How many polls do you want to see per day?",
"choices": ["Less than 1", 1, 2, "three", "4-ish", "V", "six", 7, "e8t", "nine", 10, "10+"],
"interpretation": "tokens",
"token": "HIVE:HP"
}
Also would be beneficial if UI sends token data at the time of casting. custom json id could be just poll, action is unnecessary. Also perhaps instead of poll id, use author/permlink as it is already part of unique post?!
{
id: 'poll',
json: {
"author": "demo",
"permlink: "test",
"choice": 1
"extras" : "200000 VESTS"
}
}
@borislavzlatanov, you are working on this? ^
Yes. Would you be interested in implementing a polls feature?
Yes, we are working on Polls feature, thought it would be good to use similar approach like you guys proposed, suggested few simplifications. Why keep it simple without considering other future expansions, because you cannot simply think about future use cases in details. Content_type for example, unnecessary logical complication in code, when you add different content types, you will have to re-think entire json structure again anyway.
OK, great. We have a first functional prototype of the polls API, which any frontend can plug into: https://polls.hivehub.dev/rpc/polls
The point is that we can all use the same system instead of everyone building the same feature separately. One polls system for all of Hive - the same polls will be available and can be voted on from any frontend. Together we can make something better that everyone can use. And you can save yourself the time of creating something that has already been created, if you can simply use it and given that it does everything you need, do you think?
Yes, of course, you cannot think about future use cases in details, but you can develop things with future flexibility and general (not detailed) use cases in mind. Thinking in advance can save a tremendous amount of time later on. We are of course not thinking about the whole json structure - I absolutely agree that would be getting into too much detail and unnecessary. But just making a standard
content_typefield which can be used (and it already is used by various apps) to specify the type of content can really help development, actually. Because when we pull data from HafSQL, we want to pull only the posts with the rightcontent_type, so it really makes it easier this way. But if you want to implement these polls, you don't have to do this yourself, you can simply take the data from the API and all that work is already done for you - the polls are there, validated, and the results interpreted.Looks like API has different structure than what you have on this post.
We would like to create our own indexing for polls also so there is redundancy for fallback in case one API is down.
Imagine someone opening post, then you would want to fetch author & permlink combination. Both for stats as well, you won't know trx_id from front-end hence my suggestion was to use author/permlink.
Could you please update post with latest format for both poll and action you guys are using, so we can design our indexer to work same way?
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.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.poll, sure. It seems more polluted already, whereaspollsseems unused. And it seems to better refer to the Open Polls Protocol.Which token data - the user's token balance?
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. 🤔