Polls RFC 69 #320
Polls RFC 69 #320
Conversation
-further define poll event -further define purpose
-define outcomes section -outline format
-add detailed 'count' tally method requirements -add option tag reference -remove bolt11 references
-add standardized poll event json format
-reorder, refine poll format -modify TODOs
-add zap vote format section -edit, elaborate other sections
-organize and clarify format sections -other minor edits
-clarify, organize outcome and other sections -minor edits
-add poll tags to standardized tags index
Co-authored-by: Semisol <[email protected]>
… consensus_threshold and closed_at tags to type string, remove poll tags from README tags index
|
Can we merge this? Amethyst and Snort implement this NIP and has been working well. |
|
I haven't merged it yet because it is breaking the README and I haven't had time for or remembered fixing it myself. |
|
I realize this ship has already sailed, but NACK on making zaps a hard dependency of other nostr features. Payment proof should be open ended and optional. |
|
Agreed @staab. We will need a different type of poll to bridge polls from ActivityPub. |
|
@staab @alexgleason I don't see this as the only poll implementation in Nostr and I generally agree that the dependency on zaps is not good. However, I do think for those using zaps, this is already good enough. |
I think we can make this better, Dependency on zaps sucks... |
Fixed |
|
I am coming here again asking to merge this. Let's move on. |
|
Consensus seems to be that dependency on zaps is bad. I vote against this PR. |
Can't we merge and if somebody has a good non-zap implementation they can just update this NIP? By not merging, we are essentially blocking all potential changes from the community. |
|
There have been 3-4 other poll implementations. We could vote on those or someone could make a new NIP. I'd rather not merge for no reason and make a bad idea a standard. Do we have a tally of how many implementations each one has? We've had polls in various places for over a year, I remember some in branle. |
That's a bit too much. Not having a non-zap version doesn't make this a bad idea. The procedure is sound as a polling option. If people want to offer polls with zaps, this is it. We can tweak things around to make it better, but it works well. Then somebody else will need to create a different procedure for polling without zaps that hopefully have similar protections against spam. |
I've yet to see a single other NIP that comes anywhere close to as comprehensive as this one. Afterall, NIP69 was paid out @NVK and @StackSatsIO bounty. |
| @@ -37,6 +37,7 @@ In addition, the event MAY include the following tags: | |||
|
|
|||
| - `e` is an optional hex-encoded event id. Clients MUST include this if zapping an event rather than a person. | |||
| - `a` is an optional NIP-33 event coordinate that allows tipping parameterized replaceable events such as NIP-23 long-form notes. | |||
| - `poll_option` is a tag used for voting by [zap poll events](69.md). | |||
There was a problem hiding this comment.
No reason to modify NIP-57 for this.
There was a problem hiding this comment.
This is under optional MAY conditional list, for documentation purposes. It is a required field for zap-poll event zap requests: which is why it's included here. Still want it removed?
Request for Comment on new Poll event (kind #6969)
-Poll notes are paid poll events on nostr used to conduct quantitative opinion polls that users can vote on with zaps