* Go to chat list view after registration
* sync system contacts during registration
* Use explicit local credentials for storage service operations during registration
* fix tests
* Quick hack to get through double pin confirmation
* Finishing touches
* lint
* fix build
* reload phone number discoverability after storage service sync
* fix tests again
* Take chat auth on account and contact record initializers
* Change around branches for clarity in OWSUserProfile
* pr comments
* Split ChatServiceAuth into the same and AuthedAccount
* fix tests
* merge woes
RATE LIMITS & IS CRITICAL PRIORITY
Before this change, there was a notion of “critical” discovery tasks
that had their own rate limit, and that rate limit was used for
UUIDBackfillTask. In this change, that logic has been generalized to
consider a separate rate limit for additional request types.
QUEUE PRIORITIES
All of the discovery operations were updated to use `.userInitiated` as
their priority. Before this change, the `UUIDBackfillTask` and message
sending flow used lower priorities. However, both of those should use
higher priorities -- the former blocks receiving messages and the latter
blocks outgoing messages. This change allows the code to be simplified.
TESTS
This removes most of the existing `UUIDBackfillTaskTest` test cases
(they were commented out) and all of the `ContactDiscoveryTaskTest` test
cases (which were for the rate limiter, which has been moved elsewhere).
It introduces a few new tests. These aren’t meant to be exhausive;
instead, they’re meant to hit most of the code in the new classes and a
few specific edge cases that aren’t likely to be hit in normal use.
Currently, only some `JobQueue` types are initialized during startup
(as part of `Environment`, or `SSKEnvironment`). Initialization is
required, however, for a `JobQueue` type to restart any latent jobs.
That means that, for example, a durable `SendGiftBadge` job that failed,
and should be reattempted at a later date, will not in fact be restarted
since no `SendGiftBadgeJobQueue` will be initialized at launch.
This change adds `SSKJobQueues` and `SignalMessagingJobQueues` types,
which are intended to be singletons that hold within them a singleton
job queue for each of our `JobQueue` types. These wrappers are added to
`SSKEnvironment` and `Environment` (from SignalMessaging) respectively,
ensuring that all the `JobQueue`s they contain are initialized as part
of environment setup. The wrappers also avoid the need to add a new
property to the (already large) environment types for each new future
`JobQueue`.
This change also updates all existing call sites that accessed a
`JobQueue` from an environment object, to direct that access now through
the wrapper type.
This change may improve performance slightly but should have no other
user impact.
`myString.isEmpty` is faster than `myString.count == 0` or equivalent,
because computing `count` may require iterating over the string.
I tried to fix all occurrences of this.
Tested this by sending a message in a group and doing a full
re-registration, just in case I broke something there.
If we’ve recently discovered that a phone number can’t be discovered,
there isn’t much benefit to checking again.
However, for other parts of the migration flow, we still want to
consider such users. For example, sometimes we want to require all users
to have a UUID to perform a migration. Before this change, we might
return a false positive after performing a CDS lookup since we wouldn’t
check whether or not recently undiscoverable users have a UUID.
In another case, we’re intentionally excluding users without UUIDs. In
this case, the end result is the same whether we drop them during the
first pass or the second pass, but the intent is more clear if we drop
all such users during the second pass.
Lastly, we want to fetch profiles even for undiscoverable users, even
though this operation is likely to fail.
Change license to AGPL
This commit:
- Updates the `LICENSE` file
- Start every file with something like:
// Copyright YEAR_FIRST_PUBLISHED Signal Messenger, LLC
// SPDX-License-Identifier: AGPL-3.0-only
---
First, I removed existing license headers with this Ruby 3.1.2 script:
require 'set'
EXTENSIONS_TO_CHECK = Set['.h', '.hpp', '.cpp', '.m', '.mm', '.pch', '.swift']
same = 0
different = 0
all_files = `git ls-files`.lines.map { |line| line.strip }
all_files.each do |relative_path|
if relative_path == 'Pods'
next
end
unless EXTENSIONS_TO_CHECK.include? File.extname(relative_path)
next
end
path = File.expand_path(relative_path)
contents = File.read(path)
new_contents = contents.sub(/\/\/\n\/\/ Copyright .*\n\/\/\n\n/, '')
if contents == new_contents
same += 1
else
different += 1
end
File.write(path, new_contents)
end
puts "updated #{different} file(s), left #{same} untouched"
I'm sure this script could be improved, but it worked well enough.
Then, I created `Scripts/lint/lint-license-headers` and ran it to auto-
fix a lot of files. This changed the mode of some files, but I think
that's actually desirable. For example,
`SignalServiceKit/src/Util/AppContext.m` previously had a mode of
`0755/-rwxr-xr-x`, and it's now `0644/-rw-r--r--`.
Then I fixed some stragglers and updated the precommit script.
See [a similar change in the Desktop app][0].
[0]: 8bfaf598af
The `attemptToMigrateByCreatingOnService` method has a single caller,
and that caller also calls `tryToPrepareMembersForMigration` first. The
former is called when `migrationMode`’s `canMigrateToService` is true,
and the latter does a CDS lookup & profile key fetches if
`migrationMode`’s `isOnlyUpdatingIfAlreadyMigrated` is false; these two
conditions are true in the same situations. As a result, these CDS
lookups and profile key fetches aren’t necessary.
(This also removes an extra `firstly` block. I’d recommend ignoring
whitespace while reviewing the change.)
* 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
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).
* 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.
