Great!!

This diff led to ENG-7706 because preRequestUserState was not correctly stripped from calls to keyserver

I should probably also rename workerRequestMessageTypes.GET_CURRENT_USER_ID, workerRequestMessageTypes.SET_CURRENT_USER_ID, and any other related stuff

In D11638#335229, @marcin wrote:

Are we able to cache it, such that if the user goes back to before this screen, and then advances to this screen again, the SIWE flow does not need to be re-entered?

Thanks for pointing this out. I haven't thought about this earlier. Could you share some additional info about expected user experience in such case? For instance - if the user creates backup message, goes back to change the avatar should we then just skip create backup message screen or potentially display different UI?

Can you share an updated screenshot?

Hmm, you seem to have used a different icon than the one I requested. Can you update it to use the one I mentioned here?

It looks like this info is irrelevant, but just in case I wanted to share it: note that because of the nonce verification logic during login on the identity service, a signed ETH message for login is only valid for 120 seconds after the nonce was first delivered.

One more round, sorry for the churn

Screen with backup secrets generation screen before clicking Secure with Ethereum Wallet

In D11643#335050, @inka wrote:

Requesting review because now:

1. We can still see this modal more than once - for other keyservers. Is this that we want??
2. For the auth keyserver, the user is logged out. If they dismiss the modal, but ignore it and log in, they will be logged out and will NOT see the modal again. Is this ok or should I make logging in reset this state?

Discussed this in a meeting with @inka and @tomek. We identified the following next steps, now that @tomek's work has been landed:

Accepting, but I have some change requests inline. If anything is unclear, please re-request review :)

Ping for the above comments!

Always clear the cookie if it's a user cookie

It is also weird to me that we try to auth with the keyserver before identity login success.

Note that testing here was flawed and this definitely did not address ENG-7696. That said, I don't think it was a bad idea to land this.

Add a log

Move to CommCoreJSIModulePackage

Maybe we can call it from getJSIModules? We're calling CommSecureStore.getInstance().initialize(secureStoreModuleSupplier); there and it is somehow connected.

In D11659#334885, @tomek wrote:

Why moving this code to CommHybrid fixes the issue?

Can you share a screenshot of what this looks like?

Just a question

Would be good to include screenshots of what the various screens look like from mobile. (You can omit the original screen if it's unchanged.)

Seeing now that @marcin added me for approval:

I can review this one, since I wrote the original code that dispatches setActiveSessionRecoveryActionType

Would also be good for somebody with more familiarity with the rest of the stack to review the dispatch logic, but it generally looks good to me. Just a request to get rid of a createSelector

It's not possible for ThreadActivityStoreEntry to be an empty object?

We should implement it for notifs while working on DMs - now there is no need to I guess.

Love to see more hacks getting removed here!

This diff actually did end up affecting the registration flow. It introduced a very slight regression due to @ginsu's removal of the question mark. @ginsu, can you reply here either with a diff that fixes it, or a task?

For some reason setCommServicesAuthMetadata creates a job that is run on GlobalDBSingleton::instance

Appears to have worked