Change Details

[ENG-9656](https://linear.app/comm/issue/ENG-9656/native-changes-for-minimal-version-of-backup). There are several options on how to implement this: 1. `createUserKeysBackup: (backupSecret: string)` -> we pass the secret (password or signature), and message is read from SQLite. It's definetely the cleanest to use, but for SIWE users we first read signature from SQLite to pass this again to C++ via JSI to then read message again from C++ level. 2. `createUserKeysBackup: (backupSecret: ?string)` -> and then we can pass secret for password users, for SIWE read it directly from SQLite avoid transferring data (this was pointed by @varun in https://phab.comm.dev/D13847#inline-78286). However, using nullable values raise concerns explained in https://phab.comm.dev/D11715?id=39388#inline-70515. 3. `createUserKeysBackup: (backupSecret: string)` and createUserKeysBackupSIWE: ()` -> having separate JSI calls for SIWE and wallet users doing almost the same, for me it's the least clean, I prefer having one API to work regardless of user type. I implemented 1, which is not the best in terms of transferring data but it's the cleanest one - but I am open to update. Depends on D13933

[ENG-9656](https://linear.app/comm/issue/ENG-9656/native-changes-for-minimal-version-of-backup). There are several options on how to implement this: 1. `createUserKeysBackup: (backupSecret: string)` -> We pass the secret (password or signature), and the SIWE message is read from SQLite. It's definitely the cleanest to use, but for SIWE users we first read the signature from SQLite to pass this again to C++ via JSI to then read the message again from the C++ level. 2. `createUserKeysBackup: (backupSecret: ?string)` -> We can pass secret for password users, for SIWE read it directly from SQLite to avoid unnecessarily transferring data (this was pointed by @varun in https://phab.comm.dev/D13847#inline-78286). However, using nullable values raises concerns explained in https://phab.comm.dev/D11715?id=39388#inline-70515. 3. `createUserKeysBackup: (backupSecret: string)` and createUserKeysBackupSIWE: ()` -> having separate JSI calls for SIWE and wallet users doing almost the same, for me it's the least clean, I prefer having one API to work regardless of user type. I implemented 1, which is not the best in terms of transferring data but it's the cleanest one - but I am open to updating. Depends on D13933

[ENG-9656](https://linear.app/comm/issue/ENG-9656/native-changes-for-minimal-version-of-backup). There are several options on how to implement this: 1. `createUserKeysBackup: (backupSecret: string)` -> weWe pass the secret (password or signature), and the SIWE message is read from SQLite. It's defineitely the cleanest to use, but for SIWE users we first read the signature from SQLite to pass this again to C++ via JSI to then read the message again from the C++ level. 2. `createUserKeysBackup: (backupSecret: ?string)` -> and then weWe can pass secret for password users, for SIWE read it directly from SQLite to avoid unnecessarily transferring data (this was pointed by @varun in https://phab.comm.dev/D13847#inline-78286). However, using nullable values raises concerns explained in https://phab.comm.dev/D11715?id=39388#inline-70515. 3. `createUserKeysBackup: (backupSecret: string)` and createUserKeysBackupSIWE: ()` -> having separate JSI calls for SIWE and wallet users doing almost the same, for me it's the least clean, I prefer having one API to work regardless of user type. I implemented 1, which is not the best in terms of transferring data but it's the cleanest one - but I am open to updateing. Depends on D13933