Damus
Blake · 169w
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...
daniele profile picture
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?
3❤️1
Blake · 169w
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...
daniele · 169w
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 ...
daniele · 169w
/cc #[0] for ruthless evaluation