On a recent trip through a CPU profile taken while Signal Desktop
churned through a large backlog of messages, it was clear that
console.log was a major source of time spent, primarily the sort
operation required after every new entry is added to the Backbone
collection. So, three different techniques to combat this:
1) Reduce the maximum number of entries in the collection from 5k to 2k
2) No more logging of add/update/remove queue in MessageReceiver
3) No more log entries in Message.handleDataMessage main codepath
FREEBIE
When processing a contact sync with embedded identity key verification info, we
were running overlapping async fetch/save operations on the same conversation
model, causing a race that tends to clobber updates to the contact info.
In this change we extend the application-level contact info handler to block on
a subsequent call to the verification handler, which effectively serializes the
fetch/save calls, and relieves the need for the message receiver to trigger a
seperate event concerning the verification info on contact sync messages.
Fixes#1408
// FREEBIE
* Add support for backup and restore
This first pass works for all stores except messages, pending some scaling
improvements.
// FREEBIE
* Import of messages and attachments
Properly sanitize filenames. Logging information that will help with
debugging but won't threaten privacy (no contact or group names),
where the on-disk directories have this information to make things
human-readable
FREEBIE
* First fully operational single-action export and import!
FREEBIE
* Add migration export flow
A banner alert leads to a blocking ui for the migration. We close the socket and
wait for incoming messages to drain before starting the export.
FREEBIE
* A number of updates for the export flow
1. We don't immediately pop the directory selection dialog box, instead
showing an explicit 'choose directory' button after explaining what is
about to happen
2. We show a 'submit debug log' button on most steps of the process
3. We handle export errors and encourage the user to double-check their
filesystem then submit their log
4. We are resilient to restarts during the process
5. We handle the user cancelling out of the directory selection dialog
differently from other errors.
6. The export process is now serialized: non-messages, then messages.
7. After successful export, show where the data is on disk
FREEBUE
* Put migration behind a flag
FREEBIE
* Shut down websocket before proceeding with export
FREEBIE
* Add MigrationView to test/index.html to fix test
FREEBIE
* Remove 'Submit Debug Log' button when the export process is complete
FREEBIE
* Create a 'Signal Export' directory below user-chosen dir
This cleans things up a bit so we don't litter the user's target
directory with lots of stuff.
FREEBIE
* Clarify MessageReceiver.drain() method comments
FREEBIE
* A couple updates for clarity - event names, else handling
Also the removal of wait(), which wasn't used anywhere.
FREEBIE
* A number of wording updates for the export flow
FREEBIE
* Export complete: put dir on its own line, make text selectable
FREEBIE
There's really no reason to retry encryption errors again if they've
already been made user-visible in a conversation.
Also, refactor e->error in background.js onError(), since both e and ev
in this method made it too easy to make a mistake.
These were failing because ByteBuffers from the protobufs need to be converted
to ArrayBuffers. Fixed by useing the existing handler in MessageReceiver to
process verified messages from contact sync messages and dispatch them as their
own events, reducing some complexity on the application side.
// FREEBIE
In some cases, due to promise chaining and error propagation, we were
calling registerError more than once for a given error. This would then
cause the overall callback for the send operation to be called with a
partial set of errors, as well as duplicates.
Note: we do need to find a way to attach identityKey to the
OutgoingIdentityKeyError in the case where it comes directly from the
encrypt() instead of our pre-key operations.
FREEBIE
First construct a null message of random size and contents and send it to the
destination. Then include that same padding in the verification sync.
Note that the sync message is additionally randomly padded like all other sync
messages.
This lets Verified sync messages appear the same as normal sync message traffic.
// FREEBIE
Just log em for debugging. Also update the error messge thrown when we get a
content message with no supported properties. It may be empty or may just have
an unrecognized field.
// FREEBIE
This adds a new method to message sender for sending verification sync messages
and a new event to message receiver representing incoming verification sync
messages. Currently the event handler just logs the message.
// FREEBIE
saveIdentityWithAtttributes allows directly setting all properties of an
identity key record. In AccountManager we use it to save our own identity
key after a new registration.
Previously we would remove the existing key first in order to coerce firstUse to
true, but now we can simply set it explicitly, along with a VERIFIED status.
// FREEBIE
Previously we only expected these errors to occur when decrypting prekey
messages, so we need to add handling for them in the case of a normal message.
// FREEBIE
Multiple cases here:
1. setting our own key on registration
1. changing identities from a safety number change dialog
Note that removeIdentityKey runs before saveIdentity, so we'll always end up
with firstUse: true on our own key.
// FREEBIE
We can use the same padded plaintext across multiple numbers or attempts rather
than re-creating it every time we encrypt to a particular number.
// FREEBIE
This test is out of date with respect to the latest signed key rotation rules
implemented in b92dd45 and 536dd7b. Previously we would only keep the last two
signed keys, but now we keep at least three as well as requiring a minimum
retention period. As a result, this test should be failing, but we haven't
noticed because it's not using the `done` parameter to signal its asynchronous
nature.
// FREEBIE
This was supposed to solve the problem of losing group state after a reinstall
by inspecting member registration ids and pre-emptively sending group updates to
those who appear newly re-registered, but it has been unused since 6123c419.
Nowadays there's a protocol for requesting lost group state from other members.
// FREEBIE
There may come a day when we may need to change this url from the server
side. On that day, clients should continue to operate normally. The
service should be able to change attachment server locations without
requiring a client update.
// FREEBIE
Previously, updateNumbers would throw an Error, so the whole group
update was discarded.
Signal-Android handles this the same way in
GroupMessageProcessor.handleGroupUpdate().
Closes#1056
Scott Nonnenberg
Lilia
haffenloher