Skip to content
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.

Sign up for GitHub

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

NIP-41: Poll & Vote Event #148

Open
wants to merge 5 commits into
base: master
Choose a base branch
from
Open

NIP-41: Poll & Vote Event #148

Changes from 1 commit
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
afe487d
Create 41.md
0xtlt Jan 5, 2023
01cdd98
Merge branch 'nostr-protocol:master' into master
0xtlt Feb 28, 2023
4b47572
:up: Poll update
0xtlt Feb 28, 2023
00dc874
:up: Poll Update
0xtlt Feb 28, 2023
0b4fe77
Highlights
0xtlt Feb 28, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
46 changes: 46 additions & 0 deletions 41.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,46 @@
NIP-41
======

### Poll & Vote Event
-----------------------------------

`draft` `optional` `author:0xtlt`

An event with kind `1` that wants to contain a poll can do so by adding poll tags and its content as follows:

```json
{
...
"kind": 1,
"tags": [
...
["poll", "Choice 1"],
["poll", "Choice 2"],
["poll", "Choice 3"]
...
],
}
```

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

@AngusP AngusP Jan 17, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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"


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.
Copy link

@AngusP AngusP Jan 17, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 :)

Copy link

@jrc-dev jrc-dev May 26, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


It should also contain an `e` tag with the id of the poll event only.

```json
{
...
"kind": 8,
"tags": [
...
["e", "<event-id>"]
...
],
"content": "1"
}
```

#### Warning

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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