With this PR, multiple keys and key shares in a single message are handled correctly. When the keyper receives a decryption trigger with at least one new identity, it generates a decryption key shares message for all identities. When it receives a decryption key shares message that enables it to generate at least one new decryption key, it generates a decryption keys message for all identities. When it receives a decryption keys message, it inserts all keys into the db.
An alternative would be to only consider new identities, eg if the keyper receives a trigger for identities 1 and 2, but for identity 1 the share has already been sent, send a shares message only for identity 2. However, this would be inconvenient at the receiver's side, as effectively a single trigger would be broken up into multiple decryption keys messages, which they would have to piece together in the end. During normal operation (ie all keypers broadcast all requested shares), the outcome is the same.
With this PR, multiple keys and key shares in a single message are handled correctly. When the keyper receives a decryption trigger with at least one new identity, it generates a decryption key shares message for all identities. When it receives a decryption key shares message that enables it to generate at least one new decryption key, it generates a decryption keys message for all identities. When it receives a decryption keys message, it inserts all keys into the db.
An alternative would be to only consider new identities, eg if the keyper receives a trigger for identities 1 and 2, but for identity 1 the share has already been sent, send a shares message only for identity 2. However, this would be inconvenient at the receiver's side, as effectively a single trigger would be broken up into multiple decryption keys messages, which they would have to piece together in the end. During normal operation (ie all keypers broadcast all requested shares), the outcome is the same.