- How long it takes to get a message through the pre-send checks
- How long it takes to open a conversation for the first time
- The timestamp of any message we send to corellate with other logs
- Add conversation ID to 'decrypt old identity key errors' start/end
FREEBIE
Turning off travis email notifications. Github does a fine job notifying
us about the things we care about, otherwise we can always go there and
see the results.
FREEBIE
- When loading a conversation, do check for old messages hidden due to a
not-yet-approved safety number and attempt to decrypt them
- When processing queued messages or retrying incoming messages,
maintain original received date
- Fixed an issue where the security checks before sending to a group
with an unknown contact could fail, blocking send
- Improve performance of security checks before send to groups
- We now disable the message composition text box when doing security
checks before send
FREEBIE
Because we do a number of async checks before allowing the real send to
begin, on a slow matchine or when doing a lot of work (like receiving a
lot of messages) there can be a noticeable delay between hitting Enter
and the clearing of the text in the message box. In fact, newly-typed
text can be added to the previous message if the delay is long enough.
This prevents any interaction with the message box until the send has
either been prevented or has started.
FREEBIE
Discovered a user log where expiring message checks were happening
constantly. This ensures that a very large timeout doesn't roll over
into immediate callbacks.
FREEBIE
isVerified and isUntrusted both went to the protocol layer, but were not
prepared for rejected promises resulting from missing records. This
prevented send in large groups where there has never been a message
exchanged with one of the members.
FREEBIE
Notable changes:
Application loading screen
- We now properly process read receipts, delivery receipts and other
types of sync messages before dismissing the screen.
Fix: Properly report decryption errors when they happen
Fix: Slow down expiring message processing, especially on startup (may
result in lower CPU/memory usage)
I believe this to be the reason behind some of the high resource usage
on startup. If a lot of read receipts come in for disappearing messages,
this method can be called many, many times very quickly.
FREEBIE
Notable changes:
Verified contacts
- Ability to verify a contact's safety number, same for group's
members via the 'Show members' screen
- Check mark next to verified contacts, and next to
100%-verified groups
- Synchronization of verification decisions across devices
- Banner and confirmation on send when previously-verified safety
number changes
- Confirmation on send if safety number has changed very recently
- Updated message detail screen when a message fails due to a safety
number change
Delete individual message from message detail screen
Clearer error text when a message to a group partially fails
Icons for in-conversation timer change and key change notifications
We now drop duplicate messages when we receive them
A number of reliability fixes:
- New 'unprocessed' cache for messages not yet fully processed,
attempted re-process on startup
- Protections against 'wedged' conversations, which won't receive or
send messages until restart
- Better resilience to errors throughout the codebase
Application loading screen until server backlog is fully processed
- Shows messages processed so far
- Prevents large numbers of notifications from firing on application
startup
Conversation loading screen
Unloading of conversations and old messages due to inactivity to reduce
memory usage
Potential fix for "Too many message keys for chain" (caused after
desktop is offline for long time)
FREEBIE
