waklaf_21 on Nostr: I know there is a problem with metadata leaking who chats with who in nostr protocol ...
I know there is a problem with metadata leaking who chats with who in nostr protocol when sending messages (both individual or group messages).
So I was thinking about it fow a while and I came up with an idea that could maybe at least partially help to solve or minimize this problem.
What if we implemented hierachic deterministic accounts and their derivation from one master key (seed, nsec...) and it would then allow you to generate new pair of keys for each conversation. Then you wouldn't have any connection between the people in conversation and their "real" (publicly known) pseudonyms they use for other nostr things.
I would like to explain whole process in detail:
First, the sender of the first message (or message request) sends message from his newly generated account to recipient's publicly-known npub (sender encrypts the message with recipient's npub). The message contains his publicly-known npub signed by his corresponding nsec, so the recipient can verify who send message request and it also contains another new npub to break the link between original contacting message and upcoming conversation. Then as a reply original recipient sends message from his newly generated account also containing publicly-known npub signed by corresponding nsec. This way they both know they are talking with the person who they wanted to talk with. They can know freely send each other message from new accounts and there is a very little link to original identity.
Only thing publicly visible to others on relays, is the fact somebody contacted this exact person and after a while "somebody else" contacted somebody who is completely unknown to other members of network. There is no way of connecting these two events if many people would chat at the same time and there could also occur slight delay (maybe even hours, days) between first contact (message request) and reply (accepting message request.
Only one entity that can now connect two events (or two accounts) is, I think, sender's and recipient's client.
Let me know, if this idea already exists or anything in it doesn't make sense to you. If it is useful maybe we could add another NIP...
#nostr #nip #message #messages #chat #chats #relays #nometadata #plebchain #grownostr
So I was thinking about it fow a while and I came up with an idea that could maybe at least partially help to solve or minimize this problem.
What if we implemented hierachic deterministic accounts and their derivation from one master key (seed, nsec...) and it would then allow you to generate new pair of keys for each conversation. Then you wouldn't have any connection between the people in conversation and their "real" (publicly known) pseudonyms they use for other nostr things.
I would like to explain whole process in detail:
First, the sender of the first message (or message request) sends message from his newly generated account to recipient's publicly-known npub (sender encrypts the message with recipient's npub). The message contains his publicly-known npub signed by his corresponding nsec, so the recipient can verify who send message request and it also contains another new npub to break the link between original contacting message and upcoming conversation. Then as a reply original recipient sends message from his newly generated account also containing publicly-known npub signed by corresponding nsec. This way they both know they are talking with the person who they wanted to talk with. They can know freely send each other message from new accounts and there is a very little link to original identity.
Only thing publicly visible to others on relays, is the fact somebody contacted this exact person and after a while "somebody else" contacted somebody who is completely unknown to other members of network. There is no way of connecting these two events if many people would chat at the same time and there could also occur slight delay (maybe even hours, days) between first contact (message request) and reply (accepting message request.
Only one entity that can now connect two events (or two accounts) is, I think, sender's and recipient's client.
Let me know, if this idea already exists or anything in it doesn't make sense to you. If it is useful maybe we could add another NIP...
#nostr #nip #message #messages #chat #chats #relays #nometadata #plebchain #grownostr