Oddbean

However, the sender has signed with their private key in kind13. Therefore, the recipient can step by step prove to the public that the message was written by the sender. "Not your sig, not your event. This is how Nostr works." I don't understand what you mean by this. https://image.nostr.build/ef4f50793e286a501390fcdb7f8c7f9ffa4d6fbb34ac7c4d3f25de0b7a370248.jpg

Yes, kind13 is signed, but kind14 event is encrypted and placed in the content. If you want to expose the encrypted content, you must reveal your private key, which you obviously won't do. But if you don't reveal your private key, then you can only expose a kind14 event that does not contain a sig. Without the sig, it cannot be proven that this event was sent by the sender.

The recipient can calculate the encryption key for kind13 using their own private key and the sender's public key. They only need to disclose this encryption key, not their own private key, to prove that the message was written by the sender, right? I'm not a cryptography expert, so I'm not 100% certain.

Let's continue. Even with a shared key, if it gets exposed, all conversations between the two individuals will be leaked. Furthermore, I can identify who exposed the key. (For the person who exposed the privacy: This person is untrustworthy, and I can choose not to communicate with them.) Additionally, the inner event might not be exposed by the recipient; it could be leaked due to client-side storage or other reasons. An inner event that includes a `sig` is much less secure.

OK, let’s continue. kind1059(kind13(kind14)) VS kind1059(kind1) In the kind1059(kind13(kind14)) model, if the recipient discloses the encryption key, not only will the sender's messages be visible to everyone, but the recipient's own messages will also be visible to everyone. This is disadvantageous for the recipient and advantageous for the sender. In the kind1059(kind1) model, if the sender discloses the unencrypted kind1, everyone can see the messages sent by the sender. However, the sender can also proactively disclose the messages previously sent by the recipient. Furthermore, the sender can identify who disclosed the messages, which is a good thing. In both cases, the sender can determine who disclosed the messages. Finally, regarding the issue of app bugs causing kind14 leaks, it would require extremely poor code quality for this to happen. If you must consider this risk, why not directly encrypt the content using NIP-44? Using kind4(kind4) would be simpler than kind1059(kind13(kind14)). Please note that the kind4 mentioned here uses NIP-44 encryption, not NIP-4 encryption.

I think you missed the point. Kind1059 (kind1) has a problem where the recipient can broadcast kind1 without exposing any keys. However, kind1059 (kind13 (kind14)) requires exposing the share key, right? And kind4 (kind4) leaks metadata and is not even within the scope of discussion. Moreover, I don't think the leakage of kind14 requires poor code. Even very rigorous code can have bugs and be subject to hacker attacks. What we need to do is not to hope for no bugs or leaks, but to ensure security even in the event of a leak.

Yes I think leaking the conversation key would expose the binding between the seal and rumor, not provably, but it would be highly unlikely to find a different conversation key that decrypted into a sensible rumor so effectively. And the conversation key is post-HKDF so it doesn't expose your nsec. This would have been great feedback for NIP-44 development.

As for the timestamp argument, asking for all of them from the last 2 weeks each time you spin up a client isn't going to be signifcant even though you are getting repeats. And if new backdated ones flow in while the client is up, they will come through that same subscription after the initial EOSE without having to ask again. So repeats only happen when you start up a client. I should correct my earlier post, it was NIP-59, the giftwrap NIP, that would have benefitted from the insight that you could dox your DM counterparty without exposing your nsec. Kind 14 is essentially Kind 1 used in this context, except maybe the different kind number helps something. We could have a couple dozen new kind numbers that didn't mean anything different from kind-1 and it wouldn't hurt. I don't personally like seed phrases. They are ok for recovery, but not for login. For login a user wants to remember a passphrase that they get to make up from whole cloth. There are algorithms to map that into a seed phrase. NIP-49 goes from a passphrase to an nsec. nsecs being 256 bits probably can be mapped to a seed phrase too. Everything with sufficient entropy could be mapped into anything else. Just saying there are a lot of possibilities here.

I'm afraid the current Nostr relays don't handle the pushing of events with random timestamps correctly. For example, Alice and Bob are chatting using NIP-17, and both of their chat apps are active. Alice sends Bob a message with a random timestamp from 48 hours ago. The relay not only pushes this message to Bob but also re-pushes all the messages that Alice sent to Bob within the past 48 hours. Alice then sends Bob another message with a random timestamp from 24 hours ago. The relay not only pushes this message to Bob but also re-pushes all the messages that Alice sent to Bob within the past 24 hours.

I don't know what relay you are using but that is wrong. I'm curious what relays are doing this horrible thing and I'll add a test to my relay test suite. I wrote a relay https://github.com/mikedilger/chorus and I assure you it does not behave that way. You connect and subscribe to a 1-week period for DMs. You get all the DMs over that week, then an EOSE. Then when the next DM comes in, dated 7 days ago for example, it shows up by itself under that subscription without any repeats of data that came before the EOSE. This behavior could happen if your client disconnects when it gets an EOSE, because when it reconnects and submits the REQ it will get the entire week again.