Page MenuHomePhabricator

[CommCoreModule] implement creating User Keys backup
ClosedPublic

Authored by kamil on Nov 14 2024, 8:50 AM.
Tags
None
Referenced Files
F3513489: D13934.id46012.diff
Sun, Dec 22, 12:25 AM
F3513488: D13934.id45825.diff
Sun, Dec 22, 12:25 AM
F3513439: D13934.id.diff
Sun, Dec 22, 12:24 AM
F3513431: D13934.diff
Sun, Dec 22, 12:24 AM
Unknown Object (File)
Thu, Dec 19, 6:38 AM
Unknown Object (File)
Sun, Dec 15, 11:57 PM
Unknown Object (File)
Sun, Dec 15, 5:54 PM
Unknown Object (File)
Sat, Dec 14, 9:16 PM
Subscribers

Details

Summary

ENG-9656.

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

Test Plan

Tested in D13937

Diff Detail

Repository
rCOMM Comm
Branch
publish-client-backup
Lint
No Lint Coverage
Unit
No Test Coverage

Event Timeline

kamil held this revision as a draft.
kamil edited the summary of this revision. (Show Details)
kamil edited the summary of this revision. (Show Details)
kamil published this revision for review.Nov 15 2024, 2:25 AM

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.

I agree with this reasoning

This revision is now accepted and ready to land.Nov 20 2024, 7:46 AM