-
Notifications
You must be signed in to change notification settings - Fork 150
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[FEATURE] Zapless Polls #935
Comments
I have a zapless polls spec here: nostr-protocol/nips#1190 Would love to help out anyone trying to implement this either here or on hzrd149/nostrudel#186. |
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. |
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. |
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. |
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. |
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. |
how? my argument is that they are the same thing. |
You say right on your NIP:
There is no need for any of that for social media polls. |
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. |
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. |
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. |
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. |
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. |
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. |
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. |
I'm not sure where to put this but has anyone played with the idea of posting poll results? 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. |
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. |
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. |
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. |
I would probably just mark any altered poll invalid, not show it or stop putting any effort in trying to make it look correct. |
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. |
If you don't add an eligibility event, all responses will be shown, not sure how that is a constraint on the responder? 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. |
Super early implementation https://nostr-polls.vercel.app/ |
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
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.
The text was updated successfully, but these errors were encountered: