merge with remote master

This commit is contained in:
toadlyBroodle 2023-03-05 12:01:33 +09:00
commit 5d0ad89914
2 changed files with 12 additions and 12 deletions

2
01.md
View File

@ -16,7 +16,7 @@ The only object type that exists is the `event`, which has the following format
```json
{
"id": <32-bytes lowercase hex-encoded sha256 of the the serialized event data>
"id": <32-bytes lowercase hex-encoded sha256 of the serialized event data>
"pubkey": <32-bytes lowercase hex-encoded public key of the event creator>,
"created_at": <unix timestamp in seconds>,
"kind": <integer>,

22
69.md
View File

@ -1,5 +1,7 @@
# Poll event
`draft` `optional` `author:toadlyBroodle`
A poll note is a [nostr event](01.md) (kind `6969`) for conducting paid polls. A poll presents two or more voting options, which participants my vote on by sending regular [zap events](57.md) 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
@ -15,12 +17,12 @@ A poll event:
* MUST specify a primary `tally_method`: either `value` OR `count`
* SHOULD specify a `closed_at` time:
* a `closed_at` value of less than or equal to the `created_at` field indicates a poll SHOULD NOT be closed.
* MAY include a `consensus_threshold` integar (0-100), representing a percentage threshold for any single vote option to achieve poll consensus
* MAY include a `consensus_threshold` (0-100), representing a percentage threshold for any single vote option to achieve poll consensus
* a `consensus_threshold` of '0' indicates no threshold is specified.
```json
{
"id": <32-bytes lowercase hex-encoded sha256 of the the serialized event data>
"id": <32-bytes lowercase hex-encoded sha256 of the serialized event data>
"pubkey": <32-bytes lowercase hex-encoded public key of the event creator>,
"created_at": <unix timestamp in seconds>,
"kind": 6969,
@ -39,12 +41,11 @@ A poll event:
## Zap vote format
Poll options are voted on by sending [zap events](57.md) (to the original poll event) which include 1 additional `poll_option` tag within their otherwise standard [json structure](57.md#the-zap-note).
Poll options are voted on by sending [zap events](57.md) (to the original poll event) which include 1 additional `poll_option` tag in the zap request event.
Zap vote events (kind `9734` and `9735`):
The zap request event (kind `9734`):
* MUST include exactly 1 `poll_option` tag
* 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`
* MUST reference the vote option by its corresponding integer `n`, chosen from the original poll event's list of predefined `polling_options`
```json
"tags": [
@ -70,8 +71,8 @@ A tallying client:
* 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
* MUST NOT include late votes received after `closed_at` time
* 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
@ -83,12 +84,11 @@ After the above rules are applied and clearly rendered, a tallying client:
* 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.
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 achieving consensus. However, until this protocol is further tested, refined, and proven robust, polls should probably not be considered authoritative nor binding.
## TODO
* refine standardized polling formats based on dev feedback
* send pull request (RFC) to nostr-protocol/NIPs
* refine NIP#69 based RFC feedback
* implement polls in 1 relay
* implement polls in 2 clients
* merge with nostr-protocol/NIPs