NIP-88: Polls
Polls are social objects with counting rules
A poll looks simple until clients try to interoperate. One app uses labels, another uses IDs, a third counts the latest vote, and a fourth cannot find responses because they landed on different relays. NIP-88 gives polls a shared event shape.
The poll event is kind 1068. Its content is the question. option tags carry stable option IDs and labels. relay tags tell respondents where answers are expected. polltype distinguishes single choice from multiple choice.
Responses use kind 1018. They point back to the poll with an e tag and include one or more response tags that reference option IDs.
A poll is one event; a vote is another
The separation matters. A poll creator signs the options and end time. A respondent signs their response. Counting rules then decide how to interpret multiple responses from the same pubkey or multiple response tags in one event.
For single-choice polls, the first response tag is the actual answer. For multiple-choice polls, the first response tag pointing to each ID is counted without relying on tag order. The spec also describes relay behavior and curation expectations.
The end-time tag gives clients a way to close the UI, but it does not force every relay or indexer to agree on a final result.
Polls had a messy path into the current NIP set
Abhay Raizada started the visible Polls on Nostr work in June 2024 and refined it through July. In September 2024, Alex Gleason changed the poll response shape, fiatjaf renumbered it to NIP-88, then removed the polls NIP temporarily the same day. In January 2025, abhay-raizada reinstated it through PR #1507.
That churn is worth preserving in the article because polls sit at the edge of product convenience and protocol difficulty. Everyone understands the feature; fewer people agree on what reliable, abuse-resistant counting needs to mean.
The current NIP is usable, but a serious poll client still has to explain its counting and trust assumptions.
The count is a view, not a law of nature
A good poll UI needs to show whether the poll is single-choice or multiple-choice, when it ends, where responses are expected, and how many relays were queried. If the count is partial, it needs to look partial.
Clients also need a policy for duplicate votes, edited votes, blocked users and spam. NIP-88 gives the event shape, not a universal identity system or sybil-resistance model.
That honesty can make polls useful without overselling them. A poll on Nostr is best treated as a signed social signal, not a formal election.
Open polls are easy to game
NIP-88 does not solve one-person-one-vote. A determined actor can create many keys. For casual community questions that may be acceptable; for governance it is not enough on its own.
Poll creators can also write misleading options. The protocol cannot rescue a bad question.
Read NIP-88 in the wild
NIP-88 models polls. A poll can be fun, exploratory or governance-adjacent, but the social meaning changes depending on who created it and how votes are collected.
Do not let a poll pretend to be an election. Display eligibility, visibility, counting method, closing time and whether votes are public or private enough for the context.
What changes when you actually use it
For you, NIP-88: Polls is felt when someone makes a claim about content, people, trust, status or community behavior. Reports, labels, badges, assertions and polls can help you navigate an open network, but they can also become quiet authority. Read NIP-01 and the adjacent source links so you see who speaks, what is targeted and how much weight the claim deserves.
What changes for builders and operators
For builders and moderators, NIP-88: Polls means preventing claims from becoming invisible law. Show issuer, target, reason, timestamp, evidence and conflict. Let people understand why a label, report, badge or assertion appears before it changes what they can see.
What the official file makes concrete
The official file is organized around Events, Poll Event, Responses, Poll Types, Counting Results, Relays, Curation. Inspect kind 1068, kind 1018, kind 5, kind 30000, draft, kind:1068, kind:1018, kind:30000 because these are the pieces most likely to surface as product behavior.
NIP-88: Polls is a claim layer. Reports, labels, badges, assertions and polls only help when issuer, target and scope stay visible.
Where it breaks
The failure mode in NIP-88: Polls is authority theater. A report, label, badge, assertion or poll can look official because it is signed and rendered cleanly. The signature proves the issuer, not the fairness or accuracy of the claim.
Where this appears outside the markdown
In the ecosystem, NIP-88: Polls belongs to the social safety and coordination layer. It can help people filter noise, recognize contribution, report abuse, run polls or make assertions. It can also concentrate influence quietly if the issuer disappears behind the label. The hub has to preserve that tension instead of selling governance as solved.
The nearby-standard trap
The nearby-standard trap in NIP-88: Polls is treating every signed claim as a moderation decision. A label, report, badge, assertion or poll can inform judgment without becoming policy. Read NIP-01 and the adjacent source links and keep issuer, target and consequence separate.
Language that keeps the feature honest
Good product copy for NIP-88: Polls names the claimant. It says who reported, labeled, awarded, asserted, voted or counted, and it leaves room for conflict. That is how a safety feature avoids becoming invisible authority.
What this page does not promise
NIP-88: Polls does not make a community decision neutral. Signed reports, labels, badges, assertions and polls can improve safety or discovery, but they still come from people, services or institutions with incentives. The standard helps expose the claim. It does not make the claim fair, complete or universally binding.
Read it as a field test
Start NIP-88: Polls with the claimant. A label, report, badge, assertion or poll has meaning only when issuer, target, reason and consequence remain visible. The article needs to preserve that social context because signed data can still be biased, stale or disputed.
Where the standard earns trust
The source links give you places to test the interpretation in public: nips.nostr.com NIP-88, PR #1507, Stacker News discussion. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-88 source is the anchor for exact wording, and NIP-88 commit history shows how that wording moved over time. The strongest secondary clues here are nips.nostr.com NIP-88, PR #1507, Stacker News discussion. Treat this evidence chain as part of the article, not as footnotes. A NIP page becomes useful when you can move from claim to source to working behavior without guessing.
Keep the chain visible for NIP-88: Polls: first the human promise, then kind 1068, kind 1018, kind 5, kind 30000, draft, kind:1068, then the implementation record, then the real-world failure case. That order keeps NIP-88 useful without turning it into marketing copy or protocol trivia.
Three questions to carry forward
- Who issued the claim, label, badge, report, assertion or poll, and what exactly is the target?
- Can you see evidence, conflicts, expiry and scope before the claim changes what you see?
- Does the design leave room for disagreement instead of hiding authority behind a clean badge?
What to verify before you rely on it
- Find
kind 1068,kind 1018,kind 5,kind 30000,draftin the official file and check where the UI exposes the same concept. - Read NIP-01 and the adjacent source links as context before treating NIP-88 as a complete product story.
- Open at least one implementation, mirror, pull request or library source from the source links before trusting that the idea is mature.
- Test the unhappy path: missing relays, stale metadata, invalid signatures, blocked events, expired state, revoked permissions or unavailable media.
- Write the user-facing copy in plain language. If a standard changes authority, privacy, money, moderation or recovery, say that before the click.
Direct sources
Use these sources for NIP-88: Polls in that order: Official NIP-88 source for the current wording; NIP-88 commit history for the change record; nips.nostr.com NIP-88, PR #1507, Stacker News discussion for public context. The article gives you the consequence in plain language, but the source trail is where exact fields, status notes, unresolved debates and implementation proof stay checkable.
