I'm not sure how this is happening, but this will prevent the crash and
give us additional diagnostic data in the cases where it is happening.
// FREEBIE
* Auto-add new contact threads to profile whitelist when local user sends first message to that thread.
* Ensure dynamic interactions have a non-negative timestamp even if the conversation was empty.
* Only call updateMessageMappingRangeOptions _after_ beginLongLivedReadTransaction and updating messageMappings.
* Improve documentation around how to avoid corrupt mappings in conversation view.
* Fix edge cases around large initial range sizes.
* Always treat dynamic interactions as read.
* Rebuild the “unseen” database views to remove dynamic interactions (see above).
// FREEBIE
* Auto-add new contact threads to profile whitelist when local user sends first message to that thread.
* Ensure dynamic interactions have a non-negative timestamp even if the conversation was empty.
* Only call updateMessageMappingRangeOptions _after_ beginLongLivedReadTransaction and updating messageMappings.
* Improve documentation around how to avoid corrupt mappings in conversation view.
* Fix edge cases around large initial range sizes.
* Always treat dynamic interactions as read.
* Rebuild the “unseen” database views to remove dynamic interactions (see above).
// FREEBIE
Crypto Scheme:
- Name (un)padding
- WIP AES-GCM (funtioning, but need to verify against android
implementation, and tag functionality)
Changes to avatar API:
- hard code avatar domain (cdn.signal.org)
- avatar form hands out new avatar key, invalidating old avatar
- preliminary aes-gcm integration
Also:
- New type to represent AES128 keys, rather than passing around opaque
data blobs everywhere, we can use the compiler to help us make sure
we're passing compliant keying material.
- Started using factory pattern for API requests. This is intended to be
a lighter weight way to implement new API requests, rather than the
current 1-method class ceremony.
// FREEBIE
Without this, when the user has a large message queue to process, things
slow to a crawl as we spew more and more threads. Since it's on a serial
queue anyway, there's no need to have multiple threads executing this
code.
// FREEBIE
