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