Old Nostr DM (NIP-4) integrates four capabilities into a single Nostr keyโit serves as an ID, an encryption key, a receiving address, and a sending address.
The encryption key in NIP-4 does not change, so NIP-4 messages lack both forward secrecy and backward secrecy.
Consequently, if the private key is compromised, both historical and future messages can be exposed.
The receiving and sending addresses remain constant, which poses a severe issue for metadata privacy in NIP-4 messages;
Everyone can see who (ID) is sending messages to whom (ID).
Currently, most Nostr apps use NIP-4 for DM functionalities, such as Damus and Primal.
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
New Nostr DM (NIP-17) integrates three capabilities into a single Nostr keyโit serves as an ID, an encryption key, and a receiving address.
Kind-17 separates the sending address from the ID, making the sending address random and concealing the sender's real ID, thus improving metadata privacy.
The encryption key in NIP-17 does not change, so NIP-17 messages also lack forward secrecy and backward secrecy. Once the private key is leaked, both historical and future messages will be compromised.
The receiving address remains constant, so there is still a slight issue with metadata privacy in NIP-17 messages; everyone can see who (ID) is receiving messages.
Apps like 0xchat and Amethyst use NIP-17 to implement DM functionalities.
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
In Keychat, the ID, encryption key, receiving address, and sending address are separated.
The encryption key, the receiving address, and the sending address are updated independently and continuously.
Keychat's encryption key is derived using the Signal protocol, and each message uses a unique encryption key, which is deleted after use.
Thus, Keychat messages have both forward secrecy and backward secrecy. Even if an encryption key is compromised, only the current message can be leaked, and historical and future messages remain secure.
Keychat's sending address is randomly generated for each message.
Therefore, external parties do not know the sender's ID.
Keychat's receiving address is derived using the Signal protocol, with almost every message using a unique receiving address.
Thus, external parties do not know the receiver's ID.
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
However, it's important to emphasize that NIP-4 and NIP-17 offer superior multi-device synchronization capabilities because they integrate three capabilities into a single Nostr keyโit serves as an ID, an encryption key, and a receiving address.
Thread
Login to reply
Replies (23)
PSA
Keychat
Old Nostr DM (NIP-4) integrates four capabilities into a single Nostr keyโit serves as an ID, an encryption key, a receiving address, and a sending address.
The encryption key in NIP-4 does not change, so NIP-4 messages lack both forward secrecy and backward secrecy.
Consequently, if the private key is compromised, both historical and future messages can be exposed.
The receiving and sending addresses remain constant, which poses a severe issue for metadata privacy in NIP-4 messages;
Everyone can see who (ID) is sending messages to whom (ID).
Currently, most Nostr apps use NIP-4 for DM functionalities, such as Damus and Primal.
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
New Nostr DM (NIP-17) integrates three capabilities into a single Nostr keyโit serves as an ID, an encryption key, and a receiving address.
Kind-17 separates the sending address from the ID, making the sending address random and concealing the sender's real ID, thus improving metadata privacy.
The encryption key in NIP-17 does not change, so NIP-17 messages also lack forward secrecy and backward secrecy. Once the private key is leaked, both historical and future messages will be compromised.
The receiving address remains constant, so there is still a slight issue with metadata privacy in NIP-17 messages; everyone can see who (ID) is receiving messages.
Apps like 0xchat and Amethyst use NIP-17 to implement DM functionalities.
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
In Keychat, the ID, encryption key, receiving address, and sending address are separated.
The encryption key, the receiving address, and the sending address are updated independently and continuously.
Keychat's encryption key is derived using the Signal protocol, and each message uses a unique encryption key, which is deleted after use.
Thus, Keychat messages have both forward secrecy and backward secrecy. Even if an encryption key is compromised, only the current message can be leaked, and historical and future messages remain secure.
Keychat's sending address is randomly generated for each message.
Therefore, external parties do not know the sender's ID.
Keychat's receiving address is derived using the Signal protocol, with almost every message using a unique receiving address.
Thus, external parties do not know the receiver's ID.
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
However, it's important to emphasize that NIP-4 and NIP-17 offer superior multi-device synchronization capabilities because they integrate three capabilities into a single Nostr keyโit serves as an ID, an encryption key, and a receiving address.
View quoted note →
What he said. Such a long way for me to go to understand the #nostr #protocol.
The key and encryption stuff is the hardest ๐
Much hard but this young Padawan strive will.
Love how fast this is moving already.
Are you using the new nip-104 mls messaging proposed by JeffG?
We are using signal protocol to encrypt one-on-one chat and small group.
Good explanation, thank you!
็ฐๅจ็ #nostr ็โๅฏไธๅ็ง้ฅ่งๅโไบๅฎไธๆฏไธไธชๅทจๅคง็ๆผๆด่ฎพ่ฎกใ
ๅบ่ฏฅๆฏ่ฎพ่ฎกๆไธๅฅๆๆ้ๅ็็ง้ฅๆๅบ้ๅ๏ผ{<โ ไธปๅฏ้ฅ,โก ่ทจๅฎขๆท็ซฏๆดปๅจๅฏ้ฅ,โขๅๅธๅฏ้ฅ>}ใ
ไฝๆ้กบๅบๆๅๅฏ้ฅๅฆไฝๆ้ซๅฎๅ
จๆง๏ผ
So has anyone messed with this? Anyone wanna give it a try?
Keychat
Old Nostr DM (NIP-4) integrates four capabilities into a single Nostr keyโit serves as an ID, an encryption key, a receiving address, and a sending address.
The encryption key in NIP-4 does not change, so NIP-4 messages lack both forward secrecy and backward secrecy.
Consequently, if the private key is compromised, both historical and future messages can be exposed.
The receiving and sending addresses remain constant, which poses a severe issue for metadata privacy in NIP-4 messages;
Everyone can see who (ID) is sending messages to whom (ID).
Currently, most Nostr apps use NIP-4 for DM functionalities, such as Damus and Primal.
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
New Nostr DM (NIP-17) integrates three capabilities into a single Nostr keyโit serves as an ID, an encryption key, and a receiving address.
Kind-17 separates the sending address from the ID, making the sending address random and concealing the sender's real ID, thus improving metadata privacy.
The encryption key in NIP-17 does not change, so NIP-17 messages also lack forward secrecy and backward secrecy. Once the private key is leaked, both historical and future messages will be compromised.
The receiving address remains constant, so there is still a slight issue with metadata privacy in NIP-17 messages; everyone can see who (ID) is receiving messages.
Apps like 0xchat and Amethyst use NIP-17 to implement DM functionalities.
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
In Keychat, the ID, encryption key, receiving address, and sending address are separated.
The encryption key, the receiving address, and the sending address are updated independently and continuously.
Keychat's encryption key is derived using the Signal protocol, and each message uses a unique encryption key, which is deleted after use.
Thus, Keychat messages have both forward secrecy and backward secrecy. Even if an encryption key is compromised, only the current message can be leaked, and historical and future messages remain secure.
Keychat's sending address is randomly generated for each message.
Therefore, external parties do not know the sender's ID.
Keychat's receiving address is derived using the Signal protocol, with almost every message using a unique receiving address.
Thus, external parties do not know the receiver's ID.
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
However, it's important to emphasize that NIP-4 and NIP-17 offer superior multi-device synchronization capabilities because they integrate three capabilities into a single Nostr keyโit serves as an ID, an encryption key, and a receiving address.
View quoted note →
the explanation of the DMs was made by jb55 and Jeffg at the nostRiga event and you are forgetting the new nip-44 encryption
NIP-44 is just a part of NIP-17; it only handles encryption and is not a complete DM spec.
yes nip-44 is an attempt to improve encryption
also nip-04 is just encryption so you can use it for lists and settings in the clients and also for DM, IOT device.
i was not aware of this nip-17 thanks for bringing it to my attention, now adding its kind to my library so it is treated as private
well, so it is all understood anyway... for now it's only used in relay code but having a comprehensive kind library means including these others, 14, 13, which don't appear as events on the wire but content of wire events
oh yes, if the relay is to be able to implement a chatbot such as for managing and alerts regarding subscriptions it does need to have the ability to parse them in the manner of a client
That's a great explanation. Do you also have plans to make a version for desktops (linux) ? For privacy, I try to limit my use of phones.
We use the Flutter framework, so we should be able to build a Linux version.
That's great news. Thank you!
gift wrap your dm's (NIP-17)
Keychat
Old Nostr DM (NIP-4) integrates four capabilities into a single Nostr keyโit serves as an ID, an encryption key, a receiving address, and a sending address.
The encryption key in NIP-4 does not change, so NIP-4 messages lack both forward secrecy and backward secrecy.
Consequently, if the private key is compromised, both historical and future messages can be exposed.
The receiving and sending addresses remain constant, which poses a severe issue for metadata privacy in NIP-4 messages;
Everyone can see who (ID) is sending messages to whom (ID).
Currently, most Nostr apps use NIP-4 for DM functionalities, such as Damus and Primal.
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
New Nostr DM (NIP-17) integrates three capabilities into a single Nostr keyโit serves as an ID, an encryption key, and a receiving address.
Kind-17 separates the sending address from the ID, making the sending address random and concealing the sender's real ID, thus improving metadata privacy.
The encryption key in NIP-17 does not change, so NIP-17 messages also lack forward secrecy and backward secrecy. Once the private key is leaked, both historical and future messages will be compromised.
The receiving address remains constant, so there is still a slight issue with metadata privacy in NIP-17 messages; everyone can see who (ID) is receiving messages.
Apps like 0xchat and Amethyst use NIP-17 to implement DM functionalities.
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
In Keychat, the ID, encryption key, receiving address, and sending address are separated.
The encryption key, the receiving address, and the sending address are updated independently and continuously.
Keychat's encryption key is derived using the Signal protocol, and each message uses a unique encryption key, which is deleted after use.
Thus, Keychat messages have both forward secrecy and backward secrecy. Even if an encryption key is compromised, only the current message can be leaked, and historical and future messages remain secure.
Keychat's sending address is randomly generated for each message.
Therefore, external parties do not know the sender's ID.
Keychat's receiving address is derived using the Signal protocol, with almost every message using a unique receiving address.
Thus, external parties do not know the receiver's ID.
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
However, it's important to emphasize that NIP-4 and NIP-17 offer superior multi-device synchronization capabilities because they integrate three capabilities into a single Nostr keyโit serves as an ID, an encryption key, and a receiving address.
View quoted note →
I'm learning more
nevent1qqs0cvqrmp9t78f3f59k5sg99pl8037cfz0wwkvq99yfprwr3whtfsgpr3mhxue69uhkummnw3ezucnfw33k76twv4ezuum0vd5kzmqwj8fsp
Great info! Thank you. I wonder if there might be a place for two kinds of encrypted chat, a more ephemeral one that cannot be recovered with just an nsec, and a more historical version that remains accessible with an nsec?
