Fix too-aggressive verification notifications on startup by starting a
conversation with the right initial verified state, and then making sure
to fetch() before setting a new verified state.
FREEBIE
New experience in the Message Detail view when outgoing identity key
errors happen, matching the Android View.
'View' button is only shown on outgoing key errors right now.
When a contact with an outgoing identity key error is clicked, they are
taken to a view like the popup that comes up on Android: an explanation
of what happened and three options: 'Show Safety Number', 'Send Anyway',
and 'Cancel'
Contacts are now sorted alphabetically, with the set of contacts with
errors coming before the rest.
FREEBIE
If the key has changed, saveIdentity will archive sibling sessions, but not the
session for the device it was called on. Therefore we have to archive that one
by hand.
Also switch from saving the identity of an OutgoingIdentityKeyError to just
triggering a profile fetch, mostly for consistency, simplicity, and DRYness.
// FREEBIE
Sessions established with the previous identity should no longer be used for
sending, so we should close them.
Since we've added this call to saveIdentity, we can omit the call to it after
profile fetches.
// FREEBIE
Not yet using the new APIs, but ready to. Still to do:
- Send sync messages on trust decisions
- Respond to received trust decision sync messages
- Show trust decisions in the conversation history
- In that rare situation where a sent message ends up with a key error
make it easy to retry the send.
FREEBIE
Also:
- All the necessary wire-up to update things in real time. If you have
a safety number page up via a group member view as well as via a 1:1
conversation with that contact, they'll both be updated as the
underlying model changes. Similarly, the overall group will update
in real-time as members change.
- A bit of special-casing for yourself in a group conversation - you're
shown as 'me' and are not clickable, where normally that would take you
to the Safety Number screen for that contact. You are also not included
in the trust calculations for a given group.
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
saveIdentity is now reponsible for determining firstUse, so we must not remove
the existing key before updating it.
Previously, the implementation provided an extra check against overwritting an
existing key, but that should be done via isTrustedIdentity instead.
// FREEBIE
We will now always attempt to mark things unread if this method. If the
conversation's unreadCount gets out of date, set to zero, we will still
do it. If we go through the motions, and nothing is newly marked read,
we will still set the unreadCount to zero.
We queue the job because we often get a whole lot of read receipts at
once, and their markRead calls could very easily overlap given the async
pull from DB.
We also disable read receipts for any message marked read due to a read
receipt. That's a notification explosion we don't need.
FREEBIE
We mark as read everything older than this message - to clean up old
stuff still marked unread in the database. If the user generally doesn't
read in the desktop app, so the desktop app only gets read receipts, we
can very easily end up with messages never marked as read (our previous
early read receipt handling, read receipts never sent because app was
offline).
FREEBIE
This is no longer guaranteed to be true. If you're scrolled up in a
conversation, you may not have read all messages. Setting the
unreadCount to zero will prevent the user from marking any of their
existing messages as unread until something else happens, like receiving
a read receipt or new message.
FREEBIE
- Only mark messages read when scrolling if in focus and visible
- Remove last seen indicator when scrolling to the bottom with scroll
down button
- Update last seen indicator when we don't already have one and we're
scrolled up.
FREEBIE
Bind a single listener to keychange events from the storage interface,
which then looks up relevant conversations and adds notices to them,
with tests.
Previously we would need to instantiate a conversation model in order to
start listening to its key change events. In practice this usually
happens at startup but we shouldn't rely on it, and it incurs higher
overhead since it creates a different listener for each conversation.
// FREEBIE
