This would allow either user to forge messages with each others decoy keys since they are both composed of information shared by both parties, is this intended?

@jb55 I guess if one of the users signed a message with the other's decoy key, it wouldn't matter because it's not their actual private key. Can you give an example of how they could forge. I might be misunderstanding.

ah I think I misunderstood, the decoy keys are not used as the new secret keys which is what I thought in the first reading of this... interesting approach!

Yeah, the decoy keys are kinda like P.O. boxes that only the two participants know about. The relay is like the post office in that it knows the two participants have the P.O. boxes (decoy keys) because they are filtering for them but it can't see what's inside.

I really like this. was envisioning something similar but don't know cryptography (yet)

curious if its possible to take this a step further to cover the author? would it be too insecure to do something like this? I believe this would allow you to author notes from decoy public key and sign with decoy private key, so no one would know who the message is from or to (except for the people messaging). if we're trying to remove metadata from DM's (and a lot of people seem to want this) author is probably worth trying to obfuscate as well.

A[sk] = Alice's private key
A[pk] = Alice's public key
A[dsk] = Alice's decoy private key
A[dpk] = Alice's decoy public key
B[sk] = Bob's private key
B[pk] = Bob's public key
B[dsk] = Bob's decoy private key
B[dpk] = Bob's decoy public key
AB[ss] = Alice and Bob's shared secret, derived using ECDH(A[sk], B[pk]) or ECDH(B[sk], A[pk])

Alice's decoy private key is defined as A[dsk] = SHA256(AB[ss]) * A[sk]
Bob's decoy private key is defined as B[dsk] = SHA256(AB[ss]) * B[sk]
Alice's decoy public key is defined as A[dpk] = SHA256(AB[ss]) * A[pk]
Bob's decoy public key is defined as B[dpk] = SHA256(AB[ss]) * B[pk]

apologies if I'm way off with any of this, just trying to learn and was fun to ponder.

Thanks for the feedback! I'm glad you like the proposal. I am not a cryptography person and just learning as well.

You make a great point that the author should be covered as well. I am working on an update for this NIP to address that.

I may take a stab at implementing this in damus since I am intrigued...

@cameri @jb55 I am working on an update to this NIP which allows the sender's pubkey to be obfuscated as well. I will push an updated spec and POC code in a few days.

@RandyMcMillan had this to say: https://twitter.com/RandyMcMillan/status/1582842087409881088