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.

Reply to this note

Please Login to reply.

Discussion

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 (profile, notes, contact list, reactions, channel messages, spam reports, etc).

Pubkeys may be cheap, however I’m not going to create 100 just to segment or try obfuscate my data. Pubkeys if stored correctly, shouldn’t be throw away use for people - unless that’s their intention.

I have no issue with 1,000 NIPs that may content private/sensitive information being drafted - that’s 100% fine - the issue is that data being published by default by client apps - and not opt-in and clear in UX.

Agree.

Nostr clients should allow the user to chose the relays to publish private data to, if any at all.

I guess a client settings page could include Kind toggles? You can turn some off and lose some features.

Most people are happy to have Google read their emails and sell the data to advertisers so that advertisers can target them for more impromptu purchases.

Privacy has layers too, privacy from your spouse or work colleagues is one thing, but privacy from state actors is something completely different.

#[4] had a saying like [your privacy matters because you’ll never know that meta data they gathered (without your authorization) will be used against you]. If we refer to privacy as “I have full authority to decide which data to be shared to whom”, think #nostr is quite fit for the purpose imho.

However, what happens to our private conversations? I’m actually wondering is DM e2e encrypted or is nostr even an option for private talks?

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 - https://zkproof.org/

3. Schnorr-nizk - https://github.com/sdiehl/schnorr-nizk

I'm not expert in cryptography. Hopefully, someone could give more feedback on this. Basic idea is how to make all events have an opt-in to hide their relations to a pubkey that send the event but still cryptographically proven (Anon Likes of NIP-25, Anon Zaps of NIP-57, Anon Reports of NIP-56)