Due to X3DH's nature of not handling message loss, clients nowadays send PreKeyMessages using the same OTPK until they get a first response indicating that the key exchange was successful. The library already supports receiving multiple PreKeyMessages without deleting the OTPK, but it does not support sending more than one.
This would require
[ ] When sending a first PreKeyMessage, bind the selected OTPK to that jid+device.
[ ] Until receiving a response (*), keep building PreKeyMessages instead of Messages.
[ ] Use the bound OTPK when building these subsequent PreKeyMessages.
[ ] Give the user an API to indicate succeeded delivery, for example when a receipt is received.
Maybe add a PreKeyMessagePolicy as the counterpart to the OTPKPolicy, controlling when to stop building PreKeyMessages.
Before adding all of that complexity, think about whether this is really required.
Don't forget to add migration for the storage if this is added.
Due to X3DH's nature of not handling message loss, clients nowadays send PreKeyMessages using the same OTPK until they get a first response indicating that the key exchange was successful. The library already supports receiving multiple PreKeyMessages without deleting the OTPK, but it does not support sending more than one.
This would require
[ ] When sending a first PreKeyMessage, bind the selected OTPK to that jid+device.
[ ] Until receiving a response (*), keep building PreKeyMessages instead of Messages.
[ ] Use the bound OTPK when building these subsequent PreKeyMessages.
[ ] Give the user an API to indicate succeeded delivery, for example when a receipt is received.
Maybe add a PreKeyMessagePolicy as the counterpart to the OTPKPolicy, controlling when to stop building PreKeyMessages.
Before adding all of that complexity, think about whether this is really required.
Don't forget to add migration for the storage if this is added.