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.
Updates the proto definition to add a preview description and date
field. Date and description metadata from fetched content will be sent
over the wire. We can't render it locally yet, but at least this will
allow supporting recipients to display the content.
Also, made some minor changes to HTMLMetadata to better handle article
publish/modified date tags.
Also, re-run protobuf generation with swift-protobuf-1.8.0 to reduce a
bunch of diff noise. If we decide to migrate, we should do that in a
separate commit.
After some discussion, it was determined that we'd need to keep this
around to ensure that we'll eventually resolve any unknown fields.
Leaving around an unregistered flag will permanently leave us with an
unknown proto field.
This change:
- Disables link previews on upgrade
- Introduces a new megaphone to prompt users to re-enable link previews
- Updates sync message proto to add a v2 link previews flag
Added a new field destinationDeviceId to the protocol buffer for
CallMessage.
Added supporting logic of setting it when sending.
Added a catch when receiving: If the field is defined, then use it
and check the local deviceId and if not a match, drop the message
since it is not for this device.
Changed naming to be more explicit.
Removed the FeatureLevel definition from the protocol since proto enums
won't be backwards compatible if updated. Instead, adding boolean flags
instead. For this release, the feature supported is multi-ring, so a
multiRing flag is defined instead of a feature level.
The supportsMultiRing value is persisted through to RingRTC. There is
no more need to translate between the enumerations anymore.
Added prefix naming for proto enums since the namespace is shared.
Removed defaults since they are already the desired default values.
When sending messages, using a nullable unsigned integer type instead
of a flag and value pair. This simplifies the function calls, although
some NSNumber extensions were required on the Swift side.
Add type for Hangup messages, to reflect either normal hangup or hangup
because the call was accepted elsewhere.
Add type to Offer messages, which is used to indicate the type of call
that is being originated, either an audio call (the same as all legacy
calls) or a video call.
Add level for all messages, which is used to filter feature support,
either legacy or multi-ring behavior.
If the feature level for the Call Message is detected as legacy, AND if
the device is NOT the primary, drop the incoming Call Message.
Always mark outgoing Call Messages as multi-ring capable.
Adjust RingRTC interfaces to support:
- Call Media Type (default is always audioCall for now)
- The Hangup Type, which can be either normal (i.e. regular hangup) or
accepted, replacing the removed Accepted message.
Hangups can now be sent out as a legacy messages or new messages. The
format is the same so that legacy clients will ignore 'new' hangups
sent to squelch ringing if they were actually the 'winner'.
Passing information for receivedOffer and receivedAnswer APIs to
indicate if the sender is a legacy sender or not. Legacy here means
someone using the protocol before the FeatureLevel was added to the
prototol for Call Messages.
Passing information to receivedOffer to indicate if the local device
is primary or not. As a result, if the device is receiving the offer
from a legacy device and is non-primary, the offer shall be ignored.
In this case, a new event is fired:
endedIgnoreCallsFromNonMultiringCallers
Co-authored-by: Michael Kirk <michael@signal.org>
