JD on Nostr: I found this image and the text elsewhere but it seems that this is what's been ...
I found this image and the text elsewhere but it seems that this is what's been implemented on nostrgram.co for DMs.
"Every interaction in Nostr is represented by an event. These events are publicly available, which makes privacy hard. When two users want to send private messages to each other, they can protect the content of the message by encrypting it. The metadata included with these messages however is free for everyone to look at. Every event in nostr contains the public key of the author. NIP04 states that every direct message should also include the pubkey of the receiver as one of the tags. This way, other clients on the network can see all direct messages sent over the network with their sender and receiver. The timestamp of every message is leaked as well.
Like every other computer science problem, this leaking of metadata can be partially solved by adding a layer of abstraction. A shared secret between every sender and receiver is used as the key to encrypt the content of the messages. This shared secret is calculated using a combination of the private key and public key of the users. Only they have enough information to calculate the secret and decrypt the messages sent between them.
This hash of this shared secret can be used to create the layer of abstraction between sender and receiver. Both A and B can split up the hash in two parts. A uses the first part (389) as a secret inbox (sending inbox) where his messages for B are sent to. A uses the second part (273) of the shared secret' hash as a secret inbox for B to deliver messages (receiving inbox). B can derive the same inboxes, however his receiving inbox is the sending inbox of A and his sending inbox is the receiving inbox of A. Since no other users can calculate these inboxes, a private way to send messages between A and B has been established
For A to receive messages from B with this approach, he is required to manually add B to his chat client, since there is no way for the client to know where to look for messages without having a partner to calculate the shared secret from. This is not ideal, but does eliminate spam as a nice bonus. The timing of the messages is still public and could be used to derive probabilistic links between sender & receiver. The more messages are sent over the network, the harder it becomes to create these links."
"Every interaction in Nostr is represented by an event. These events are publicly available, which makes privacy hard. When two users want to send private messages to each other, they can protect the content of the message by encrypting it. The metadata included with these messages however is free for everyone to look at. Every event in nostr contains the public key of the author. NIP04 states that every direct message should also include the pubkey of the receiver as one of the tags. This way, other clients on the network can see all direct messages sent over the network with their sender and receiver. The timestamp of every message is leaked as well.
Like every other computer science problem, this leaking of metadata can be partially solved by adding a layer of abstraction. A shared secret between every sender and receiver is used as the key to encrypt the content of the messages. This shared secret is calculated using a combination of the private key and public key of the users. Only they have enough information to calculate the secret and decrypt the messages sent between them.
This hash of this shared secret can be used to create the layer of abstraction between sender and receiver. Both A and B can split up the hash in two parts. A uses the first part (389) as a secret inbox (sending inbox) where his messages for B are sent to. A uses the second part (273) of the shared secret' hash as a secret inbox for B to deliver messages (receiving inbox). B can derive the same inboxes, however his receiving inbox is the sending inbox of A and his sending inbox is the receiving inbox of A. Since no other users can calculate these inboxes, a private way to send messages between A and B has been established
For A to receive messages from B with this approach, he is required to manually add B to his chat client, since there is no way for the client to know where to look for messages without having a partner to calculate the shared secret from. This is not ideal, but does eliminate spam as a nice bonus. The timing of the messages is still public and could be used to derive probabilistic links between sender & receiver. The more messages are sent over the network, the harder it becomes to create these links."