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

section clarifications

Browse Source 
-clarify, organize outcome and other sections
-minor edits
This commit is contained in:
landonMutch 2023-03-02 21:21:18 +09:00 committed by GitHub
parent ae55cbffa6
commit edd13533d5
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 28 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

37
69.md
View File

@ -1,6 +1,6 @@
# Poll event
A poll note is a nostr event (kind `6969`) for conducting paid polls. A poll presents two or more voting options, which participants my vote on by sending regular zap events which include an additional `poll_option` vote tag. Poll results may be blinded, until after users have voted. Polls may specify a `closed_at` time, after which results should be unblinded, closed to new votes, and considered final. Polls may also specify a `consensus_threshold`.
A poll note is a nostr event (kind `6969`) for conducting paid polls. A poll presents two or more voting options, which participants my vote on by sending regular zap events which include an additional `poll_option` vote tag. Poll results may be blinded, until after users have voted. Polls may specify a `closed_at` time, after which results should be unblinded, closed to new votes, and the tally considered final. Poll options may be tallied by either satoshi `value` or vote `count`. Polls may additionally specify a `consensus_threshold`.
## Purpose
@ -47,8 +47,8 @@ Poll options are voted on by sending zap events (to the original poll event) whi
Zap vote events (kind `9734` and `9735`):
* MUST include exactly 1 `poll_option` tag
* MUST reference the chosen vote option by its corresponding integar `n`, from the original poll event's list of predefined `polling_options`
* MUST transmit the exact `poll_option` between between kind `9734` and `9735`
* MUST reference the vote option by its corresponding integar `n`, chosen from the original poll event's list of predefined `polling_options`
* MUST transmit the exact `poll_option` between kind `9734` and `9735`
```json
"tags": [
@ -58,15 +58,34 @@ Zap vote events (kind `9734` and `9735`):
]
```
## Poll outcomes
## Poll outcome
Votes may be tallied either by value or by count. To avoid ambiguity of a winning outcome, a primary `tally_method` MUST be specified as either `value` or `count`. When a `count` `tally_method` is specified, only a single vote (the most recent) per unique voter MUST be included in the tally, zap amounts MUST be ignored, and anonymous zaps MUST NOT be counted.
To avoid ambiguity of results, strict adherence to the following rules is vital when tallying and rendering poll outcomes.
If a `closed_at` time is specified, after it is passed, a poll should be unblinded publicly and MUST be treated as closed (late votes must not be tallied). Once closed, the option associated with either the most satoshis (value) or the most votes (counts), depending on `tally_method`, MUST be treated as the winning option; while the distribution percentages across all vote options MUST be considered respresentative of the distribution of opinion amongst participants.
A tallying client:
* MUST tally poll results according to the primary `tally_method` specified:
* when tallying by `value`, clients:
* MUST include full satoshi values from all relevant zap events
* MUST include multiple zap events from single users
* MUST treat the vote option with the highest satoshi value as the winning option
* when tallying by `count`, clients:
* MUST ONLY count the most recent zap from a unique user as 1 vote
* MUST NOT include zapped satoshi values in the tally
* MUST NOT count votes from anonymous users
* MUST treat the vote option with the most unique votes as the winning option
* when a `closed_at` time is specified, clients:
* MUST NOT include late votes recieved after `closed_at` time
* SHOULD publicly blind results until after a user's vote has been recieved
* 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
If a `closed_at` time is not specified (or is less than or equal to `created_at`), all votes SHOULD be tallied into perpetuity, and the most recent tally SHOULD be treated as the definitive outcome.
Additionally, if a consensus threshold percentage is specified, and any single option's associated value (or vote count) percentage of the poll's total value (or vote count, respectively) exceeds the consensus threshold, then consensus MUST be considered attained.
After the above rules are applied and clearly rendered, a tallying client:
* MUST display the distribution percentages, from the total, for each vote option
* if a non-zero `consensus_threshold` is specified, clients:
* MUST indicate the state of consensus by displaying its value relative to the final percentage of the winning vote
* MAY display the secondary tally method result, for statistical purposes, along with other associated poll metrics and comments
Strict adherence to these requirements should enable a standardized means of quantitatively assessing the distribution of opinion regarding a poll's content amongst poll participants, determining a winning outcome, and possibly acheiving consensus. However, until this protocol is further tested, refined, and proven robust, polls should probably not be considered authoritative nor binding.