If you've got the `giftBadgeSending` flag enabled, you can now send gift
badges to anyone who has the capability.
This commit doesn't complete the feature, though. It is missing:
- Proper durability and error handling (to be addressed separately)
- Saving of receipts
- A few other cleanups
This makes a few small changes to `OWSRequestFactory.boostCreatePaymentIntent()`:
- Adds tests
- Rewrites the function in Swift
I made sure I could do a boost (in staging) in the simulator.
anyUpdate runs its closure twice with different
messages but the batching context applied updates
always to the same copy of the message.
Also apply lint fixes.
* 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
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.
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.
However, as soon as they have processed a PniSignature, there's no
need to keep wasting space in messages. Detect this using the
following conditions:
- You received a delivery receipt from them.
- The original message was sent via sealed sender (so the server
can't synthesize a delivery receipt).
- All their other devices have already sent delivery receipts for this
message.
- The original message actually had a PniSignature in it.
- The original message's PniSignature matches your current PNI
(relevant if you change your number and then get an incoming message
from the same person at your new PNI).
Additionally, reset phone number sharing for *everyone* when you
change your number; they've contacted you at your old PNI,
representing your old number, and even if you reply you can no longer
claim that PNI as yours.
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 adds the first screen for badge gifting. It lets you see the gift
badge, pick the currency, and advance to the next screen.
It also adds a skeleton for the next screen, so there's somewhere to
advance to, but that screen is unfinished.
All of this is behind disabled flags, so this should have no user
impact.
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.
SwiftLint [gets upset][0] when `XCTFail` doesn't have a message. We had
two tests that lacked these, so I added them.
Part of my ongoing quest to get to "SwiftLint zero".
[0]: https://realm.github.io/SwiftLint/xctfail_message.html
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)
_I recommend reviewing this with whitespace changes disabled._
Signal has renamed its primary branch to `main`. This updates references
to the old name, `master`, to either reference `main` or a specific
commit hash.
I also fixed a couple of small whitespace issues in a file I was
editing.
We can only *really* trust this once the certificate validates, and
even then the certificate could be out of date. So now the mapping is
only treated as high-trust when the inner messages decrypts
successfully too.
This test-only change adds tests for [`Subscription`][0].
I did this because I'll be adding additional behavior to this struct and
want to be ready to test that logic. I think this is a useful change on
its own, however, so I split it out into its own change.
[0]: 2693c55232/SignalMessaging/Subscriptions/SubscriptionManager.swift (L70-L104)
The class can be computed from `self`, and the lookup block is always
the same (essentially `self.value(forKey:)`), so there’s no need to
provide separate implementations for each subclass. The superclass can
provide a single implementation for all subclasses to share.
Messages always have an isGroupStoryReply of true or false (1 or 0),
but non-messages don't have this field, and GRDB treats that as NULL
rather than falling back to the table default.
notImplemented() ends up forwarding to fatalError() anyway, but before
it does so it flushes our logs. That's probably good to have. I think
most of these come from the default implementations Xcode provides for
you with a fix-it.
...so it can use an existing one when there is one, which in practice
there always is because we never refresh one-time pre-keys without
rotating our signed pre-key too.
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.
