Create a private chat for buyer and seller

[Catrya]

After users starts to talk to each other the client should make them chat sending nostr events with kind 14 and the content encrypted with nip44 algorithm, this messages leaks metadata exactly the same like nip04, but with nip44 we have the option of allow users to export their conversation key and voluntarily gave it to an admin if they need, having the opportunity of read the messages from both parties the admin can easily solve the dispute.

But if a user uses the same key for all trades the conversation key would be the same if the trade each other again, so the admin could see older messages, that's why we should force users to use a ephemeral key for each trade.

This goal of this issue is to create a chat between parties after the order is active to exchange directly how the buyer will send the fiat money to the seller.

Must adhere to this design.

[bilthon]

I have a couple of questions. First, since the shared key is a point, how exactly do we apply the Lowent method to convert it into a private key? I see that a hash is used, so the question boils down to whether we hash the compressed or uncompressed version of the shared secret 𝑘.

The second question is about the mechanics of the Lowent chat. Here, both parties retain their own Nostr private keys but send messages to the shared "room" created by their shared secret. To an external observer, it would appear as if both Alice and Bob are sending messages to this third unknown entity. Is that correct?

[Catrya]

The second question is about the mechanics of the Lowent chat. Here, both parties retain their own Nostr private keys but send messages to the shared "room" created by their shared secret. To an external observer, it would appear as if both Alice and Bob are sending messages to this third unknown entity. Is that correct?

Alice and Bob will share a new key and use that key to send DMs to that same key. In the eyes of an observer, a random user will be sending a DM to theyself, and will not be able to link with either Alice or Bob.

[bilthon]

But in that case the client won't be able to distinguish between messages from each party and provide a proper chat UX like mostro web does today.

[Catrya]

Well each user will know what they wrote, since it will only be a chat between 2 people I think it should not generate so much confusion among users, they will just not see their handle placed in the message

[gzuuus]

I have a couple of questions. First, since the shared key is a point, how exactly do we apply the Lowent method to convert it into a private key? I see that a hash is used, so the question boils down to whether we hash the compressed or uncompressed version of the shared secret 𝑘.

k can be used then as a private key, and even do k*G to obtain the public one of the shared secret. So it would be easy to use k as a private key to share between users, at the end both can compute the same secret. In Lowent, it's a bit different since DH isn't used; instead, the SHA-256 of a random string is taken as the private key.

The second question is about the mechanics of the Lowent chat. Here, both parties retain their own Nostr private keys but send messages to the shared "room" created by their shared secret. To an external observer, it would appear as if both Alice and Bob are sending messages to this third unknown entity. Is that correct?

As @Catrya said, both share the private key, so for an external observer it would be like the key encrypting things to itself. This is a mess in a large group, but for two parties it's easy to tidy the chat by, for example, maintaining a registry of sent messages. That's how Lovent works, it maintains an indexDB of sent messages, so you can order them in the chat. Also, another way to go stronger in verification is to use gift wraps (https://github.com/nostr-protocol/nips/blob/master/59.md) or just create an object inside the content with the necessary fields to create an ID and a signature. So, the sender can sign the content inside the encrypted message, and that will allow verifying the signature of the participants without revealing anything to an external observer.

[grunch]

But in that case the client won't be able to distinguish between messages from each party and provide a proper chat UX like mostro web does today.

Another way of fixing this is that the client generate a random number, save it locally and each message send would have this random number, after reading, all messages that have this same number are from you:, everything else are from counterparty:

[bilthon]

True, there are several ways to address the UX of this. A more portable solution is likely what @gzuuus suggested.

However, one critical aspect we might lose here is the non-repudiation of messages. A key advantage of Mostro over LNP2PBot is that we can design the system to keep conversations private until a dispute arises. In the event of a dispute, it would be beneficial for the involved parties to disclose the entire conversation to allow arbitrators to weigh in. By using different keys for different parties, the arbitrator can verify that the conversation history is authentic and untampered, ensuring that each party genuinely sent the messages attributed to them.

For this reason I like the idea of "gift wraps". Their one-time keys for the outermost event is similar to our ephemeral key solution. The timestamp tweaking of seal & gift wrap layer's timestamp to protect against time-analysis attacks is also neat.

[grunch]

True, there are several ways to address the UX of this. A more portable solution is likely what @gzuuus suggested.

However, one critical aspect we might lose here is the non-repudiation of messages. A key advantage of Mostro over LNP2PBot is that we can design the system to keep conversations private until a dispute arises. In the event of a dispute, it would be beneficial for the involved parties to disclose the entire conversation to allow arbitrators to weigh in. By using different keys for different parties, the arbitrator can verify that the conversation history is authentic and untampered, ensuring that each party genuinely sent the messages attributed to them.

For this reason I like the idea of "gift wraps". Their one-time keys for the outermost event is similar to our ephemeral key solution. The timestamp tweaking of seal & gift wrap layer's timestamp to protect against time-analysis attacks is also neat.

Hi @bilthon could create a new issue with a detailed proposal to solve this issue with gift wraps? you can add an explanation like above and some examples to implement it.

thanks

[grunch]

closing it in favor of #29