Adds Reaction-based Polling

[vitorpamplona]

Adds a simple way to use reactions for polling.

This is not for serious pools but for fun/social media ones:

• It doesn't have a closing date because people can distort the tally by creating reaction events in the past anyway.
• It doesn't have a central tallying place that can control and distort the results. It's whatever authors want to believe.
• It doesn't pretend to address spam because there is no way to block spam on Nostr.

Example of use: https://njump.me/nevent1qqsdrt3lekgna5navscqd726pr7vnz8jhru6mwcmkeg7jpawafteyzczyr9utmmtq89arlazew26j48sfsu94ymvr2rwrwuuehev7r6wh6kvkqg894q

For reference:

• Zap Polls are implemented on Amethyst and Snort Polls RFC 69 #320
• Member-only Form Polls are implemented on FormStr Forms on nostr #1190
• Multi-choice Polls were proposed on: NIP-41: Poll & Vote Event #148
• Multi-choice Replaceable Polls were proposed on: feat: add surveys / polls #111

[jeremyd]

This is cool. What do you think about having an optional ["r", "wss:https://pollrelay"] as a tag? So that if you wanted the poll to happen on a specific relay that has an ACL (such as paid or community relay) then the poll would be harder to game with bot accounts.

[vitorpamplona]

The relay for polls should be the same relay you send reactions to. If this is a Kind 1 post, it should go to the NIP-65 READ relays of the author of that post (or reply). If this is a NIP-28 chat, the reactions should be sent to the relays tag on the kind 41 event. If this is a community post, the reaction SHOULD be sent to and from the community relay.

It should go to almost always 3 relays:

• The author of the poll's READ relays using NIP-65, so that the author is notified.
• The voter's own NIP-65 WRITE relays so that the voter can keep it's records.
• The host relay of the chat/community/stream/group chat this is coming from so that Clients can tally from it.

[CyberDexter]

I can see a ton of usage of this with nostr based streaming and podcasting. GG

[jeremyd]

The relay for polls should be the same relay you send reactions to. If this is a Kind 1 post, it should go to the NIP-65 READ relays of the author of that post (or reply). If this is a NIP-28 chat, the reactions should be sent to the relays tag on the kind 41 event. If this is a community post, the reaction SHOULD be sent to and from the community relay.

It should go to almost always 3 relays:

• The author of the poll's READ relays using NIP-65, so that the author is notified.
• The voter's own NIP-65 WRITE relays so that the voter can keep it's records.
• The host relay of the chat/community/stream/group chat this is coming from so that Clients can tally from it.

Right, for the host relay one, it would make it easier for clients if they wanted a 'true tally' to know which relay this was. There's no entry in NIP65 for this.

[vitorpamplona]

1. There is never going to be a "true tally".
2. Should clients also send replies, other reactions, and all the other stuff people can do to a note to that relay? If so, then the relay tag is more general than the polling change.

[jeremyd]

1. There is never going to be a "true tally".
2. Should clients also send replies, other reactions, and all the other stuff people can do to a note to that relay? If so, then the relay tag is more general than the polling change.

True. I wonder how this could be done then, it seems that nip65 is more for a users in a twitter like mode, vs. a streamer who is managing a chat of potentially thousands of people that are not part of this paradigm.. Streams have the same problem, they should be able to point at a relay instead of the general pool so that they can manage their community of users separately from their nip65+mute list. I thought just having ["r", "wss:https://streamrelay"] could solve this, but I guess it's too early to point at this pattern and say, this is a good idea to add to a new kind. It's the only pattern I've seen used for other things trying to be relay specific, such as NIP29 or NIP87 groups though. So I thought it would be cool to have it for polls.

Anyway, I know it makes it harder to implement, but if it was in the spec as optional, you don't have to implement it but it will be there for clients that do want to.

[vitorpamplona]

It might be better to have the relay tag each of the NIPs that control the "host" setting. They already have to specify which relay to use in each of their concerns, reactions should just nicely fit into their needs.

[abhay-raizada]

I believe #1190 is a more fleshed out standard that can achieve the same results, as well as have access control if you want it. I don't see the point of having two standards do the same thing, it will break interoperability of decent polling solutions.

What do you think NIP-101 can't do, that this change can?

[vitorpamplona]

#1190 requires clients to implement it as opposed to reactions that is virtually supported by all clients at this point. In this PR, any client would already be voting without changing anything.

[staab]

Yeah, I don't like this. Overloading is bad, this basically means that people might be voting without knowing it. A different, incompatible argument is that this only supports "reaction hints", which may or may not be followed or rendered. I'd rather see a real polls NIP rather than something that subtly degrades interoperability.

[alexgleason]

I agree with @staab

ActivityPub has Question and Answer types. We should do that.

[vitorpamplona]

ActivityPub has Question and Answer types.

Which event kinds do you use?

this basically means that people might be voting without knowing it.

Doubt it. The note usually asks people to use reactions to vote. This add-on just allows Clients to know when there is a poll and render it.

The reaction poll is already happening by people simply writing: "Do you folks like pizza? React with 👍 for yes and 👎 for no". We can just nicely render the results.

[vitorpamplona]

Example: https://nostr.band/note16xhrlnv38mf86epsqmu45z8uexy09w8e4ka3hdj3ayr6a6jhjg9s6cpwen

[alexgleason]

Which event kinds do you use?

I haven't implemented it on Nostr yet, but I have a whole UI ready to go for polls once we decide the data model. So I can be one of the adopters of this pretty easily.

[staab]

Doubt it. The note usually asks people to use reactions to vote. This add-on just allows Clients to know when there is a poll and render it.

Changing the interface will change how people frame it. If there's a "poll" button they won't explain that it's a poll.

[vitorpamplona]

Changing the interface will change how people frame it.

Sounds like poor UI design, not a problem of the spec.

[nanikamado]

How about specifying the syntax of this part:

🤙 option 1
👍 option 2
❤️ option 3

so that clients can parse it and change it into proper UI?

I prefer this:

over this:

[vitorpamplona]

We could change it to: ["poll", "<reaction>", "<description - optional>"]

Like:

{
  "kind": 1,
  "content": "Do you folks like pizza?",
  "tags": [
    ["poll", "👍"]
    ["poll", "👎"]
  ],
  ...other fields
}

and

{
  "kind": 1,
  "content": "Do you folks like pizza?",
  "tags": [
    ["poll", "1️⃣", "option 1"]
    ["poll", "2️⃣", "option 2"]
  ],
  ...other fields
}

[nanikamado]

I really like the idea of using reactions because it allows people to see and participate in polls even if their clients don't support it. So I prefer including the description texts in .content, not .tags.