[FEATURE] Zapless Polls

[vicariousdrama]

Polls are an underutilized capability of nostr. Currently, Amethyst is the only client that I am aware of that has implemented polls, but unfortunately they are in the zap-based format as outlined in nostr-protocol/nips#320. I guess one could consider Formstr as a method of polls? I myself used to run a poll bot in the first quarter of 2023 that tallied votes based on zap amount on the note by participants.

Many people want polls but do not want to spend sats to participate. The arguments for requiring zap payments tend to focus on prevention of spam, but there is no technical constraint that keeps a bad actor from spinning up multiple pubkeys to spam a poll with sats. If its the author of the poll, they can manipulate it in this fashion paying the invoices to themself. Alternatively, the author, and others can issue zap receipts claiming to have paid sats when none were actually paid.

I propose that zapless polls be added to amethyst and follow the same general model as the zap based polls.

HOW

1. Existing kind 6969 could be used with the value_maximum and value_minimum tags both be set to 0 to indicate the poll responses do not require zaps.
   2,. Under this model, voting may be tallied by reactions, which should match the poll_option value. For example, a poll_option "0" would increment if a reaction having content of "0" is sent by a voter, referencing the event of the poll.

Bounty (in Bitcoin sats) offered for the implementation

I (npub1yx6pjypd4r7qh2gysjhvjd9l2km6hnm4amdnjyjw3467fy05rf0qfp7kza) am offering 1_000_000 sats for this feature to be added for kind 6969

Please advise if this should be broken down into multiple issues and bounties.

[abhay-raizada]

I have a zapless polls spec here: nostr-protocol/nips#1190
also a very rudimentary implementation on formstr as well https://deploy-preview-151--hilarious-cupcake-5ce684.netlify.app/#/c . Problem with open access polling is spam, which is what zaps were trying to solve in the first place, I've tried to solve it with access control.

Would love to help out anyone trying to implement this either here or on hzrd149/nostrudel#186.

[vitorpamplona]

Here's what I am thinking... We might need to keep things very simple for the fun polls: nostr-protocol/nips#1324

Serious polls must have a central tallying place to verify if the sender has the right to vote at each new vote event.

[abhay-raizada]

I hear you about simplicity, i fear that such a feature renders the results meaningless, it kind of works for formstr because results arent public, but people are going to want to skew the results if they can see which way they are tilting.

Also access controls are not that hard, you can give access to an entire contact list, or other lists, or through an algorithmic eligibility criteria.

[vitorpamplona]

I think that one and the one for forms are two separate polling styles. If you want to hide votes until the end, it has to use yours. But that is just one type of poll.

[abhay-raizada]

Umm sorry for the confusion when i meant formstr i meant the current version live on production, the nip101 spec works in both open-access and access controlled environments.

I see no reason why there need to be two standards to do the same thing.

[vitorpamplona]

My point is that they are not the same thing. In the same way that reaction polls and zap polls are not the same thing or in the same way that posts and community posts are not the same thing.

[abhay-raizada]

how? my argument is that they are the same thing.

[vitorpamplona]

You say right on your NIP:

1. Only elligeble candidates must be allowed to vote.

2. Participants shouldn't be able to associate a response to another participant.

3. Participants should be able to verify that their response is counted.

All of these conditions can be met by establishing a "Voter Key". The Voter Key is a private key generated by someone with edit access to the form (Issuer).

There is no need for any of that for social media polls.

[vitorpamplona]

BTW, we will code the forms version as well, but making them behave the same is a disservice for both. One is a form with lots of possibilities, the other one is a reaction poll.

[abhay-raizada]

That is completely optional though, and maybe i should improve the wording.

You can not have a p-tag on your 30168 event, and just query all 1069 events for results, instead of filtering.
Then that works exactly the same way a reaction would work, and we wouldn't need to follow two seperate standards.
Infact this is also how formstrs default scenario works in this nips implementation as well.

[vitorpamplona]

The reaction polling can happen at any event. Otherwise you would have embed a 30168 inside a kind 1 just for the polling part. 30168 is replaceable: the author can change the order and options over time. Something that we don't want on kind 1 polls for instance.

[abhay-raizada]

I think the edibility concern is a legitimate concern even for access controlled polls. I will try to address it on the nip, thanks for pointing it out.

Still not sure if the right approach is to use "reaction" polling here, since this issue should be solved in the polls nip itself probably by managing the poll content and access on separate events.

[vitorpamplona]

I don't think you should address it. Forcing one thing to behave like a separate thing is terrible for both sides and just complicates things even further. Do one thing and one thing really well.

[abhay-raizada]

I don't think there are two sides here, there is only one, "being able to conduct polls on nostr", "Social Media polls" are just a subset of the bigger problem.

I do agree that maybe the forms PR is doing too many things and maybe I should seperate out the forms from the polls as @staab had pointed out.

[vitorpamplona]

Keep in mind that your path is EXACTLY how nostr-protocol/nips#320 was moved to the back of the class. It started super simple and then kept adding stuff to do other things.

The NIP was never merged even though 4 popular clients have implemented Zap Polls for over a year.

This has happened so many times in other NIPs that now I think it's not a good move. Just make it work for you. The others will follow if it also works for them.

Arthur just gave up nostr-protocol/nips#784 exactly for the same reason. Tried to abstract a thing into a larger thing just to see it being replaced by simpler NIPs later.

[fabianfabian]

I'm not sure where to put this but has anyone played with the idea of posting poll results?
Imagine in this region people voted like this and in the other region they voted like that. In nostr it would be in the author's WoT people posted like this, but in my WoT like that etc.

So creating a poll and voting would be very simple, and on the more difficult part (the result) clients can compete on figuring out a way to best show it in whatever way they think calculates it best.

[vitorpamplona]

I'm not sure where to put this but has anyone played with the idea of posting poll results?

That was talked during nostr-protocol/nips#320. The main problem was the lack of trust in the poll author. People wanted a solution where the author couldn't influence the results. Developing a trustless tally is really hard.

[abhay-raizada]

nostr-protocol/nips#1190 has post-able poll results (because of a lack of spam) but you have to "trust" the author. I have some new ideas about polls where trust isn't an issue. I'll draft them up in a new PR soon.

[fabianfabian]

you don't have to trust the author when anyone can post poll results, you could leave that open and let the best algo win. For example show like this (but of course up to each client to decide what to show):

but instead of Model A/B it could be author/you/relay/service/dvm/whatever

[vitorpamplona]

If the author can change the poll, by publishing a new replaceable with inverted options, then there is either some trust involved or tallying becomes extremely complicated. Different people can view different options just because they use different relays that just so happen to have diverging versions of the same replaceable.

[fabianfabian]

I would probably just mark any altered poll invalid, not show it or stop putting any effort in trying to make it look correct.

[abhay-raizada]

Or we can just have the poll content be in a non editable event and eligibility be a spereate event, as I try to do in this very early draft. https://github.com/abhay-raizada/nips/blob/70f1be5866a69768e4cc63447e2268a15e70ad3f/118.md

[vicariousdrama]

Or we can just have the poll content be in a non editable event and eligibility be a spereate event, as I try to do in this very early draft. https://github.com/abhay-raizada/nips/blob/70f1be5866a69768e4cc63447e2268a15e70ad3f/118.md

That NIP puts excessive constraints on respondents to a poll. As a poll publisher, most of my polls are whimsical, and I want the option to allow anyone (global) to give a response, vs having to define a list of who is allowed to respond. For instances where I want more serious polling and constraints on who can respond, my personal approach to this would be publishing to a restricted relay used by a group of pubkeys. This is still a kind of list, but implicitly defined vs explicit as in your NIP.

[abhay-raizada]

That NIP puts excessive constraints on respondents to a poll. As a poll publisher, most of my polls are whimsical, and I want the option to allow anyone (global) to give a response, vs having to define a list of who is allowed to respond. For instances where I want more serious polling and constraints on who can respond, my personal approach to this would be publishing to a restricted relay used by a group of pubkeys. This is still a kind of list, but implicitly defined vs explicit as in your NIP.

If you don't add an eligibility event, all responses will be shown, not sure how that is a constraint on the responder?
Infact even if you do add an eligibility event, an option for all responders should still be given to the person viewing the results.

It's exactly how @fabianfabian envisions it. The eligibility lists are a curation list, not a restriction.

As in for a poll like, "Is the new bitcoin-core version good?", see how the eligibility list referencing "bitcoin devs" voted, or see all. Lists could also be ordered by WoT. It's kind of inspired by the wiki nip.

Should have an implementation out soon.

[abhay-raizada]

Super early implementation https://nostr-polls.vercel.app/