Avatar
Blake 2y ago

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 - but it comes with an insane privacy cost. Worse than todays social networks. Are we building something worse?

A public following list is fine. But I want a private one too. I want private lists. I want private block lists or mutes. I want private bookmarks. I want private connected relays. And so on.

The current client app approach is basically ‘give the government a direct event feed for everything you do or have, in a nice standardise format for them to process’.

We really need to rethink the public first mindset in Nostr clients. Most data can be synced using iCloud or something that’s not public - and made public by choice by the user as needed. You can even store the data as Nostr events locally without publishing if you like that format.

Let’s not build a privacy nightmare..

Reply to this note

Please Login to reply.

Discussion

Avatar
133332 2y ago

#[0]

Avatar
Lurking Cat 2y ago

Let's see...

Private mute: snort.social already implemented this along with public block list

Private bookmark: not yet but almost, CMIIW, Nostros implement public bookmark in latest release

Private relay: if you refer to only whitelisted can read and write (not like current paid relay who allow read by everyone) then NIP-42 possible to achieve that

Avatar
Lurking Cat 2y ago

For the privacy issue, i think it has became secondary issue since the inception. Because, at first, nostr design is mainly focused on censorship-resistance protocol.

"The simplest open protocol that is able to create a censorship-resistant global "social" network once and for all." - Nostr Github

But, truly agree that privacy issue should also be addressed properly. :)

Avatar
Lurking Cat 2y ago

Food for thought ...

#[0]

Avatar
⚡️🌱🌙 2y ago

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.

Avatar
Blake 2y ago

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.

Avatar
DZC 2y ago

Agree.

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

Avatar
⚡️🌱🌙 2y ago

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.

Avatar
xiangcai 2y ago

#[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?

Avatar
Lurking Cat 2y ago

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)

Avatar
brianco 2y ago

This is important. There should be a continuum that includes private relays and activity.

Avatar
solobalbo 2y ago

I'm sure privacy solutions will be implemented with time, but being uncensorable first was a must.

Avatar
daniele 2y ago

Yes a protocol direction in this way is needed. And the data should be non only encrypted but also detached from the profile. For example we can deterministically derive a new private key from the main one and use it to encrypt the lists.

Poor man temp solution: attach the encrypted blob as a metadata field and retrieve it when needed.

The privacy weakness here is the writing relay, that via data analysis can match the two keys.

So let's create a way where users in a P2P collaborative fashion randomly send each other this events, adding a new encryption layer to avoid comparing them, with the goal to broadcast it to other relays decoupling the sender and the config-key.

I suspect that using somehow DM for all this, to store the full list/config payload too, will also help to obfuscate people private chats, that is another critical point of the actual protocol.

Could works?

Avatar
Blake 2y ago

Certainly worth experimenting with. Not all event data is desirable to be so easily linkable - p2p could help. But maybe event another sister protocol would be ideal using privacy preserving tech like mixing, etc.

One downside could be that if you pay a relay to persist your data, and they can’t easily identify or link data back to your pubkey, they can’t know to persist it.

Avatar
daniele 2y ago

A 1000 items list is about ~65kB (64 bytes + 1 byte separator), let's double it for the encryption layers and sum up to 150kB adding some other config data.

With 124GB we accommodate 1M users, that pessimistically could read+write 1-2 times a day to do automatic backups; 2M operations are 22req/sec (11 read + 11 write), perhaps doable on a low/middle range VPS that can survive by anonymous donations.

Avatar
AAA 2y ago

There are dozen services can do things you want, nothing but Nostr can do information communication very well. Nostr, IMO it is like HTTP/web to the early Internet.

Avatar
umu 2y ago

people haven't learned from the usenet and people will continue to repeat the mistakes made in ye olden days that we should've learned from. the cycle continues until we make an effort to stop it.

34
royaoid 2y ago

keets approach is better for privacy, nostr is more tilted for public but hopefully they get combined

34
royaoid 2y ago

sync using icloud? for privacy? are you fucking larping?

12
Carlos 2y ago

💯

One reason I like the Gossip client is it supports local follow lists. Better privacy + no risk of having other clients overwrite it, which looks like a common issue.