2.9 KiB
Poll event
A poll note is a nostr event type (kind 6969) for conducting valuation polls. A poll presents two or more voting options, each represented by a unique zappable bolt11 address. Voters may participate in polls by zapping one or more chosen option(s). Poll results may be blinded, until after users have voted. Polls may specify a closing time, after which results should be unblinded, closed to new votes, and considered final.
Votes may be tallied either by total valuation or by count. To avoid ambiguity of outcome, the tally method MUST be specified by the poller upon creation of the poll. Once closed, the option with either the highest total associated value (sats) or the most votes (counts) should be treated as the winning option, and the distribution of votes considered respresentative of the combined opinion of its participants.
Purpose
The purpose of poll notes is to solicit qualitative public opinion polls by requiring voters pay to participate. By quantitatively tying vote counts and amounts to real satoshi valuations, nostr polls should provide superior signal compared with other free polling models. Imposing real monetary costs on participants should also discourage attempts at fraudulent result manipulation, by automated or other means.
Strict adherence to the requirements of this NIP should allow for more robust and formal means of assessing consensus of opinion on a poll's content. However, until this outline is further refined and proven robust, polls should not be considered authoritative nor binding.
Poll format (RFC)
A poll is a self-contained event, containing a predefined number of voting options.
Self-contained poll event
- Pros:
- likely results in better UX by providing compact, widget-style notes immediately recognizable as unique poll type
- promotes more uniform implementation across clients
- Cons:
- increased poll event complexity, owing to internally nested voting options (each necessarily containing their own zap requirements)
- potentially increased difficulty of client implementation
Single parent poll event with linked child voting option events
- Pros:
- better alignment with existing event (specifically zap) structures
- potential for backward compatibility with clients uncompliant with polling events, i.e. non-compliant clients could handle poll event chains same as existing threads
- possibly simplifies implementation by clients?
- Cons:
- introduces possibility for fragmentation of polls, e.g. separation or loss of child voting options
- increased potential for non-uniform implementation of polling UI/UX across clients
TODO
- define basic polling features
- define basic polling format
- outline polling NIP
- publish RFC to nostr dev community
- implement polls in 1 relay
- implement polls in 2 clients
- send pull request to nostr-protocol/NIPs
- merge with nostr-protocol/NIPs