Replies (70)

It's not an election, just a way to gauge people's opinions. the spec I'm using allows to specify authoritative relays which can filter spam, and doing client side filtering of results should help separate the signal from the noise.
Saw this, while working on pollerama, to make it easier to use. I think if these "popular clients" won't do it, we should just make our clients better and make these dinosaurs irrelevant.
I'm mostly on Jumble and our own stuff, now, with occasional side-offs on Nostrudel and Chachi. I also sometimes spy on Primal, to find out how the other half lives. Oh, and I use Pollerama. 😁
The most stupidest polls to exist, you can find the real ones on pollerama.fun or chachi.chat and now even on jumble.social
Tbh I would even argue that the spec is also election ready if implemented correctly πŸ€·β€β™‚οΈ
Yet there are npubs who would die on this hill, they would knowingly make nostr worse just so they can make a few sats on their polls.
I would filter it by my follows and maybe their follows and would want to know who voted what. No need for sats.
Relays or clients, user-set client filters or hard-coded client filters, it all leads to a quantum soup one way or the other. Nostr just doesn't do consistency. And the whole point of a poll is that everyone is 100% sure everyone else is seeing the exact same numbers. Otherwise it's not a poll, it's an interpretation generator. Could work for NIP-29 groups though.
Something cool that Pollerama could do, as a cross-relay service, is display the polls by demographic (relay community) and also in aggregrate (deduplicating the results by npub). Then you can have higher-signal results for the "full" data set, than if someone just looked at the results in relay.nostr.band, or something, while everyone could still drill down by demographic. You could also display the relay.nostr.band results, of course, since it's a sort of mega-community.
Overthinking for the win. So many Nostr issues stem from underthinking and just smashing something out. Case in point: NIP-04. Couple days of whoo-wee followed by couple years of pain.
It's already de-duped by npub, the poll creator is supposed to specify the relays though so there is consistency, but yeah relay filtering doesn't hurt, I'll look into it.
The result should depend on where the author is targeting the :poll: Poll. I.e. the author selects what Communities (with moderated relay + media server) he uses as the publication houses for his event. This gives you a Global state you can work with, without having the author hand over control to one server.
Targeting to multiple #commuikeys fixes the quantum soup, while not trying your publications to one community forever. I need people to poke holes on this approach. The lack of a global default state to work with is a real one and keeps coming up for nearly every content type.
I think it gets some hate because it upends the physics of Nostr. It's like Galileo coming in and going "No actually it's the other way around y'all.".
I also need a mobile app that fixes my typos before sending :joke:
For most content types, BOTH publishing in the unglobal feed or in 1 moderated community suck. There's a middle way tho.
water783's avatar
water783 7 months ago
With a high-performance server, I think it could support a group with up to ten thousand members.
If you're checking the source code, make sure to look at all branches. Master branch is"stale" minus translations, because they are hard at work on outbox support.
↑