After setting a new identity key as trusted, we retry decryption on all
pending conflicts for that contact. If their identity changed twice in a
row, we can still get a conflict the second time, and should handle it
appropriately.
When resolving conflicts, we should not only discard the old key, but
set the new trusted key to the one the user has verified. Previously, we
would end up trusting the first-seen new key, which may not be the one
the user verified.
// FREEBIE
Related with #278. Redone to include keeping scroll at the bottom when resizing the window, as suggested in #305, and to better fit the current code structure.
This new endpoint should always issue a response to a provisioning
socket so if we don't receive one we should assume the connection has
been lost.
Closes#318
By default, automatically disconnect if no response. This is preferable
because we can sometimes lose connectivity without receiving a close
event from the socket, but it's also possible that the endpoint may not
support responses.
// FREEBIE
saveKeysToDeviceObject is the detector of outgoing identity key errors.
Catch these key errors closer to the source by pulling the
getKeysForNumber into the context of sendMessageToDevices, which lets
it access registerError and the message protobuf.
Previously identity key errors would be uncaught if all existing
sessions with a recipient were closed/deleted, since we would
preemptively fetch the new identity key. The old error handling only
kicked in after a 409/410 response from the server when posting a
message encrypted for a stale session.
// FREEBIE
Previously we would convert a bytebuffer to a string, pass it to
libaxolotl where it would be parsed back into a bytebuffer.
Ideally we would just pass the bytebuffer, but it turns out that
libaxolotl's bytebyffer class is identical but separate from
libtextsecure's bytebuffer class. ¯\_(ツ)_/¯
So instead we pass the underlying array buffer, which is handled
more or less the same way as a bytebuffer, and most importantly,
does not involve any copying.
// FREEBIE
We now disconnect ourselves if we don't get the server's response to a
keepalive request within 30s. This way we will eventually disconnect if
the network goes away but the socket is not closed.*
* See code.google.com/p/chromium/issues/detail?id=197841 and
https://stackoverflow.com/questions/11755605/chrome-websocket-connection-not-closed-when-browser-closed
We will then try to reconnect once a minute (See 8a10c96);
Keepalives belong at this level anyway, since the format is defined by
both the websocket resource protocol and our specific server url
structure.
// FREEBIE
