* 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
When we send the nth message, we retain the footer for the n-1th message
until the nth message is successfully sent.
1. leave the footer on the n-1th message
2. draw the nth message with the "..." footer
3. update the nth message with the "sent" footer and hide the footer for
the n-1th message
In the normal case this all happens very quickly, which results in some
unpleasant flicker every time you send a message.
The concession here is that we'll only print the n-1th footer if the
outgoing message *fails*. So until we implement a design more like
Android's double-check for sent/delivery, the user will not be able to
distinguish between a sent and delivered message *while* their message
is outgoing.
In my opinion the lack of jank in the normal case makes the app
supercedes this use case.
// 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
For ease of CDN cache expiry, each new avatar will have a unique URL, so
no need for a separate digest. Contents of file at URL will be verified
by forthcoming crypto scheme.
// FREEBIE
