When someone sends a message to your PNI, your responses (from your
ACI) must include a PNI signature, and the sealed sender certificate
you use during this period should include your phone number. This
confirms to the other user that your ACI is associated with your PNI.
This commit adds the state tracking that and ensures that both
TSOutgoingMessage and OWSUDManager check that state when building 1:1
messages and choosing certificates, respectively. Later commits will
set and clear this flag as needed.
This communicates the PNI identity key to existing linked devices,
which is important for linked devices to initially learn about a PNI,
or for the change of identity that comes with changing your number
(and therefore your PNI). The exact contents of this message will
probably change going forward, but here's a baseline to work off of.
We're very close to being able to decrypt messages sent to our PNI,
but *until* that point it's best to just drop any such messages. This
should make testing easier.
If there are several group changes being returned at once,
deserializing all of them up front can lead to excessive memory use,
especially for very large groups. This commit switches to
deserializing each change as it is used, which doubles the amount of
CPU work (because we loop through the changes twice) in exchange for
only ever having one Change object graph in memory at a time. It does
also mean we can get a protobuf deserialization error a bit later in
the process if the data is ever corrupted, but that shouldn't cause
additional issues at these particular call sites.
RingRTC will now vend the urgency of an incoming opaque call message. We
can use this to determine whether or not we want the NSE to wake the
main app.
- Fetch mp4s from Giphy for showing previews
- Fetch mp4s from Giphy for sending (behind featuree flag)
- A new flag on attachments to tag a video as "looping media"
- Videos tagged with this flag will be shown on repeat
Doing this correctly means going "back" to proto2 for SessionRecords,
because we need to distinguish between "0" and "absent" in the
serialized protobuf data. (Note that we can do this independently of
SignalClient properly making this distinction because the proto3
implementation we're using, prost, will omit scalar proto3 fields
whose values match their defaults.)
By including eraId in GroupCallUpdate messages, we're able to identify
separate group calls after the fact. Each unique eraId will result in a
new entry in the database, even if the group call has since ended.
