RE: Open Polls Protocol - Initial Version

[ecency]

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"
  }
}

Comments

[ecency]

@borislavzlatanov, you are working on this? ^

[borislavzlatanov]

Yes. Would you be interested in implementing a polls feature?

[ecency]

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.

[borislavzlatanov]

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_type field 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 right content_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.

[ecency]

Looks like API has different structure than what you have on this post.

1. Which preferred interpretations work right now?
2. How to get status active, status expired polls separately?
3. How to get if poll exist in given author/permlink?
4. What is the structure of polls in API?
5. Is it final or still in progress API that changes constantly?
6. Is it possible to run indexer separately or it is designed to be run by full node providers?

We would like to create our own indexing for polls also so there is redundancy for fallback in case one API is down.

[borislavzlatanov]

1. Right now the "number_of_votes" works.
2. I will add the ability to get polls by status.
3. I will add the ability to search polls by author. Does this seem enough?
4. You can see the individual poll structure like this: https://polls.hivehub.dev/rpc/poll?trx_id=85ab0df74e186c2184d43da608b40f86c66f72d4 When we have token balances, it will also show the total HP (or Hive Engine token) voting for each choice.
5. It is still in progress, this is just a first working prototype. But we don't want to make breaking changes (unless we really have to) that would create work for frontends to accommodate the changed structure.
6. There is a very small backend node which will be made open source. It fetches the polls data, validates, calculates the interpretations, and provides the API. So absolutely, multiple people will be able to run such a node so that there is redundancy.

[ecency]

I will add the ability to search polls by author. Does this seem enough?

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?

[borislavzlatanov]

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 with content_type in 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_type can be poll, and in the future we can have job-opening, product and 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: {}.
• action in 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, whereas polls seems 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.

[ecency]

end_time better wording perhaps expires, content_type could stay as an expansion idea I agree. preferred_interpretation just interpretation conveys the same meaning I think.
Filters and actions still over complicating the system, imo.

Which token data - the user's token balance?

Yes, as it is easy for UI to fetch and send that data instead of backend handling it which wouldn't be optimal.

[borislavzlatanov]

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.

[ecency]

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. 🤔