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
A good bit of CSS was required to keep the text color changing along
with the text it is nestled within.
Also: took this opportunity to increase the contrast of the number and
verified section right under the contact name in the group members view.
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
