* Add OnboardingStoryManager
* mark onboarding story viewed
* Add tests and fix issues that came up from testing
* up test timeout for slower CI
* rename SystemStoryManager and put into dependency injecton container
* Use viewed state on StoryMessage itself. Have SystemStoryManager observe app lifecyle events to automatically manage the onboarding story
* use iOS assets which are now in s3
* todo cleanup
* increment timestamp for uniqueness
* pr comments
* change literal delimiter
* Add ChainedPromise utility, tests, and use in SystemStoryManager
* discretionarily observe app backgrounding in SystemStoryManager
* renaming from PR comments
As of 86b8eb08b8, the database initialization no longer has
asychronous components. The current code returns an already-resolved
promise in all situations, so remove the asynchronous infra entirely.
* Split OWSSignalService into a swift protocol and implementation, migrated from objc
* Put OWSSignalService under SSKEnvironment and use mock in mock environment
* Rename from basename + impl to protocol + basename
* extend mock functionality a bit
* pr feedback
* Start muted, unmute when pressing volume buttons
* move ringer switch observation into its own class
* observe ringer switch in stories
* add foreground time to AppContext; use to drive mute foregrounding behavior
* dont double observe
* mix story volume with others, show volume controls
* 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
This respects the `giftBadges` capability when trying to send gift
badges. In other words, it prevents you from sending gift badges to
someone who lacks the capability.
The bulk of this change involves fetching and saving of this new
capability. The rest of the code involves showing it on the "choose
recipient" screen (and some debug screens).
The purpose of this change is to alleviate the
main source of CPU-grinding after sending a
message to a large group: about 20% of the total
time is spent decoding and re-encoding messages as
they are fetched from the DB and then updated with
info about which recipients have acknowledged
delivery.
Prior to this commit, we decrypted the payload and
then processed the message in a single rather deep
call tree that began in `processNextBatch`. There
are two completely different paths through this
tree that lead to handling a delivery receipt
because server-generated delivery receipts have
the necessary info in plaintext in the envelope
and client-generated delivery receipts have it in
the ciphertext.
The idea here is to break incoming envelope
handling into two parts.
In the first part, each envelope is decrypted and
other common activities (like handling sender key
distribution messages) are performed. A processing
request is created for each. Next, processing
requests are handled. It's easy to examine a
processing request to determine if it is a
delivery receipt, and if so, for what outgoing
message. Doing so allows the new
DeliveryReceiptContext class to cache message
fetches and combine updates to the same message.
Processing requests are grouped together so that
sequential delivery receipt requests enjoy caching
of messages and coalescing of updates into a
single fetch/decode/encode/commit. Other kinds of
envelopes are handled immediately to avoid
increasing memory pressure that caching multiple
messages could cause.
The normal reachability manager would never get configured during
testing because it waited for AppReadiness. However, it still created
an OWSURLSession, and if between tests the previous reachability
manager wasn't destroyed fast enough, trying to set up a new one would
create a second URL session with the same background identifier, which
isn't allowed.
Fix this by providing a MockSSKReachabilityManager, which is never
reachable by default, and while here update the background identifier
to be something descriptive.
We expose many of these builders to Objective-C, but Swift is unable
to map forward-declarations of those types (@class) back to the real
Swift classes because they're nested within the protos. Since we're
already using fully-qualified names even in Swift (e.g.
"SSKProtoContentBuilder"), nesting isn't worth the trouble it's
causing.
Sealed sender certificates come in two flavors: one with our local
phone number, and one without. Add an automated test for picking the
right one based on our phone number sharing mode (everybody,
contacts-only, nobody).
This commit also adds a convenience helper for tests that want to wait
on promises that might run on the main thread.
This removes calls to `arc4random` and `arc4random_uniform` and replaces
them with calls to `Int.random` or equivalent.
These are a little less readable, which may be [why SwiftLint doesn't
like them][0]. (SwiftLint calls them "legacy", possibly because they're
not strong random number generators, but I couldn't find a clear
explanation for this anywhere, including [the original PR][1].)
This is the kind of change that's error-prone, so I wrote [a simple
script to help avoid regressions][2]. The script runs 10,000 iterations
of the old and new RNG and compares the ranges, reporting differences.
(Some differences are likely, like the ones that involve floats; others
are very unlikely to have differences.)
`git grep arc4random | grep swift` returns no results after this change.
Same for [everything else SwiftLint checks for][3].
[0]: https://realm.github.io/SwiftLint/legacy_random.html
[1]: https://github.com/realm/SwiftLint/pull/2419
[2]: https://gist.github.com/EvanHahn-Signal/9c75c9f484f4778149cbde3eafc9b285
[3]: ea6cc50890/Source/SwiftLintFramework/Rules/Idiomatic/LegacyRandomRule.swift (L23-L27)
*Most* of the identity store's duties are about the identity keys of
people you talk to, but it also provides the local identity key (and
registration ID), and the local identity key differs by PNI.
This design fetches the local identity key up front in preparation for
supporting Change Number flows better, where you may need to use a
past PNI identity key to decrypt a message. (That's just one possible
implementation strategy, though.)
Pre-keys are refreshed at regular (throttled) intervals, but the
"refresh" operation will only actually upload new pre-keys if the
server says we're running low. In addition, after the "refresh",
there's a "rotation" operation for the signed pre-key if the current
one is more than two days old. This only runs if the refresh was
skipped, since uploading new one-time pre-keys is already an
opportunity to rotate the signed pre-key (and it's worth doing so,
since pre-keys running low can indicate high traffic).
None of this has changed. However, we can now do this for both ACI and
PNI pre-keys. This reworked +[TSPreKeyManager
checkPreKeysWithShouldThrottle:] quite a bit to declare the proper
operation dependencies, which isn't *strictly* necessary because the
queue they're executed on is already limited to a
maxConcurrentOperationCount of 1. We could remove that at this point
with proper use of "barrier" operations, but since all the operations
are hitting the server and account updates have to be serialized on
*that* end, there doesn't seem to be much of a benefit.
At launch time, if a primary device doesn't have a PNI identity key,
it should generate one immediately, as well as pre-keys. If a linked
device doesn't have a PNI identity key, it messages the primary to ask
for one; when it gets a response it generates its own pre-keys.
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.
This doesn't handle
- device linking (we need to send the PNI identity key as well as the
ACI identity key)
- existing devices that need PNI keys (that'll be an explicit check)
This stacks on top of PR #4065.
This is a simple change that uses the existing
batch profile fetching to get user names.
It adds a test for OWSProfileManager.
This is the first meaty part of optimizing
fetching display names.
Some contacts fall back to phone numbers as their
display names. This PR fetches them in a single
SQL query via
`OWSContactsManager.phoneNumbers(for:, transaction)`.
To achieve this, this PR introduces
`GRDBSignalAccountFinder.signalAccounts(for:,transaction:)`
to fetch many accounts at once.
In order to fetch many accounts at once, we need
to be able to fetch many values from a
ModelReadCache at once. So this PR introduces
`ModelReadCache.readValues(for:,transaction:)` and
`ModelReadCache.getValues(for:,transaction:,returnNilOnCacheMiss:)`.
Existing methods that operate on a single value
were refactored to use the batch methods.
This PR adds tests for this functionality, which
necessitated changing the visibility of various
private symbols and also improving the fake
profile manager to make it more configurable.
There's also a tiny optimization for Refinery to
avoid calling a closure that has no work to do.
This helps elide do-nothing SQL queries that would
otherwise have been introduced.
'sessionStore', 'preKeyStore', and 'signedPreKeyStore' are no longer
directly accessible; you have to go through
'signalProtocolStore(for:)' instead. This commit mechanically changes
all use sites to use `signalProtocolStore(for: .aci)`, with the
understanding that they will need cleanup in the future.
This is not enough to actually support multiple stores; they still
store in the database under the same keys. That's coming in the next
commit.
Save the PNI after registration and when verifying or updating our
current phone number. (Also, show it in the Internal settings like the
phone number and ACI.)
This PR is the first in a series that will
optimize looking up full names of group members.
The biggest source of slowness when opening a
group chat is looking up the full names of group
members in the search for duplicates. It is slow
because it requires multiple db queries for each
member.
The characterstic feature of this algorithm is the
iterative process of assigning names to signal
addresses. For example, some contacts' names may
be cached. For others, their profiles must be
fetched. For those without profiles, their phone
numbers must be formatted (which requires fetching
SignalAccounts). For those without phone numbers,
their user names must be formatted.
This PR creates a class called Refinery. Its job
is to make it easy to assign values to keys
through multiple passes, where each pass may
succeed only for a subset of keys.
This is useful because we will eventually issue a
single DB query for some of these passes.
PR 2982 optimized
ConversationViewController.createGroupMembershipCollisionBannerIfNecessary`
that fetches user profiles off the main thread and
then, when that completes, uses them on the main
thread to find duplicate display names.
The optimization doesn't work for large groups.
Because `UserProfileReadCache` is backed by an
LRUCache with a maximum capacity of 32, there is
effectively no cache and profiles get fetched
twice.
The main purpose of this commit is to fix this
optimization for large groups without expanding
memory usage unnecessarily. While increasing the
LRU cache's size to 1000 (or some other arbitrary
value) would fix the problem very simply, my gut
tells me that we're going to keep running into
this problem.
Rather than pick an arbitrary "large enough"
value, this commit increases the cache size to be
just large enough for its intended purpose and to
keep it that size for just long enough to do its
job.
This commit introduces the concept of a "lease" on
a larger cache size. The cache's size is defined
as the largest of all its leases plus its
"regular" size (the size it was initialized with).
For now only the user profile cache uses it.
