This change should have no user impact.
This commit:
- Rewrites the tests in Swift
- Removes some redundant tests
- For North American phone numbers, uses `555-01XX` phone numbers
(because "only 555-0100 through 555-0199 are now specifically reserved
for fictional use; the other numbers have been reserved for actual
assignment)
* 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
This updates our libPhoneNumber dependency. See [the libPhoneNumber-iOS
commit][0].
According to [the upstream libphonenumber release notes][1], they
updated the formatting for +49 numbers. That caused a test to break, so
I updated it (and tested a few additional dialing codes).
[0]: 8b6f552682
[1]: 90503ecef3/release_notes.txt (L21)
I added these tests in da322d3bf9, but we
decided that they're not worth it.
Also, it seems I forgot to add them to the project! So they were never
run anyway, outside of the times I ran them while developing.
* Improve phone number parsing.
Previously, if you entered a phone number
including a country code during registration you'd
have a duplicate country code. Signal on Android
did not have this bug because it uses a different
API inlibphonenumber. This diff changes iPhone to
use the same API, which is smart enough to remove
the country code from the phone number the user
entered if needed.
Co-authored-by: Evan Hahn <evanhahn@signal.org>
Make `encodeE164s` a static method since it doesn’t need to access any
details from the operation instance.
Also move the test to SignalServiceKitTests.
To improve message reliability, we're adding an urgency flag to outgoing
messages. For example, outgoing calls are urgent, but delivery receipts
are not. [Android][] and [Desktop][] have already done this work.
At a high level, I added an `isUrgent` property to `TSOutgoingMessage`s.
It defaults to `true`. Some subclasses, like
`OWSReceiptsForSenderMessage`, override it to return `false`.
Builds off of a few other commits (not necessary to understand this
commit, but might be useful for posterity):
- e858a0d916
- 8c6d2ebe8c
- 402b117221
- 2ba0cd764d
- 266a4663e9
- 8e5009bbf7
[Android]: dc04c8ed98
[Desktop]: 06190b1434
When you compose reply to a message but do not
send it, we would persist the text you entered but
would lose the quoted message to which you were
replying.
This commit adds support for persisting that
information.
ThreadReplyInfo is a new class that uses the
key-value store to associate a single optional
reference to a message with each thread.
The following behaviors are nw:
* When you enter the CVC the input toolbar is
updated to have the quoted message.
* When you exit the CVC the quoted message is
saved.
* When a thread is deleted, the quoted message is
deleted.
This change should have no direct user impact.
`OWSOutgoingReactionMessage` was untested. This adds a basic test for
its `shouldBeSaved` method.
I think this is a useful change on its own, but may make future changes
easier, too.
SignalServiceKit is currently a separate pod. This makes merges tedious
and error-prone. Ultimately, it slows us down. It might've made sense as
a standalone library before, but it's so tightly integrated now that it
isn't useful to have it be separate.
This changes that, and makes SignalServiceKit a "normal" target.
IMO, most of this change isn't that exciting—just a bunch of changes to
scaffolding. There's one slightly spicier change: our generated
`Acknowledgements.plist` is now a little more clever.
Co-authored-by: Max Radermacher <max@signal.org>
Group snapshots fetched from the service do not store the
`didJoinFromInviteLink` field on their members, and when we parse a
snapshot into a group model we hardcode this value to `false` for all
members. However, we store that field locally on a `GroupMembership`'s
`MemberStateMap` when processing an "add members" change action, as the
field is provided in the `AddMember` change action proto.
This becomes an issue, since when we refresh the group's state from the
service (which we do periodically, e.g. when opening a group for the
first time after launch) the `GroupMembership` from the group's snapshot
on the service will not match the `GroupMembership` we have locally,
even though they are from the same revision, due to mismatched
`didJoinFromInviteLink` values (hardcoded in the snapshot).
Consequently, we believed we were "updating the group model in a user-
facing way", but the only change therein was clobbering a
`didJoinFromInviteLink: true` to `...: false`, which was 1) wrong and
2) did not have a description to show.
This commit changes `GroupMembership` to ignore values for
`didJoinFromInviteLink` when comparing equality. This means that when we
parse a snapshot into a `TSGroupModel` with all those values hardcoded
to false, but otherwise identical to our local, we will no longer see it
as different from our local (and subsequently clobber our local and
generate an empty update).
This change should have no direct user impact.
This tests `TypingIndicatorMessage`'s `isOnline` getter.
I plan to add additional tests to this file in a future commit, but I
think this is a useful change on its own.
Some users [are unable to register][1] because the server [returns a 400
error][2] if passed an invalid `Accept-Language` header.
This commit helps prevent two possible error modes:
- Filters out invalid language tags. Some users reported a "Workshopx"
language, which the server would reject because it's syntactically
invalid. Deleting this language (at the OS level) let them register.
- If no languages are valid, we should send `*` instead of the empty
string. There's no evidence that this happened in practice.
In addition, this commit:
- Adds tests.
- Sends a maximum of 10 languages instead of 6.
- Omits the `q` value when it's 1 because [that's the default][3].
- Marginally improves performance by iterating lazily.
[1]: https://github.com/signalapp/Signal-iOS/issues/5261
[2]: bf6d3aa324/service/src/main/java/org/whispersystems/textsecuregcm/controllers/AccountController.java (L271-L275)
[3]: https://www.rfc-editor.org/rfc/rfc9110.html#section-12.4.2
Co-authored-by: Nora Trapp <nora@signal.org>
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.
