Oddbean

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.