keychat on Nostr: Let me use the metaphor of a letter to explain how Keychat processes messages: ...
Let me use the metaphor of a letter to explain how Keychat processes messages: encrypting the content and filling out the envelope.
The content of the message is encrypted using either the Signal protocol or the MLS protocol. These protocols continuously derive new encryption keys behind the scenes for every message, ensuring forward and backward secrecy. Keychat leverages these open-source libraries directly, reusing libsignal and OpenMLS for encryption.
When filling out the envelope, it’s important to understand that the user name, sending address, and receiving address are all separate concepts. The envelope doesn’t include the name. The sending address can be left blank, which effectively means a new random sending address is generated for each message. The receiving address, on the other hand, is constantly rotated—but it must be known only to the two communicating parties, so it can’t be purely random.
Now you might ask: should each message include the next receiving address in its content? That approach works, but there’s a simpler solution. During encryption, a continuously evolving key—tied to the message encryption process and known only to the sender and recipient—can be used to deterministically derive the next receiving address.
Then attach a sat stamp, and finally send it to the Nostr relay.
The content of the message is encrypted using either the Signal protocol or the MLS protocol. These protocols continuously derive new encryption keys behind the scenes for every message, ensuring forward and backward secrecy. Keychat leverages these open-source libraries directly, reusing libsignal and OpenMLS for encryption.
When filling out the envelope, it’s important to understand that the user name, sending address, and receiving address are all separate concepts. The envelope doesn’t include the name. The sending address can be left blank, which effectively means a new random sending address is generated for each message. The receiving address, on the other hand, is constantly rotated—but it must be known only to the two communicating parties, so it can’t be purely random.
Now you might ask: should each message include the next receiving address in its content? That approach works, but there’s a simpler solution. During encryption, a continuously evolving key—tied to the message encryption process and known only to the sender and recipient—can be used to deterministically derive the next receiving address.
Then attach a sat stamp, and finally send it to the Nostr relay.