nostr/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2024-11-12 23:19:08 -05:00
Code Issues Actions Packages Projects Releases Wiki Activity

elaborate on purpose of value/count tally_methods based on feedback

Browse Source
This commit is contained in:
toadlyBroodle 2023-03-05 13:47:04 +09:00
parent a2f6b39b90
commit 9ce8a868a3
1 changed files with 9 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
69.md
View File

@ -8,6 +8,12 @@ A poll note is a [nostr event](01.md) (kind `6969`) for conducting paid polls. A
The purpose of poll notes is to conduct quantitative public opinion polls over nostr by requiring voters pay to participate. By tying vote amounts and counts to real satoshi valuations, nostr polls intend to provide superior signal compared to other free polling models. Imposing real monetary costs on participants should also discourage attempts at fraudulent result manipulation, by automated or other means.
Distinct `value` and `count` `tally_method`s are defined to enable two different polling types. Polls tallied by total zapped `value` allow for weighting of votes by their associated satoshi valuations, while polls tallyied by `count` force an equal weighting of all votes, regardless of their satoshi amounts (provided they meet the `value_minimum`, when specified).
Both `tally_method` types have their own strengths and weaknesses: `value` polls may encourage larger bidding-style submissions and are resilient against a single entity submitting repeated low-value votes, however, they also allow for a single 'whale' voter to discount many smaller 'shrimp' voters; while `count` polls may encourage increased voter participation, by enforcing an equal weighting of all votes, but are more susceptible to repeated voter count manipulations.
A careful balancing of all poll attributes should enable pollers to design and conduct polls with meaningful and valuable outcomes.
## Poll format
A poll event:
@ -32,7 +38,7 @@ A poll event:
["p", <32-bytes hex of the key>, <recommended relay URL>],
["poll_options", "[[0, 'poll option 0 description string'], [1, 'poll option 1 description string'], [<n>, 'poll option <n> description string']]"],
["tally_method", "value"||"count"],
["value_minimum", "minimum zap value to vote"],
["value_minimum", "minimum satoshi value to vote"],
["consensus_threshold", "required percentage to attain consensus <0..100>"],
["closed_at", "unix timestamp in seconds"],
],
@ -80,8 +86,8 @@ A tallying client:
* SHOULD publicly blind results until after a user's vote has been received
* SHOULD publicly display results after the `closed_at` time has passed
* when a `closed_at` time is NOT specified (is less than or equal to `created_at`), clients:
* SHOULD include all votes in tallies
* SHOULD treat the most recent tally as the definitive outcome
* MUST include all votes in tallies
* MUST treat the most recent tally as the definitive outcome
After the above rules are applied and clearly rendered, a tallying client:
* MUST display the distribution percentages, from the total, for each vote option