From 255c4d98c56bafe06e47c36c393fba3d3cc6b188 Mon Sep 17 00:00:00 2001 From: landonMutch Date: Mon, 27 Feb 2023 15:04:03 +0900 Subject: [PATCH] add RFC -add poll format request for comment (RFC) pro/con lists -remove placeholding json structure --- 69.md | 56 ++++++++++++++++++++++++++++++++------------------------ 1 file changed, 32 insertions(+), 24 deletions(-) diff --git a/69.md b/69.md index dbc5339a..0dcc798a 100644 --- a/69.md +++ b/69.md @@ -1,33 +1,41 @@ # Poll event +A poll note is a nostr event type (kind 6969) for conducting polls, containing predefined voting options, which users may vote on via zaps. + ## Purpose -- define new standardized event kind for voting polls +* define new standardized event kind for voting polls -## Poll format +## Poll format (RFC) -```json -{ - "id": <32-bytes lowercase hex-encoded sha256 of the the serialized poll event data> - "pubkey": <32-bytes lowercase hex-encoded public key of the poll event creator>, - "created_at": , - "kind": 6969, - "tags": [ - ["e", <32-bytes hex of the id of another event>, ], - ["p", <32-bytes hex of the key>, ], - ], - "content": , - "sig": <64-bytes hex of the signature of the sha256 hash of the serialized event data, which is the same as the "id" field> -} -``` +Should a poll be self-contained in a single event (including its voting options) or be a parent event (#0) with separate (but linked) child voting option events (#1, #2, #3, #n), each referencing the parent poll event? + +#### Self-contained poll event + +* Pros: + * likely results in better UX by providing compact, widget-style notes immediately recognizable as unique poll type + * promotes more uniform implementation across clients +* Cons: + * increased poll event complexity, owing to internally nested voting options (each necessarily containing their own zap requirements) + * potentially increased difficulty of client implementation + +#### Single parent poll event with linked child voting option events + +* Pros: + * better alignment with existing event (specifically zap) structures + * potential for backward compatibility with clients uncompliant with polling events, i.e. non-compliant clients could handle poll event chains same as existing threads + * possibly simplifies implementation by clients? +* Cons: + * introduces possibility for fragmentation of polls, e.g. separation or loss of child voting options + * increased potential for non-uniform implementation of polling UI/UX across clients ## TODO -- define basic polling features -- define basic polling format -- outline polling NIP -- publish RFC to nostr dev community -- implement polls in 1 relay -- implement polls in 2 clients -- send pull request to nostr-protocol/NIPs -- merge with nostr-protocol/NIPs +* define basic polling features +* define basic polling format +* outline polling NIP +* publish RFC to nostr dev community +* implement polls in 1 relay +* implement polls in 2 clients +* send pull request to nostr-protocol/NIPs +* merge with nostr-protocol/NIPs