Is there a way we can try to make this actually match the style of the main "Sign in to Comm" modal? It frankly looks completely different, in terms of color scheme, navigation, organization, etc. I think we need to do some more work on the design here, but open to landing this diff to unblock Rohan for the time being

1. Let's find a way to avoid having the "Open the Comm app" part take two lines
2. I don't love how that line just "trails off" without a period or a colon or something
3. If we're bolding navigational elements, we should make sure we bold the whole navigational element. "devices" in "Linked devices" appears to not be bolded

It feels like this diff should be broken down into at least 3: changes to temporary file name, monitoring memory usage, and changes to support multiple contentHandlers. Can you break it down to make it easier to review? (Feel free to break it down into more than 3 if you prefer.)

One nit about deviceID vs deviceId, and one request to check message.type (agreeing with @marcin). My other two comments are responses to @marcin

You seem to have accidentally addressed my 2 comments from the previous review in D8752. Can you make sure you update this diff as well?

What's the point of this change? I'm not sure that this code is better than the original... it requires understanding _memoize, and the original code seemed clear enough.

Thanks for taking the time to improve the codebase, even though it doesn't pertain to your work exactly :)

Great find! Thanks for fixing this.

Confused how the second screenshot shows a Register (new) but NOT a Sign in (QR). Based on the code, shouldn't they show up in the exact same scenarios?

Thanks for explaining!

Nit

Not looking too closely

Not looking too closely, but it seems okay

We don't need native as an option here.

I got 15 lines into the file, and then gave up on the review due to frustration. You completely ignored a comment from my previous review.

@ginsu please use git blame and arc cover in the future when determining reviewers – it seems clear that @rohan is your best bet here

Let's avoid forcing each of the TextMessage, RobotextMessage, and MultimediaMessage components from rerendering on every render of Message. We should memoize the style object we pass in

Based on how viewProps appears to be forwarded, I think it would be possible to set viewStyle in Message, and pass it as a style prop to TextMessage, MultimediaMessage, and RobotextMessage. The former two would then forward it to ComposedMessage, and the style prop would end up being set in exactly the same places that it's being set in this diff today.

Where did we factor in failedSendHeight in the code before your changes?

The square box here doesn't look super on-brand for us... we usually have rounded corners, don't we?

Passing back with question. Feel free to push back, I haven't compared these dependencies too closely

Requesting changes for .pbxproj. Adding @jon to confirm CMakeLists.txt updates are correct

Shouldn't there be some change to the .pbxproj file for iOS? Are the new iOS files showing up in Xcode?

Have you considered https://github.com/rosskhanas/react-qr-code? I found it on reactnative.directory. It looks like it's not quite as popular as react-native-qrcode-sv, but it's almost as popular, plus it works on both React and React Native and seems to have been updated more recently.

There are no reviewers specified – is this one a draft too?

Can we go with qrCodeLoginButton like in my suggestion?

Thanks for fixing this!

Nit

We're now tracking the goal of making identity service aware of client codeVersion in ENG-4598

@marcin also clarified that Telegram's codebase appears to have the same beliefs as Signal's codebase. It seems increasingly likely now that our issue is the result of assumptions around concurrency that are likely to be untrue.

I am sketched out by the lack of synchronization here. @marcin said that Signal's codebase has some code that indicates that they don't trust notifs in the NSE to be processed sequentially. If that is true, it might explain the issues we've been seeing. It also breaks some assumptions that this code is based on.

Talked about this with @marcin – it should be possible to keep this flag in just one place that is accessible from iOS and Android

Context in ENG-4525, but basically after talking with @marcin we decided to try to fix the issue that this diff is trying to detect, rather than waiting for it to be detected.

Is it necessary to have two places that we need to change? Could the isStaffRelease function have been placed in a shared CPP file, so it only needs to be updated in one place for both iOS and Android?

Make sure you address the inline comment before landing

Is there a way we can land this to master? Today the "Temporary changes for staff release" commit only touches native/utils/staff-utils.js, but we could have it touch some CPP file so that both iOS / Android native code could know if the release is a staff release. We currently have a requirement where every person who is doing a release has to coordinate very closely with you to know exactly what commits need to go on keyserver, which ones need to go on native staff release, and which ones need to go on native public release. This is rather complex and it would be easier if you could land the diffs you put up to master

A couple nits inline

Does this package version work with the version of Expo that we're running? (Sometimes we have to use older versions)