This is what I have come up with, as a starting point for discussing a Hivemind polls implementation. If anyone has alternative implementation methods, techniques, suggestions or questions; feel free to share. This is an open discussion :)
I define a poll as having the following elements:
To allow formatting flexibility (BOLD, ITALICS or even HTML), the message can be put in the body field of the post. Perhaps a max length check can be enforced, to avoid polls that are too lengthy. The title field can be blank. It's not necessary.
body: Will you buy STEEM this week?
permlink: poll-* not enforced, probably [timestamp] for consistency, but it's not a hard rule. Any permlink will work.
The poll's options can be placed as a list of string values, in the post's properties JSON metadata key, which is a dict, as shown in the next section's example.
Comments on polls can be made in the usual parent-child relationship.
I propose introducing a pair of keys in a top-level post's JSON metadata to trigger creation of polls in DB; which also makes the process of developing other post types in the future more methodical.
A type key to define the type of post.
A properties key to define the characteristics associated with that post type.
An example post's JSON Metadata:
{
"app": "steemit\/0.2",
"format": "markdown",
"type": "poll",
"properties": {
"options": ["Yes", "No", "Already bought some"],
"allow-comments": false
},
"tags": ["steem"]
}
To interact with polls, a user can submit a custom JSON op.
pollVote: when selecting an option for a poll, for example:
id = "community"
[
"pollVote",
{
"community": "hive-133333",
"account": "imwatsi.test",
"permlink": "poll-2019-12-31-235959",
"option": 1
}
]
Note: polls and votes are write-once only. Allowing modifications after they are published compromises the integrity of results. For example, changing the poll message or options may invalidate all answers made prior to that modification.
I've also been thinking about allowing custom input as an option. In this case, you might add (for example) "custom-option": "number" to properties when creating the poll, so that the user can answer the poll with their own number. Or "custom-option": "0-10" for a numeric input between 0 and 10.
To me, custom options only make sense as numbers. Free text will, in most cases, produce data sets with wide ranges, that become difficult to collate for the purpose of quantitative analysis. It doesn't seem like much of a value add, and there are better ways to get opinion data that is not quantified (discussions, for example).
So for now the custom-option is limited to numeric inputs, but free text can be supported if reasons to do so arise.
We could also enable poll creators to allow or disallow comments on their polls. A simple allow-comments boolean key in properties can achieve this.
To cater for polls, I propose adding the following tables to the hive DB.
CREATE TABLE hive_polls (
post_id integer PRIMARY KEY REFERENCES hive_posts (id),
options varchar(100) ARRAY NOT NULL,
custom_option varchar(10),
allow_comments boolean NOT NULL DEFAULT true
);
CREATE TABLE hive_polls_votes (
account_id integer NOT NULL REFERENCES hive_accounts (id),
post_id integer NOT NULL REFERENCES hive_posts (id),
option smallint NOT NULL,
custom_input integer
);
I haven't started writing code for polls or "discussion rooms" yet. I'm still doing feasibility studies. In addition to being modular upgrades that don't depend on each other, I also intend to make them compatible with Native Ads so that a community can accept sponsored polls and sponsored discussions.
I am working on a number of new features to extend Hivemind, as a way to experiment and help develop a testbed that Steem front-ends can use. To see the code, check out the branches on my fork of Hivemind on GitHub.