This change should have no user impact because it only changes
comments.
We had some comments that referenced the Signal server repo. They
referenced a commit that was a little out of date (from March 2022).
This updates the links.
This removes `FeatureFlags.giftBadgeReceiving` and
`FeatureFlags.giftBadgeSending`, replacing them with
`RemoteConfig.canReceiveGiftBadges` and
`RemoteConfig.canSendGiftBadges`.
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.
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).
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.
This only calls the block, and the formatting in the old design made it
particularly difficult to read. (It also makes this path and the success
path more similar in their construction.)
_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.
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.
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)
Following a profile update, we need to reupload the avatar. Currently
we're uploading the avatar by writing it to a temporary file and kicking
off an NSURLSessionUploadTask.
If Class A keys aren't available, we'd fail to complete the upload. This
would remove the user's avatar from their profile.
Matthew previously stripped this down in our fork of AFNetworking; at
this point there's no benefit to it living in a separate repo and
separate target.
