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?

Reply to this note

Please Login to reply.

Discussion

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.

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.

/cc #[0] for ruthless evaluation