processVerifiedMessage checks the current state of the database against the
identity key from an incoming verification sync message to determine whether or
how to update our local record.
When syncing a DEFAULT status and we have no local record, it's a no-op, but
we'll log it.
When syncing a DEFAULT status and we have non-default record with the same key,
mark it as default.
When syncing a VERIFIED status and either:
1. we have no key on record,
2. we have have a different key on record, or
3. we have the same key on record, but not verified
mark it as verified.
Otherwise do nothing.
References: https://github.com/WhisperSystems/Signal-Android/blob/master/src/org/thoughtcrime/securesms/util/IdentityUtil.java#L129
// FREEBIE
Ensure processVerified resolves
The shield matches the Android app's key change notification, and the
clock icon was easy to do and makes it easier to visually distinguish
those items in the conversation history.
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
We also show more errors than we used to in the MessageDetail screen
to help make it clear what is happening, and why the user would need to
re-send.
FREEBIE
It doesn't run today - it depends on RecipientsInputView, which depends
on Backbone.TypeaheadCollection which doesn't currently exist in the
product.
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
Reduce ambiguity in between the record itself, which now stores other
information besides the public key, and its `publicKey` attribute, which
contains an ArrayBuffer of key material.
This model is internal to SignalProtocolStore.
// FREEBIE
Previously we would only clear the publicKey since that was the only attribute,
but now we should delete the entire record. This method is currently only called
from tests.
// 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
This will enforce that all identity record attributes are valid and present
before allowing the record to be saved. This is necessary since we will be
exposing a lower-level method to save an identity with explicit values for
firstUse, nonblockingApproval, and verified status.
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
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 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
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
Because we only attach AttachmentViews to the DOM when they fire their
'update' event, we were subject to a race condition. If that event fired
after the final Message.render(), then it would be properly attached to
the final DOM node. If it fired early, it would end up missing from
the visible DOM entirely, attached to the old, discarded version of
the message.
This change updates our handling of a second call to loadAttachments().
Instead of bailing out if we've been called before, we attempt to
re-add our child AttachmentViews to the current DOM. But only if the
'update' event has been fired, and if their current parent node is not
what is in the DOM.
FREEBIE
To handle the same 'not quite at the bottom' case that our 30px buffer
gives us for marking messages read, we use the same atBottom() method to
determine whether we should mark everything unread. Saves the effort and
potential missed messages (due to partial pixels, etc.).
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
- initialize doesn't need to call update because
MessageView.renderExpiring() calls it immediately
- we don't need the className because that's already present on
the el it attaches to, part of the MessageView's template.
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
It can be moved if you're not scrolled to the bottom of of the window
or the window doesn't have focus when a new message comes in. Other than
that, it marches up the window until you close and reopen the
conversation, or send a message.
Note that we do NOT mark messages as read if they come in when you are
scrolled up. But we do mark the entire conversation as read if you
switch away from the app and back.
FREEBIE
Re-renders happen when we re-fetch messages from the database, and our
previous technique for loading attachments resulted in a new attachment
view added for every call to render()
This change ensures that a second call to render() does not add any more
attachment views.
FREEBIE
Scott Nonnenberg
lilia
Ikarulus