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 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)` -> 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. Note, that this API won't be used a lot. 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. Note, that this API won't be used a lot. Depends on D13933