The trust-on-first-use policy leads to problems when receiving messages
from two different devices of a contact before sending a message to them
(as their IdentityKeys will not have been added yet). Since session
trust will be managed externally anyway, this change is not a security
problem, and will allow us to decrypt messages from yet-untrusted
sessions.
We now track preKeys used to establish incoming sessions with us. On
each new established session, we remove the used prekey from PEP. We
have to do this because libaxolotl-java internally clears the used
preKey from its storage, so we will not be able to establish any future
sessions using that key.
XmppConnectionService.sendMessage() now dispatches messages to the
AxolotlService, where they only are prepared for sending and cached.
AxolotlService now triggers a XmppConnectionService.resendMessage(),
which then handles sending the cached message packet.
This transparently fixes, e.g., handling of messages sent while we are
offline.
Previously, the sender was assumed to be the conversation counterpart.
This broke carboned own-device messages. We now track the sender
properly, and also set the status (sent by one of the own devices vs
received from the counterpart) accordingly.
Now checks which part(s) are out of sync w/ local storage, and updates
only those, rather than assuming the entire node corrupt and
overwriting it all (especially relevant for preKey list)
We need a session object in order to build a session from a
PreKeyWhisperMessage, so add an empty one when none exists on receiving
a message.
Warning: this will break right now if the session can not be constructed
from the received message.There will be an invalid session which will
break if we try to send using it.
Bundles are now fetched on demand when a session needs to be
established. This should lessen the chance of changes to the bundles
occuring before they're used, as well as lessen the load of fetching
bundles.
Also, the message encryption is now done in a background thread, as this
can be somewhat costly if many sessions are present. This is probably
not going to be an issue in real use, but it's good practice anyway.
