@ABH3PO hey, i imagine you were seeing a bunch of garbage text as a poll event here and there, this was from an implementation into a new client, that's a encrypted group chat, so polls are published through it but encrypted. There was no mention of a private poll flow, so that's how it is implemented in that client right now. I can keep it as is, and we'll see a bunch of polls that are gibbers with clients not being able to render them properly without a sort of check if it can be rendered, or perhaps the nip would be updated to consider something like a 'visibility' tag of sorts so clients can what to render or what not to render (not to render ones where the value would be 'hidden' for example, under the assumption that poll would be encrypted), or perhaps a whole new kind specifically for private-encrypted polls. Thoughts?

Apparently this is a thing now xD (didn't try)

GitHub

GitHub - GitFrog1111/OpenWhip

Contribute to GitFrog1111/OpenWhip development by creating an account on GitHub.

Considering what I figured out with NSP (Nostr Silent Payments), I'm not worried about this (as in i'm not worried about an authority of some kind freezing an address, because there wouldn't be a static address through a normal payment flow through NSP).View quoted note →

DNN node code up:

GitHub

GitHub - Freakoverse/dnn-node

Contribute to Freakoverse/dnn-node development by creating an account on GitHub.

(check the DEPLOYMENT.md for installation on a linux server) Here's a quick video guide to installing one on a linux server: It's probably rough af and messy, but it's better to put something out there to play around with and improve as time goes on. (I'd honestly want to refactoring everything from the start, but that'd waste a lot of time and not having something out there for others to check isn't a good thing imo) You can read about the DNN project (read me and node-policy) and its NIPs (specifically NIP-DN) here:

Gitea

DNN

A decentralized, Bitcoin-anchored naming system for nostr and the web.

Couldn't be at #soveng unfortunately for SEC-06 (Identity) and SEC-07 (Network, ICANN DNS/IANA), this project pretty much fits for both cohorts. Identity & Signers (SEC-06): I made a desktop signer, DENOS, that's basically the user's nostr identity manager, that's also a wallet manager (eCash, focusing on nutzap management, and native bitcoin with both native segwit and taproot for two different purposes, DNN ID/TLD acquisition & management, local signing flow and a username/password sign-in flow, and later down the line I'd add what I'm calling Nostr Silent Payments (multi-currency, Bitcoin multisig but with good/clear UX, and a merchant e-commerce POS system (that includes traditional fiat payments). When a new user comes and generates a nostr keypair, they don't have to do anything else aside from that and you can immediatly send them eCash (nutzap focused, so no heavy token management), native bitcoin, or (later) other crypto and their tokens. And if they grab a DNN ID, aside from turning their npub (63 chars of gibberish) into a human-readable/memorable/usable/locally-meaningful ID (8-16 chars), it would also decently add to their WoT score from day 0. The Network Stack (SEC-07): There's a lot here, but focused on the ICANN-DNS problem as well as the Certificate Authority problem. With DNN, you can now have https://example.nabandonaread or https://example.naboutzook , where you acquire a Top-Level Domain (TLD) by sending yourself bitcoin from your bitcoin address that was derived from your npub and publishing a few events (DENOS has this function / as easy as it can be), and after acquring a TLD, you can have many domains at no extra cost. Forever yours, no requiring payments, no auctions, no fomo, and no trading, as simple and as fast and as cost-effect as it can be, and scales well (and it doesn't add anything to Bitcoin). SSL/TLS doesn't require CA as well, the cert would be self-signed (still secure) and you can put a thousand year validity if you want (set and forget). It should also be prepped (i hope, didn't do much testing on this part) for a Tollgate and FIPS future. Other: DNN solves other problems as well, secondary-effect benefits: - Nostr relay discovery problem (solves missing posts/messages, etc) - Relay centralization (no need to post or read from popular relays) - Impersonations (easily identify the correct person to follow) - Long event addresses (shorten event post from 150-260 chars to 18-26 chars) - Unfamiliar login flow (bringing back traditional username/password login flow, but evovled) - More Hit me up with any questions/feedback/topics, publically or privately, text or call (or in VRC, that would be fun y not x3) about any of this, especially if you want to implement DNN support in your nostr client (I forked Jumble and added support for it there, including some of the other benefits/NIPs like username/password login, local signer login, ID resolution, event addressing shortening, but forgot to add node query for user relay to be utilized so perhaps later), check it out:

Jumble

A user-friendly Nostr client for exploring relay feeds

#nostr #DNS #ICANN