1. Put SIWE backup secrets persistence to step 1.
2. Put clearing cached selections to step 2.

1. Update the comment
2. Use method to get badge only content for notif.

Add finally statements to set gurd refs to false eventually.

It wasn't easy to introduce new step here. If this solution is not accepted I will just introduce new step that clears cached Selections in the same promise as sqlite persistence and leave avatar upload unchanged.

Introduce two new steps: SQLite data persistence and clearing cached selections

Encrypt with Ethereum Wallet -> Encrypt with Ethereum signature

1. Remove needsSilentBadgeUpdate function and replace it with inline checks.
2. Bring back useful comment.

Persist directly to SQLite when forcing user to create backup message signature.

REbase to reflect changes from parent diff

Move siwe secrets persistence and cached selections clearing to registration server call.

If we go back from registration terms screen then siwe backup message creation screen looks like this:

Handle existing siwe backup secrets in cached selections.

In D11666#335421, @tomek wrote:

Should we regenerate a wasm file?

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?

1. Clear all cached selections at once after user becomes logged in. Persist siweBackupSecrets in SQLite beforehand.

Screen with backup icon from MaterialIcons

Use backup icon from MaterialIcons

Use backup icon from MaterialIcons

New screen looks like this:

Add icon to enchance user experience.

Bring back deleted condition that is actually necessary.

Simplify condition

Memoize CreateSIWEBackupMessageBase

Use cachedSelections to keep siweBackupSecrets

1. Update user texts

In D11635#334580, @ashoat wrote:

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.)

Video with the registration flow:

In D11637#334446, @atul wrote:

Looks good. (There shouldn't be any WASM stuff that needs to be generated for the non-DB code here right?)

Rebase before landing.

One additional questions:
Is it possible that due to some internal keyserver error the cookie will change and the keyserver will request the client to create new notifs session but new notifications session creation will execute before the effect is executed? In such case the old session would overwrite new one.

I would amend to the test plan some steps that try to recreate race condition when we log in multiple pages at the same time. We should expect that after logging in to all pages we can see multiple notifs sessions in IndexedDB but when the notifs is received we can decrypt it and it removes all but one notif session.

Simplify hook

Diff from 2022 what I was assigned encrypted blob upload work.

Diff from 2022 what I was assigned encrypted blob upload work.

Diff from 2022 what I was assigned encrypted blob upload work.

Diff from 2022 what I was assigned encrypted blob upload work.

Diff from 2022 what I was assigned encrypted blob upload work.

Diff from 2022 what I was assigned encrypted blob upload work.

Diff from 2022 what I was assigned encrypted blob upload work.

Diff from 2022 what I was assigned encrypted blob upload work.

GlobalDBSingleton handles that.

The only purpose of this diff was to create release that could potentially fix the crash https://linear.app/comm/issue/ENG-1464/ios-build-137-crashes

It was already done. This diff: https://phab.comm.dev/D8601 confirms it.

This diff was only used to create a release that was supposed to fix a crash: https://linear.app/comm/issue/ENG-1464/ios-build-137-crashes. The solution wasn't correct.

This diff is no longer relevant - abandoning.

In D11577#333862, @ashoat wrote:

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

Is there a task for this?