You are viewing a single comment's thread from:

RE: Open Polls Protocol - Initial Version

in HiveDevs8 months ago
  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.
Sort:  

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?

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?

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.

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?