NIP-59: improved direct messages

[davestgermain]

This NIP borrows the ideas from the SimpleX Messaging Protocol in order to obscure the metadata of encrypted direct messages. It adds an initial negotiation process, allowing for encrypted, private communication across multiple relays.

[fyookball]

Improving direction messaging is a good idea. I like the general direction, but I think it could be improved by only having either Bob or Alice send a private encrypted message, not both of them. You could do it by having Alice create ephemeral key A2, which informs B1 that he should create B2 to talk to A3. Also, there is low hanging fruit in terms of fixing issues with NIP-04 that are considered "harmful". #107

[davestgermain]

I think it could be improved by only having either Bob or Alice send a private encrypted message, not both of them. You could do it by having Alice create ephemeral key A2, which informs B1 that he should create B2 to talk to A3.

Thanks for pointing to that thread. Some of the ideas seem similar to this proposal, if I'm reading correctly. (I am also not a cryptographer. I think ease of implementation should be a consideration here)

Maybe it's not clear in the description, but only one kind=4 event is ever sent. Both parties send an encrypted "request event", but Bob sends his to Alice's A2 at Alice's relay.

Here's a program that demonstrates the negotiation.

Also, there is low hanging fruit in terms of fixing issues with NIP-04 that are considered "harmful". #107

As far as changing the encryption method, that's beyond my pay grade. There were a lot of ideas in that ticket thread, but somebody's got to pick one. Using nostr events gives you a lot "for free" (for instance, I'm using ephemeral events and the expiration tag in this proposal). My preference is to leverage the existing tools rather than introduce totally new technologies to the stack.

One possible change could be, instead of specifying a relay to connect to, Alice could send an identifier as specified in NIP-39, to recommend connecting to telegram, signal, etc to continue the conversation.

[shafemtol]

See also:

• #303 (the discussion started on NIP-04 crypto but turned into a more general one about a better DM system)
• my WIP PRs NIP-93: Secret Events #306 and NIP-92: Rendezvous Beacons #333, which are meant as building blocks for a later NIP for DMs
• NIP-24: Private Messages #56, which to me looks rather similar to this proposal

[mikedilger]

As a general comment (reserving the ability to comment on the method later on) you cannot change the meaning of kind=4. If you change how the process works it must be a new event kind. Nostr must always be backwards compatible and clients that do it the old way must continue to work.

As the proposal stands, Bob at key 18d is going to receive a jsonified request and his client will render it like it was a DM and Bob is going to say WTF?

[ntheden]

See also:
NIP-31 Incognito Direct Messages #410

[vishalxl]

Bob's client will see a DM from an unknown contact, will decrypt and validate that the request is addressed to him (the "p" tag is his public key).

The initial invitation, coming from an unknown contact, is a weak point here, from the angle that any well known public key could be spammed by random spammers, and then the recipient's client could ignore messages from unknown keys under attack from spammers.

If this initial invitation could be sent from a well-known pubkey ( of Alice) to Bob's, then there is more meta-data leak ( that Alice sent Bob an invite), but that's it, and after that there should not be a way to know whether Bob replied to Alice or not; that could be done to and may be considered.

[ntheden]

The initial invitation, coming from an unknown contact, is a weak point here, from the angle that any well known public key could be spammed by random spammers

Is it reasonable to spend resources decrypting potential spam? Because if it is, then the contents of the invitation can include a signature from Alice of the message metadata proving it's from her, and then meta data is not leaked.

[staab]

Solved by nip 17