NIP-31 Incognito Direct Messages

[bmewj]

Here is the first draft for incognito direct messages. Incognito direct messages fix the inbox peeking/metadata leaks of regular NIP-04 DMs by creating disposable identities on which user’s can exchange DMs.

An early proof-of-concept is demoed here: https://youtu.be/tldTGhcVWX8

A full reference client implementation will be released later this week based on Hamstr. Opening a PR now to allow preliminary discussion and feedback.

[Ery4z]

I was working on a same implementation on my side without knowing that someone came up with it. I'm questioning if the fact that the message is an incognito should be publicly available as it may leak the information that the user his interacting with someone else than the sender key. I like the idea that in case of a network graph "attack" the attacker don't know if the sender of the incognito message is a real user or not.

Also in your video you talk that you have to trust your relay which is true. But I'm working on a proof of concept for client to send the incognito type message through a tor docker container. Depending on the client this could be a solution, for now it is working in go

[antonleviathan]

I'm questioning if the fact that the message is an incognito should be publicly available as it may leak the information that the user his interacting with someone else than the sender key. I like the idea that in case of a network graph "attack" the attacker don't know if the sender of the incognito message is a real user or not.

I'm not sure you understood the proposed solution fully, because after the initial invite message, both parties switch to a new set of key pairs, and those are not related to their well known key pairs in any way (but the relay trust assumption remains).

But I'm working on a proof of concept for client to send the incognito type message through a tor docker container.

Tor is ok, but this is a separate concern for us and something we wouldn't conflate with this problem. Tor solves the network layer metadata issue. Mixnets are likely a better solution and there are some efforts towards integrating nym with nostr. Additionally, there are implications around paid relays that make this issue even more difficult as paid relays require you to reveal your identity in order to write to them.

[Ery4z]

I'm not sure you understood the proposed solution fully, because after the initial invite message, both parties switch to a new set of key pairs, and those are not related to their well known key pairs in any way (but the relay trust assumption remains).

My bad indeed I thought the kind 1031 was for the invite message and so that the invite was distinguishable from a regular nip04.

[bmewj]

My bad indeed I thought the kind 1031 was for the invite message and so that the invite was distinguishable from a regular nip04.

Yes, as it stands the only messages that are publicly attributed to well-known identities are indistinguishable from regular NIP-04 DMs, and only hint towards a well-known identity receiving an invite, but it's not clear from whom.

[bu5hm4nn]

I have been reading all the DM discussions today and this is the scheme I like best so far. However I do see some ideas to improve security further:

a. If we discard backward compatibility (but give this a good user facing name like 'secure DM') users could advertise on their profile that they can accept NIP-31 DM's and this NIP could define a new message kind for the initiation of DM's so that a cryptographic scheme better than aes-256-cbc can be used even for the initial contact.
I believe that is reasonable to do because nostr is not and should not be at the point where we conserve at all cost and try not to break stuff at all costs. If we adopt that mentality we will not move forward meaningfully.

b. Store the seed to the profile with better encryption than NIP-04's aes-256-cbc

c. NIP-07 and hardware extensions could be asked to do the disposable generation and eliminate the need for storing the seed

I think the proposed scheme could also be used to do secret NIP-100 webrtc connections.

[antonleviathan]

Thanks for the feedback @bu5hm4nn.

While I agree, I would suggest that the improvements around the encryption be treated separately as this privacy related proposal is not coupled with the type of encryption Nostr currently uses. Keeping the scope of this NIP focused will help us get more support for it because it's easier to understand and implement this way.

a. I think we should fix NIP-04 encryption, and just leverage that for NIP-31
b. This upgrade can be introduced after we upgrade the encryption algorithm Nostr uses
c. I think this is also something that can happen down the road, but shouldn't be a blocker. We could add this in the "Potential Improvements" section, and implement support for it down the road. Hardware support in general needs more energy spent on it.

So basically I'm just trying to keep the scope here minimal, but agree with your ideas. That being said, I will be spending some time and energy on contributing to improving the encryption standard separately from this, so please find me on Nostr and let's chat more about it :)

[bu5hm4nn]

@antonleviathan I think creating a new kind with an improved encryption scheme is way less painless than upgrading an existing one. We would have no way to distinguish which clients support the upgraded scheme as NIPs don't have a version, they are the version. I rather think NIP-04 should be deprecated after a new better standard is established, in my mind that is more clear and less confusing for the network.

[antonleviathan]

Fair enough, I can see the logic in what you're saying, but regardless, I don't think it would be good to make that part of this scope. We'd be adding a lot of additional considerations that will make it much harder to make this thing a reality. In the hypothetical that we get buy in for doing both in one NIP I wouldn't be against it, but that seems unlikely.

[antonleviathan]

@bmewj please close this, there is a new kid on the block: #1206