Oddbean

That's fine, because academic standard writing is not good, but just developing everything in "stealth mode" is not the correct solution either. A standard should have had input from other interested parties, so everybody can be happy(ish) with the final form of the thing. If you just come up with everything you're setting yourself to being the owner of the said standard, the first mover by far, likely able to change it at your whims. Or you're setting yourself to failure too, as other potential implementors may just dislike everything you did and implement a different standard -- and that is bad for everybody. Notice that so far you haven't even given a hint of what you're doing, just marketing claims of some wonder tech that is soon to be here. Even if you're right on your claims, it would still be much better to have more dialogue in the process.

In terms of metadata privacy, NIP-17 is better than NIP-4. NIP-17 provides better protection for the sender's ID, but it does not sufficiently protect the recipient's ID. The visibility of someone continuously receiving messages is also a metadata privacy issue. For a DM (a feature subsidiary to microblogging), this might be an acceptable tradeoff, as users can receive and decrypt messages on multiple clients. However, for an application using Nostr for a chat app, privacy should be a priority.

DM (a subsidiary feature of microblogging) and chat apps (primarily focused on chatting) are not exactly the same, and they face different tradeoffs. A chat app needs to consider end-to-end encryption with both forward and backward secrecy, as well as the ability to conceal the IDs of both the sender and the recipient.

Since we are considering using NIP-17, we delved deeper into it. So, let's revisit your question, "What do you think of NIP-17?" NIP17 defines a message structure as kind1059(kind13(kind14)). We are puzzled as to why it is necessary to apply NIP44 encryption twice. Kind13 (seal) is responsible for digitally signing and encrypting the message. Since kind1059 has already encrypted the message, there is no need for kind13 to encrypt it again. Therefore, the only role left for kind13 is digital signing. We wonder why the digital signature cannot be directly incorporated into kind14. A digitally signed kind14 would effectively be equivalent to kind1. Hence, we believe that kind1059(kind1) would be a simpler implementation. Moreover, changing the timestamp of kind1059 messages to a random time from the past two days could lead to relays repeatedly pushing notes to clients, potentially burdening both clients and relays. We are uncertain if this tradeoff is justified. https://github.com/nostr-protocol/nips/blob/master/17.md https://image.nostr.build/3adb9c871474866d80651ba8c12e3c18311d231a81fb91e70289c7a674e2d822.jpg https://image.nostr.build/efd502001675422031621d3fdfcf1a5a314355fc82c82b22b992f1e6f992c060.jpg

Maybe don't actually replace NIP-04 since it's in Keychat already, even if deprecated, but have both NIPs implemented, each with its own warnings. So Keychat could have Signal-encrypted chats, normal NIP-04 chats (both already in) and NIP-17 chats.

If the recipient of the message or someone else maliciously publicizes the sender's message, even the kind1059(kind13(kind14)) structure cannot prevent it. This is because they could write a post step by step proving that kind14 was written by the sender.

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.

>Notice that so far you haven't even given a hint of what you're doing, just marketing claims of some wonder tech that is soon to be here. This is not a fair assessment. So far, we have posted many notes explaining how Keychat is designed. Because the design of Keychat is very simple and intuitive, even users without a technical background can understand it.