I like the generic name here... hopefully we can reuse this component for other parts of the registration flow where we might want to get data from existing users

siweBackupSecrets - backup message and its signature that is created by CreateSIWEBackupMessage component (earlier in the stack). They are passed to RegistrationContext so that it can persist them in SQLite.

nativeSIEEBackupSecrets - backup message and its signature that are already persisted in SQLite.

Why do we have to check nativeSIWEBackupSecrets?

If this data is not present in SQLite we have to force user to create it by navigating to relevant screen. However there can be a case that user is in the process of registration. In such case siweBackupSecrets may be present but they haven't been persisted yet in SQLite but they are soon going to be. On the other hand I am starting to wonder if we actually need this check - wouldn't !loggedIn || accountHasPassword(currentUserInfo) be enough.

This data is not persisted in JS - it is only used to temporarily keep data before they are stored in SQLIte. It would be best to take a look at this diff: https://phab.comm.dev/D11638 since it introduces and handles this data,

I think that !loggedIn || accountHasPassword(currentUserInfo) will suffice.

Please ignore the comment above - it was my mistake. This condition is necessary to prevent this screen from showing after successful registration if loggedIn value happens changes before data becomes present in SQLite.

Let me address this comment from @tomek again:

cachedSelections.siweBackupSecrets - during registration CreateSIWEBackupMessage component will create backup message and its signature. It will pass it to RegistrationContext (by setCachedSelections) which will put it to SQLite and set this data to undefined.

nativeSIWEBackupSecrets - backup message and its signature fetched from SQLite. If the user is ETH user we check if this data is present in SQLite. If it is not there we need to trigger its creation by navigating to the screen responsible for their creation. However we also need to check for cachedSelections.siweBackupSecrets. Imagine the case that during registration loggedIn becomes truth before this data is persisted to SQLite. In such case we need to check first in we aren't in the process of persisting siweBackupSecrets to SQLIte.

If the user closes the app and then reopens it then siweBackupSecrets are missing but nativeBackupSecrets will return data that is persisted in SQLite (in case it was persisted).

siweBackupSecrets in temporarily present in the memory during registration. After registration is complete this data is deleted from memory and persisted to SQLite. Subsequent runs of the app won't have this data in the memory but will have it in SQLite. So the decision whether to force already logged in user to generate this data or not cannot be made based on siweBackupSecrets alone. We must look for this data in SQLite.

Ok, makes sense, thanks!