-
Notifications
You must be signed in to change notification settings - Fork 569
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
Adds Reaction-based Polling #1324
base: master
Are you sure you want to change the base?
Conversation
This is cool. What do you think about having an optional ["r", "wss://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. |
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 It should go to almost always 3 relays:
|
I can see a ton of usage of this with nostr based streaming and podcasting. GG |
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. |
|
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://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. |
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. |
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? |
#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. |
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. |
I agree with @staab ActivityPub has Question and Answer types. We should do that. |
Which event kinds do you use?
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. |
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. |
Changing the interface will change how people frame it. If there's a "poll" button they won't explain that it's a poll. |
Sounds like poor UI design, not a problem of the spec. |
We could change it to: 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
} |
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 |
Adds a simple way to use reactions for polling.
This is not for serious pools but for fun/social media ones:
Example of use: https://njump.me/nevent1qqsdrt3lekgna5navscqd726pr7vnz8jhru6mwcmkeg7jpawafteyzczyr9utmmtq89arlazew26j48sfsu94ymvr2rwrwuuehev7r6wh6kvkqg894q
For reference: