RE: Open Polls Protocol - Initial Version

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

Comments

[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]

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.

OK, we can switch to author/permlink if that would indeed be easier. I was imagining the frontend would show the feed with posts, and would in advance show that a certain post is of the type poll. So the polls would be in the same feed and would be designated as such by the frontend, even before the user opens any one poll post. But in any case, we can change to whatever will be the easiest to work with for frontends, no problem to do that.

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?

I think it will be best to open the code repository so that the latest version is always there for reference. I will discuss this with the team. But why do you want to create your own indexer instead of simply running a node with what we've already created?

[ecency]

I think it will be best to open the code repository so that the latest version is always there for reference. I will discuss this with the team. But why do you want to create your own indexer instead of simply running a node with what we've already created?

Is it ready? What is hardware requirements? We already have indexer, for us it would be easier to add this change but if codebase is ready and stable, then we can run your code as well. It is not a big deal really.

OK, we can switch to author/permlink if that would indeed be easier.

From your examples, yes you can see that author permlink combination is easier regardless. That's why initial suggestion was to use that instead of transaction id.

[borislavzlatanov]

The repository is now open, here it is: https://gitlab.com/peakd/hive-open-polls/-/tree/standalone (the standalone branch is where the most recent work is happening). It is currently functional. It's built as a HAF app which can run on a HAF server, or it can run on its own without needing HAF or hived.

It not only indexes but also implements all the logic of the protocol, checks the validity of the poll to ensure it conforms to the protocol, allows post title and body updates but no changes to the poll question and choices, allows voting and changes/removal of votes but only up until the poll's end time (if specified), calculates the interpretation of results, checks for filters and filters out the accounts that don't meet the filter criteria, and so on. There are various pieces of logic which will grow as the protocol expands and more poll types are enabled (multi-choice, etc.).

The server requirements are extremely minimal, it is a super small app. 1GB of RAM would be plenty, and the app's docker image is something like 600MB.

Would you like to give it a test run?