NIP-41: Poll & Vote Event by 0xtlt · Pull Request #148 · nostr-protocol/nips

0xtlt · 2023-01-05T19:17:39Z

AngusP · 2023-01-17T11:28:50Z

41.md

+}
+```
+
+Then the client should display voting options if more than **1 choice** is present in the poll.


Only one "poll" may seem pointless, but perhaps it'd be useful for an "Agree", "No", "Sign Up", "ACK" or whatever where ignoring it is an implicit no? Given that the responses are all going to be public events, so you could DM everyone if it was for a 'signup' mechanism or whatever.

So, I think it'd make sense to still show it if only one choice is present, even if that seems odd/niche

Poll and sign up for something are two differents things, And we need an explicite usage of the poll, then if only one poll is defined, we can't decide for the user if he wanted to have "agree", "no" or sign up"

AngusP · 2023-01-17T11:36:39Z

41.md

+
+Then the client should display voting options if more than **1 choice** is present in the poll.
+
+The client can then submit the vote by sending an event with kind `8` and its content which will be the index (start at `0`) of the chosen choice.


Why not re-use/extend/abuse the NIP-25 reactions (type 7).

Then the poll options instead would be:

{ "tags": [ ["poll", "Choice 1"], ["poll", "Choice 2"], ["poll", "Choice 3"], ] }

and reaction/response event type 7 would be like this:

{ "id": "<ID>", "sig": "<signature>", "kind": 7, "tags": [ ["e", "<event ID of the note with the poll>"], ["p", "<pubkey of the note with the poll>"] ], "pubkey": "<pubkey of the responder>", "content": "Choice 1", "created_at": 1234567891 }

Where the "content" has to exactly match the choices given to count, otherwise it's treated like a normal reaction.

For better interoperability( /not breaking the current type 7 use), using 1️⃣, 2️⃣, 3️⃣, 4️⃣ etc. as first char of the "poll"tag and then allowing the reaction to only need to include the minimum unique prefix to 'count' so a simple 1️⃣ emoji reaction would work as a vote:

poll

{ "tags": [ ["poll", "1️⃣ Choice 1 text"], ["poll", "2️⃣ Choice 2 text"], ["poll", "3️⃣ Choice 3 text"], ] }

reaction

{ ..., "content": "1️⃣", }

Any reaction that doesn't match any of the "poll" options would be treated as just a normal reaction

I did see on your Damus PR though that @jb55 wasn't sure about re-using/overloading the reaction type

The problem with using reactions is that the reaction is not necessarily used to respond to a poll but is intended for "reaction" use only.
So with @jb55, we thought it would be better to explain this "feature" via a dedicated NIP :)

Polls are an event, reactions to an event that is a poll is indeed an answer, seems perfect simple to me. YAGNI! Also I disagree with reactions is not to respond a poll because reactions is also a flexible answer(upvote, donwvote, emoji), why not the answer of a poll, it is perfect.
The only thing that we are doing is leaving the count of answer to the client implementation, a thing that they are already doing with upvote and downvote.

Giszmo · 2023-01-17T15:59:49Z

The nip should be more explicit at least with an example how poll should work.

I suggest this should be valid:

poll:

{
    "tags": [
        ["p", <someKey>],
        ["poll", "Choice 1 text"],
        ["e", <someEvent>],
        ["poll", "Choice 2 text"],
        ["poll", "Choice 3 text"],
    ]
}

with votes being 0-based in the full tags array:

{
    ...,
    "content": "4", # this is "Choice 3 text". Content 0, 2 or 5 would be invalid votes.
}

Giszmo · 2023-01-17T16:06:45Z

41.md

+#### Warning
+
+Keep in mind that all votes are public and accessible to everyone.


Clients should make explicit that votes are public. Warning the implementer is not necessarily reaching the user.

0xtlt · 2023-01-17T16:36:13Z

Mmmh, I prefer to stay on the index of the tags filtered for poll values
If a day, a NIP makes tags array "dynamic" or another thing, I don't want to make this NIP blocking another possible future evolution m

But I will add examples to this NIP 👍

The nip should be more explicit at least with an example how poll should work.

I suggest this should be valid:

poll:
{

    "tags": [

        ["p", <someKey>],

        ["poll", "Choice 1 text"],

        ["e", <someEvent>],

        ["poll", "Choice 2 text"],

        ["poll", "Choice 3 text"],

    ]

}
with votes being 0-based in the full tags array:
{

    ...,

    "content": "4", # this is "Choice 3 text". Content 0, 2 or 5 would be invalid votes.

}

Giszmo · 2023-01-17T17:04:35Z

Please also explain the upside/downside compared with the prior PR #111

Giszmo · 2023-01-17T17:06:09Z

Mmmh, I prefer to stay on the index of the tags filtered for poll values If a day, a NIP makes tags array "dynamic" or another thing, I don't want to make this NIP blocking another possible future evolution m

The sorting of poll tags depends on the sorting of all tags. I don't get your argument here.

Why not slap all options into one poll tag like #111 ?

0xtlt · 2023-01-17T21:09:25Z

You're right @Giszmo, I made suggestions to the #111 PR, hope it will be helpful 👍

improvethings · 2023-02-20T20:52:03Z

I propose allowing for dynamic ranges for polling (for example, out of 1 to 100):

{
...
"kind": 1,
"tags": [
...
["response", "boolean|int"]
["poll", "Choice 1"],
["poll", "Choice 2"],
["poll", "Choice 3"]
...
],
}

and response:

{
...
"kind": 8,
"tags": [
...
["e", "", ""]
...
],
"content": "1"
}

0xtlt · 2023-02-28T08:43:33Z

Okay guys, I updated this NIP because there isn't much news on the other one, and there are some updates here.

fernandolguevara · 2023-03-03T23:09:50Z

#111 updated!

jrc-dev · 2023-05-26T06:33:52Z

Sorry, I'm just starting to understand the protocol, I'll leave my simple idea here and of course I must makinh a lot of mistakes.

A poll is an event with a type: 0,set_metadata(poll metadata), the details of a poll are described in our nip-41, now about the voting poll.

Votes are reactions (NIP-25) to the event(poll): upvote! But then we asked how can I vote the poll option since the upvote is just "+" content, well nip-25 is flexible on that and we can pass the choosed pool option as answer in that place, so not much change in anything...

What can go wrong with this approuch ?

jrc-dev · 2023-05-26T06:47:17Z

Also, let's change the limit of 4 options to 10, 10 will be ugly in the frontend, but is not our problem, it is a frontend problem. why do that? we can use this to other things, like review(0-10) and use a star component... just 4 will limited the use case.

AustinKelsay · 2024-01-05T19:10:15Z

Is this implemented on any clients?

gocedoko · 2024-06-24T08:13:04Z

Hi everyone, can we maybe wake up this NIP ?
I will have some time next month to do some work and maybe implement this in 1-2 clients.

But I have some further suggestions/needs:

I wanted to have polls into direct messages, (something like in Whatsapp or Facebook)
and for this they need to be private, so we should be able to keep the answer in the tag encrypted (same as the direct messages)
As discussed before, we need more options to choose from, Whatsapp allows up to 12 and facebook even more, so I'd say to allow around 15.
In a few friends groups that I have in whatsapp, we often do polls (as to decide what are we gonna do next weekend), and we end up sometimes close to 10 possible options.

@0xtlt please let me know if we should continue working with this PR or should I just fork another one :)

gocedoko · 2024-06-24T08:26:56Z

Now I also see this request for zapless polls in amethyst
vitorpamplona/amethyst#935

fiatjaf · 2024-06-24T12:15:55Z

We should probably do something like #148 (comment) with limitless options.

This would also work in NIP-29 groups.

We can define an entirely new scheme for DMs, but I don't get when you would use polls in DMs, since it's just two people.

gocedoko · 2024-06-24T13:04:36Z

There are private group chats in 0xChat, that was what I was talking about.

It looks like Nip101 would actually satisfy and even extend what I intended #1190

bquast · 2025-01-31T15:42:42Z

Pallier voting would be a zero-trust way of doing this. Would be more in the spirit IMO.

staab · 2025-01-31T16:31:33Z

Pallier voting would be a zero-trust way of doing this. Would be more in the spirit IMO.

This looks cool, I think you're the first to propose it. I'd love to see a NIP for how it would work if you're up for writing one. Main reservation is that it could introduce a lot of complexity to clients that want to implement polls, but if pallier libraries are commonplace that shouldn't be too much of a problem.

bquast · 2025-01-31T20:44:02Z

Thanks for getting back so quick. I am involved in some cryptography activities, I could probably do that.

I think it would be managable to write an implementation from scratch to make things a bit cleaner.

I was trying to write a client for ios to render a markdown version of AMP stories over nostr, and a from scratch way to get events was way easier than a libraries stack.

mikedilger · 2025-02-04T01:02:15Z

TL;DR but polls should be their own event kind. Kind-1 can quote them to share them. I don't like the limits.

vitorpamplona · 2025-08-01T21:38:16Z

Replaced by NIP-88

Create 41.md

afe487d

0xtlt mentioned this pull request Jan 6, 2023

New feature: Polls damus-io/damus#243

Closed

AngusP reviewed Jan 17, 2023

View reviewed changes

Giszmo reviewed Jan 17, 2023

View reviewed changes

0xtlt mentioned this pull request Jan 17, 2023

feat: add surveys / polls #111

Closed

0xtlt added 3 commits February 28, 2023 08:15

Merge branch 'nostr-protocol:master' into master

01cdd98

🆙 Poll update

4b47572

🆙 Poll Update

00dc874

Highlights

0b4fe77

ekzyis mentioned this pull request Feb 7, 2024

Nostr crossposting all item types stackernews/stacker.news#779

Merged

vitorpamplona mentioned this pull request Jun 24, 2024

Adds Reaction-based Polling #1324

Closed

abh3po mentioned this pull request Jul 5, 2024

NIP-88, Polls on Nostr #1346

Merged

ekzyis mentioned this pull request Dec 18, 2024

Migrating your app to nostr: Best practices & lessons learned nostrability/nostrability#78

Open

vitorpamplona closed this Aug 1, 2025


		Then the client should display voting options if more than 1 choice is present in the poll.

		The client can then submit the vote by sending an event with kind `8` and its content which will be the index (start at `0`) of the chosen choice.

		#### Warning

		Keep in mind that all votes are public and accessible to everyone.

Conversation

0xtlt commented Jan 5, 2023 • edited by Giszmo Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

AngusP Jan 17, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

0xtlt Jan 17, 2023

Choose a reason for hiding this comment

Uh oh!

AngusP Jan 17, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

AngusP Jan 17, 2023

Choose a reason for hiding this comment

Uh oh!

0xtlt Jan 17, 2023

Choose a reason for hiding this comment

Uh oh!

jrc-dev May 26, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Giszmo commented Jan 17, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Giszmo Jan 17, 2023

Choose a reason for hiding this comment

Uh oh!

0xtlt commented Jan 17, 2023

Uh oh!

Giszmo commented Jan 17, 2023

Uh oh!

Giszmo commented Jan 17, 2023

Uh oh!

0xtlt commented Jan 17, 2023

Uh oh!

improvethings commented Feb 20, 2023

Uh oh!

0xtlt commented Feb 28, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

fernandolguevara commented Mar 3, 2023

Uh oh!

jrc-dev commented May 26, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jrc-dev commented May 26, 2023

Uh oh!

AustinKelsay commented Jan 5, 2024

Uh oh!

gocedoko commented Jun 24, 2024

Uh oh!

gocedoko commented Jun 24, 2024

Uh oh!

fiatjaf commented Jun 24, 2024

Uh oh!

gocedoko commented Jun 24, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

bquast commented Jan 31, 2025

Uh oh!

staab commented Jan 31, 2025

Uh oh!

bquast commented Jan 31, 2025

Uh oh!

mikedilger commented Feb 4, 2025

Uh oh!

vitorpamplona commented Aug 1, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

13 participants

0xtlt commented Jan 5, 2023 •

edited by Giszmo

Loading

AngusP Jan 17, 2023 •

edited

Loading

AngusP Jan 17, 2023 •

edited

Loading

jrc-dev May 26, 2023 •

edited

Loading

Giszmo commented Jan 17, 2023 •

edited

Loading

0xtlt commented Feb 28, 2023 •

edited

Loading

jrc-dev commented May 26, 2023 •

edited

Loading

gocedoko commented Jun 24, 2024 •

edited

Loading