Damus
Blake · 158w
I feel like perhaps we’re being quick to try and decentralise everything and store all config, data or state in published Nostr events by default 😟 The cross app support Nostr enables is awesome...
⚡️🌱🌙 profile picture
Censorship resistance and secrecy are almost opposites. It’s very difficult to achieve both.

But we can separate thing out a little here. Content (notes) is what we want to be censorship resistant, they are. If you follow a pubkey, you can get their notes from multiple sources.

Pubkeys are where we have privacy questions. But pubkeys are cheap, if you want to do something private, you can create a disposable pubkey then you have privacy/secrecy but with some imposter risk.
3❤️2🤙3
Blake · 158w
The concern isn’t around public keys needing to be private or even anonymous - it’s more targeted toward publishing lots of event kinds by default (without opt-in, or even not being obvious is client UX, including new ones), when all I actually want to publish are kind 0,1,3,7,42,1984,etc (profi...
DZC · 158w
Agree. Nostr clients should allow the user to chose the relays to publish private data to, if any at all.
Lurking Cat · 158w
Could zero knowledge proofs help in this privacy issue? CMIIW, does Nostr really fully tied to Schnorr signature? If not then some hybrid approach maybe can be integrated with some approach like: 1. Bulletproofs+ - https://www.getmonero.org/2020/12/24/Bulletproofs+-in-Monero.html 2. zk-proof - h...