This change should have no user impact.
`TSInvalidIdentityKeyReceivingErrorMessage` had an unused method,
`theirSignalId`. This removes it.
`git grep -i theirSignalId` returns no results after this change.
I think this is a useful change on its own, but will also be useful in
an upcoming change.
_This change should have no user impact._ And you can see that the only
changes to generated files are in comments.
Before this change, we used comments to denote reserved or deprecated
fields. This works, but I think we should instead use the `reserved`
keyword, which offers a few advantages. From [the protobuf docs][0]:
> If you update a message type by entirely removing a field, or
> commenting it out, future users can reuse the field number when making
> their own updates to the type. This can cause severe issues if they
> later load old versions of the same .proto, including data corruption,
> privacy bugs, and so on. One way to make sure this doesn't happen is
> to specify that the field numbers (and/or names, which can also cause
> issues for JSON serialization) of your deleted fields are reserved.
> The protocol buffer compiler will complain if any future users try to
> use these field identifiers.
This updates our proto files to use `reserved` instead of comments. It
also adds support to our wrapper script. (I moved a few things around in
that script, too, for consistency.)
I think this is a useful change on its own, but I think it'll make
things a little better when we deprecate some fields, which we're
planning to do soon.
[0]: https://developers.google.com/protocol-buffers/docs/proto3#reserved
* Add first send story privacy field to AccountRecord proto
* Store hasSetMyStoriesPrivacyKey on StoryManager
* sync hasSetMyStoriesPrivacy state
* Reuse MyStorySettingsViewController in a sheet view controller
* Show my story privacy settings from conversation picker if unset when selecting my story destination
* reload my story row to change subtitle
* pr feedback
This can get called asynchronously during tests, and that can lead to
flakiness if we’re between two tests. There doesn’t seem to be a
compelling reason to only distinguish critical errors from warnings in
the NSE, so distinguish the two types everywhere.
_This change should have no user impact._
This flag had a condition that would always evaluate to `false`. This PR
fixes that, and adds a comment about why it's a little verbose.
_This change should have no user impact._
The database corruption flag lives on `UserDefaults`. Currently, this
flag is controlled through `SSKPreferences`, but I kinda think that's
the wrong place—database corruption isn't really a user preference.
This moves it into its own file, tests it, and [drops booleans in favor
of an enum][0]. I think this is useful on its own, but also prepares us
for an upcoming change.
[0]: https://www.luu.io/posts/dont-use-booleans
- Remove duplicate check for a `+` at the beginning of each value.
- Don’t return a big-endian UInt64 from a method. The type information
(unfortunately) doesn’t include endianness, which makes that approach
somewhat more error-prone.
- Add a type that tracks validated input/output pairs. Future changes
will want to perform the validation and then use both input & output.
If you've left a group, we shouldn't show it in any pickers except the
blocking manager (`AddToBlockListViewController`). Before this commit,
we were showing it in a few places. That might let you sorta-send a
message to a group you'd left.
I enumerated all the places where we have pickers, and what their
behavior should be.
| Description | Code | Show groups? | Show left groups? |
| --------------------------------------------------------------------- | ------------------------------------------- | ------------------------ | ------------------------ |
| Various group member pickers (adding members, group story recipients) | `BaseMemberViewController` | No | N/A |
| Send payment screen | `PaymentsSendRecipientViewController` | No | N/A |
| Gift badging “choose recipient” screen | `BadgeGiftingChooseRecipientViewController` | No | N/A |
| Composer | `ComposeViewController` | Yes, only when searching | No |
| Add to block list (in Settings → Privacy) | `AddToBlockListViewController` | Yes, only when searching | Yes, only when searching |
| Share sheet | `SharingThreadPickerViewController` | Yes | No |
| Message forwarding | `ForwardMessageViewController` | Yes | No |
| In-app camera | `CameraFirstCaptureSendFlow` | Yes | No |
| Share group link via Signal | `GroupLinkViewController` | Yes | No |
| Share sticker pack, from in a chat | `StickerPackViewController` | Yes | No |
| Share sticker pack, from sticker management screen | `ManageStickersViewController` | Yes | No |
| “New Group Story” screen | `NewGroupStoryViewController` | Yes (exclusively) | No |
This doesn't intend to change the behavior of *deleted* groups. Those
will show up when searching if groups are shown at all. For example, a
deleted group will show in the composer if you search for it just like
any other group. A deleted group will *not* show in the "send payment"
screen because groups are never shown there. Again, the behavior around
deleted groups should remain unchanged.
Co-authored-by: Max Radermacher <max@signal.org>
* initial approach commit, needs cleanup
* Keep >30s videos for non-story recipients, but split for stories
* Some cleanup
* fix too many chats toast offset
* show tooltip in the send flow
* pr feedback
