* Little fix for context menu
* Add 'My Stories' section to stories tab
* Add new story thread types
* Show stories in conversation picker
* Support for sending stories
* Update story list when sending stories
* Add basic 'My Stories' view controller
* Initial stories settings screens
* Consolidate TSPrivateStoryThread and TSMyStoryThread into one class
* Require an explicit read transaction to initialize an outgoing message
* Fix linting
* Allow enabling group story from internal settings
* Fix tests
* PR Feedback
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.
There are some Swift-only features that are part of these protocols, so
they were split into Obj-C and Swift variants. However, the class itself
only reports conformance to the Swift variant, which leads to warnings
when using the class in Objective-C.
Requesters are able to request to join a group by using data in the URL.
In order to cancel their request they need to use that data again. This
data wasn't being plumbed through.
The scaffolding for this has been there for a long time, but the
server side has only just been hooked up. This should save a lot of
traffic when processing a long group backlog, or a backlog for a large
group.
The server will include this if the backlog of group updates *should*
have brought the group up to date, but the actual change action for
the latest revision is missing. This should never happen under normal
operation, but it's best to be defensive against data loss. (Or in
this case, new server features tested in upcoming commits.)
...instead of parsing them all from the server and *then* processing
them (85200228cf). This should keep from blowing out an arbitrary
amount of RAM in pathological cases.
Storage service won't serve more than a certain number of updates for
group logs at a time, returning 206 Partial Content if there are more
to process. Recursively process pages until we get a 200, then combine
all the parsed data into a single array for higher-level handling.
SignalClient used to support a non-standard version of HKDF as
"version 2" (numbered for an old version of the Signal protocol), and
the standard one as "version 3". Now only the standard version is
supported, so the parameter is unnecessary.
Without the GroupV2Params caches, processing multiple large group
updates is extremely wasteful, decrypting the same profile keys and
UUIDs over and over again. The size of these caches has also been
*increased* to match the group size limit, or else there's no benefit
for large groups.
Other LRUCache instances are still off by default in the NSE by virtue
of the "NSE max" defaulting to 0.
When Data is put into an NSCache it gets converted to an NSData, which
is a CFData underneath. CFData's hash function only looks at a prefix
of the data, and the secret params were taking up a good chunk of that
prefix, leading to hash collisions. By putting more variable data
first, we get better hashes *and* exit memcmp faster in the case of a
collision.
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.
