WHAT IS IT: A way to vote (do a poll) on hive that every single UI can easily integrate and which has advanced analytics features and multiple voting qualifications and filters.
A little while ago we announced the development of a decentralized polls and voting system for Hive. As the various pieces are gradually being built (we are progressing on fetching of polls data from the blockchain and providing them in an API), today we share with you the protocol specification for this system.
As a reminder, Hive Open Polls are meant to be decentralized and able to be (and we will encourage them to be) integrated into as many (hopefully all) Hive based UIs. They will also focus on ways to analyze the data based on factors determined by the poll creator.
UI VS PROTOCOL
The UI for the polls is already being developed by another developer and moving right along but this post today will focus on the backend protocol. However regarding the UI it will be first integrated into Hivehub.dev and we look forward to seeing what other websites do and if they want to use this open source UI or adapt it to something else for their site.
What does this polls system allow people to do?
People will be able to create polls, define choices, and let others vote on these choices. You can create a poll for everyone on Hive to vote on, or it can be just for your community's members, or just for the holders/staker holders of a token (or other criteria). Whether you want to make polls for fun, or you want to vote on governance decisions, the polls system is intended to serve all those cases.
It is also planned that later versions will allow voters to propose/submit their own choices beyond the choices the poll author added, so that there is decentralization also in the available choices that people can vote on. This can also enable functionalities like people submitting requests (for example, a request for a feature to be added to a product) and others voting so as to prioritize among all the submitted requests.
One possibility this can create is for the decentralized Hive community to collectively discover which features, capabilities and activities it cares about or wants the most, so that work can be done towards those.
Various other use cases for the polls system will be possible. We would be very interested and it will actually help inform the way we work on this project so please share your own ideas for how something like this system can be used for you and your projects/interfaces/communities.
What does this protocol do?
It specifies the rules for how the polls and voting will work. By following the same set of rules, everyone can participate and use the same polls system.
This is an initial version of the protocol, intended to get started without too much complexity. It is planned to expand it with various settings for the polls and so on.
Please share any feedback in the comments below.
The protocol follows.
Hive Open Polls
Decentralized polls software and an open polls protocol for the Hive ecosystem.
How it works
The Hive blockchain provides a way to store immutable data. Accounts can add data formatted as polls and poll votes, according to a mutually agreed upon open protocol. Anyone can spin up a polls API node which collects the polls data in a more standard database, interprets it according to the protocol and makes the interpreted data readily available to apps and frontends. All of this constitutes a decentralized polls system.
Hive Open Polls Protocol - Specification
The protocol has versions, such that the software implementation can apply the correct protocol rules according to which version was used when a poll author created a poll.
The protocol is designed to give poll authors and voters options to create and participate in polls in the way they wish to. The protocol does not specify which options or procedures should be followed in any poll but rather which options and procedures are available to choose from.
Current Version - 0.1
Polls
A poll is a regular Hive post (root comment). The post's json_metadata field is used to define it as a poll. The json_metadata field contains a json object such as the following:
{
"content_type": "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+"],
"preferred_interpretation": "tokens",
"token": "HIVE:HP",
"filters": ["account_age": 100],
"end_time": 1699373655
}
Where:
content_type defines the post as a poll
version specifies the Polls Protocol version. The poll and any votes on it will be interpreted according to the version specified here, at poll creation.
question contains the poll question
choices contains an array with choices (answers) that can be voted on. The array order is fixed at poll creation and cannot be changed. When accounts vote, their votes are recorded as the choice number in the array.
preferred_interpretation specifies the decision mechanism the poll author wishes to use for determining the poll results. It can be one of the following:
- tokens: choice support level is determined by how much tokens the choice voters collectively have.
- number_of_votes: choice support level is determined by how many accounts have voted for the choice.
token specifies the token to be used for the voting calculation. The field contains the chain or layer 2 followed by the token name, for example:
HIVE:HP,SPL:SPSP,HE:SWAP.HIVE. Required when the tokens option is selected for preferred_interpretation and not applicable otherwise.filters contains filters or requirements that accounts have to meet in order for their vote to be counted towards the poll results. In array format. Can be one or more of:
- account_age: the minimum account age, in days, at the time the account casts a vote.
end_time specifies the time at which the poll ends. Votes made afterwards don't count towards the poll results. In UNIX timestamp.
Utilizing a regular post as the poll offers multiple advantages. It allows the poll author to add any text and multimedia in the post body along with the poll. This ability to expand on and describe the poll's question becomes especially relevant for polls asking people to vote on decisions of importance. Since a regular Hive post is used, the poll also benefits from being integrated into communities, post feeds, account profiles and so on. It also enables people to post comments under the poll's post.
Once a poll is created, it cannot be changed. Changes to the metadata that define the poll are ignored. If a poll author wishes to change any of the poll settings or choices, they have to create a new poll. This avoids issues where people vote on a poll and afterwards the poll is changed. The post body, however, can be changed in the standard way a post is edited. This allows a post author to edit the accompanying text/multimedia so as to clarify any aspect of the poll. At the same time, the blockchain keeps each version of the post which gives poll participants the ability to see how the post body was changed during the duration of the poll.
Poll Votes
A poll vote is a custom_json operation such as the following:
{
id: 'polls',
json: {
"poll": "1a2b3d4e",
"action": "vote",
"choice": 1
}
}
Where:
- id serves as the unique identifier of the custom_json operation
- poll refers to the poll for which the vote was placed. This field contains the transaction ID of the comment operation of the poll post.
- action contains the activity performed on the poll, in this case a vote
- choice specifies the poll answer which is being voted for. This is the answer number from the poll's choices field, starting the counting from 1.
A voter can change their choice by making a new custom_json operation for voting on the same poll and specifying a different choice number. The new vote replaces any previous votes on the poll - any previous votes are simply ignored. If a voter wants to remove their vote rather than change it, they can specify 0 in the choice field.
QUESTIONS?
If you have any questions let us know. And like we indicated in the post please share your future use cases with us so we can help educate our future work on the project.
The Scholar & Scribe team has discussed using staked SCRIBE or SCHOLAR tokens polls to run 'Users Choose The Adventure' stories. @thinkrdotexe ran something like this manually, using comments as the votes. But having the L2 community tokens involved at a functional level would be reallllly neat.
Based on what's been described here, I think that this use case is already "ready" since it's pretty simple, but thought I'd shared anyway. 😀
That's an awesome idea! I love it
This would be great for zing stakeholder polling as well!
For sure! It basically gives an instant utility boost to every stakeable L2 token.
Yes, indeed. Enabling poll voting based on staked Hive Engine tokens (as well as other L2 sidechains that are in the works) is planned. Hopefully, this will enable a wide variety of use cases and experimentation with governance, and give each token/community a way to organize itself in whatever ways it wants to.
Awesome! A long time needed Feature on the Hive Blockchain and i like the Solution to bring it to the Protocol so other Dapps/Frontends can easily integrate it in to their application.
Some ideas i directly i have in mind for the filters to widen up the range of usecases:
cant wait to play with it / try to break things. hit me up for testing guys!
Awesome!!!!
Edit: Maybe add up a Pre-Check if the User met all the Requirements before posting the json to chain.
Edit 2: Filter Up by Follower. People can only Vote if they follow you.
Edit 3: People can only vote if they were active in the last 30 days in a specific community.
I agree that it sounds very interesting, but in my eyes HIVE reputation hasn't any meaning at all.
Or also (and maybe most of the time more reasonable) if YOU follow THEM ... (otherwise everybody could just decide to follow you for a minute, vote, and then unfollow you again - of course you could set a criteria of a min duration of following you).
Most important, however, is that there will be poll options in which not only money matters - so I fully agree with you that it could become a very nice tool.
Indeed. One possibility will be that anyone can create a token and distribute it according to whatever algorithm or system they desire to use or to experiment with. This will then become the voting power or decision-making influence that people have. This can perhaps help us find other paradigms beyond proof-of-work and proof-of-stake (even if technically you have staked a token, you may have received it not because you locked in money but because you e.g. made a certain kind of contribution that was recognized by the community).
Great suggestions, thank you. Some will be more difficult to do than others.
Do you mean that if someone upvotes the post, then the upvote would count as a vote on the poll?
Yes, it would be good for better user experience if the frontend can let the user know if all filter requirements are met, or if not, which ones aren't. But, of course, we cannot prevent users from posting a custom_json if they want to do it manually. If it doesn't meet the filters, we will just ignore the custom_json.
All of these filters would have to be done at a level outside the blockchain: The application backend or the application front-end.
LeoFinance had polls in Threads, but I believe that is not currently available. Are you coordinating with them on this feature? We need such things to work across dapps.
I hope the various teams are talking. I know there has been some communication via the Town Hall calls.
We looked at the various efforts so far at creating polling systems on Hive. And then we decided to work on an open protocol which nobody owns and has nobody's brand, and could be easily implemented by all frontends.
Another aspect of this is that for more substantial governance voting, a full post would allow for presenting with more elaboration the matter being voted on. The post is also integrated with the communities functionalities. It allows for more structured commenting underneath the post. And so on.
I remember InLeo reps talking about implementing stake weighted polling a while ago. Not sure where they are on that though!
Not super likely, I'd guess. There are a lot of little silos in Hive... natural human behaviour. I'd be happy to be proven very wrong though. And I am aware of several collab efforts, I just doubt it's the norm.
Given how small Hive is we can't afford too much incompatibility. It's going to save work to use what others have already designed. We shall see.
Some feature adds to consider—some of this may already be in the protocol (my fault if I overlooked):
Various kinds of analysis are definitely planned.
Showing and hiding things will definitely be possible. Those who want to can dive into more detail.
Hmm, haven't thought of this. How do you think it could be useful? Let's see if more people will be interested in something like it.
Possibly in a case where I want to work on building hype for a poll, but I don't want a trickle of early votes to sway anyone. Set a time and time limit to vote, so that it all happens within a controlled time frame.
I doubt this is a massive in-demand use case though—agree with gauging demand from people first :)
Great stuff! Is this already integrated into PeakD?
Not yet. Hopefully soon.
This makes a ton of sense! Thanks for the work on the project :)
Handling will be done on HAF level or is it just set the standard and provide some toolkit?
Yes, the backend is built as a HAF app.
dope
Posted via D.Buzz
We would simplify this by removing
end_time,content_typeandfilters, renamepreferred_interpretationto plaininterpretation. 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 itjson_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,actionis 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.
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. 🤔
Thanks for this - its a really important feature for a variety of reasons.
My 2 cents: There is a general issue with the visibility of historic posts on Hive sites (and web 2 sites too) - finding older posts is more difficult than it needs to be. With that in mind, it would be great to have pages/areas added to the main peakD UI to both help us discover other people's polls (a page or filter for polls) and also to look at the results of our own older polls (e.g. a new area in the 'dashboard' area).
If I run a series of identical polls over time, it would be necessary for me to both easily locate the series of polls and also to combine the data from them easily, perhaps into graphs. This is something that I have never seen on any poll systems in web 2 sites and it wouldn't be difficult to add to Hive sites at all.
Thanks for the suggestions, and the ability to find and visualize polls will be quite important, for sure. We would want to implement this on the backend, as much as possible, so that all frontends can easily add the same capabilities.
Excellent, good to hear, thanks.
I think the introduction of a group field for the poll creation operation (in that metadata) would solve this issue nicely.
Great! Shared this on the HiveToday X feed.
Hopefully, these projects will be successful and apply in eakD
The Hive.Pizza team manually curated this post.
Please vote for pizza.witness!
Congratulations @peak.open! You have completed the following achievement on the Hive blockchain And have been rewarded with New badge(s)
Your next target is to reach 7000 upvotes.
You can view your badges on your board and compare yourself to others in the Ranking
If you no longer want to receive notifications, reply to this comment with the word
STOPWell done