7650f3003e
There were a couple of issues on how we handle pinned messages: 1) Clock of the message was only checked when saving, meaning that the client would receive potentially updates that were not to be processed. 2) We relied on the client to generate a notification for a pinned message by sending a normal message through the wire. This PR changes the behavior so that the notification is generated locally, either on response to a network event or client event. 3) When deleting a message, we pull all the replies/pinned notifications and send them over to the client so they know that those messages needs updating. |
||
---|---|---|
.. | ||
github.com/protocol/encryption | ||
migrations | ||
multidevice | ||
publisher | ||
sharedsecret | ||
README.md | ||
encryption_multi_device_test.go | ||
encryption_test.go | ||
encryptor.go | ||
persistence.go | ||
persistence_keys_storage_test.go | ||
persistence_test.go | ||
protocol.go | ||
protocol_message.pb.go | ||
protocol_message.proto | ||
protocol_test.go | ||
x3dh.go | ||
x3dh_test.go |
README.md
protocol/encryption package
Hash ratchet encryption
encryptor.GenerateHashRatchetKey()
generates a hash ratchet key and stores it in in the DB.
There, 2 new tables are created: hash_ratchet_encryption
and hash_ratchet_encryption_cache
.
Each hash ratchet key is uniquely identified by the (groupId, keyId)
pair, where keyId
is derived from a clock value.
protocol.BuildHashRatchetKeyExchangeMessage
builds an 1-on-1 message containing the hash ratchet key, given it's ID.
protocol.BuildHashRatchetMessage
builds a hash ratchet message with arbitrary payload, given groupId
. It will use the latest hash ratchet key available. encryptor.encryptWithHR
encrypts the payload using Hash Ratchet algorithms. Intermediate hashes are stored in hash_ratchet_encryption_cache
table.
protocol.HandleMessage
uses encryptor.decryptWithHR
fn for decryption.