There is a desktop app feature where we need to transfer keystore files for selected
keypair/s only via local network using a QR code (of course, which are not migrated
to a keycard, otherwise we wouldn't need to do that).
If user followed onboarding flow to recover his account using seed phrase or keycard,
then `ProcessBackedupMessages` property of node config json object should be set to
`true`, otherwise it should be set to `false` or be omitted.
This commit adds LoginAccount endpoint.
This makes it consistent with CreateAccount and RestoreAccount as they
use similar config.
The notable difference with the previous endpoint is the API, which is
the same as CreateAccount/RestoreAccount, and the fact that it will
override your networks configuration.
Storing them in the config is now not needed anymore, as that's always
driven from the backend, and we won't allow custom networks in the new
wallet.
* Moved all configs into config.go
* Completed build out of new config structures
* Completed SenderClient process flow
* Completed sync data Mounter and client integration
* Completed installation data Mounter and client integration
* House keeping, small refactor to match conventions.
PayloadEncryptor is passed by value and used as a pointer to the instance value and not a shared pointer.
* Reintroduced explicit Mounter field type
* Completed ReceiverClient structs and flows
* Finished BaseClient function parity with old acc
* Integrated new Clients into tests
Solved some test breaks caused by encryptors sharing pointers to their managed payloads
* Built out SenderServer and ReceiverServer structs
With all associated functions and integrated with endpoints.
* Updated tests to handle new Server types
* Added docs and additional refinement
* Renamed some files to better match the content of those files
* Added json tags to config fields that were missing explicit tags.
* fix tests relating to payload locking
* Addressing feedback from @ilmotta
* Addressed feedback from @qfrank
This tests the entire process of converting a regular account to a keycard
account and then converting that keycard account back to a regular account.
For the need of this test I had to improve `DeleteAccount` function, cause the
previous implementation didn't remove account from the keystore cache, but
only from the keystore.
In desktop when a community is created the share url looks like :
https://join.status.im/c/zQ3shTAten2v9CwyQD1Kc7VXAqNPDcHZAMsfbLHCZEx6nFqk9 where
zQ3shTAten2v9CwyQD1Kc7VXAqNPDcHZAMsfbLHCZEx6nFqk9
is the serialised key which desktop uses.
In mobile when a community is created the share url looks like :
https://join.status.im/c/0x025596a7ff87da36860a84b0908191ce60a504afc94aac93c1abd774f182967ce6 where
0x025596a7ff87da36860a84b0908191ce60a504afc94aac93c1abd774f182967ce6
is the non serialised key (but compressed) key which mobile uses.
The goal of this PR is to give mobile the ability to go from
zQ3shTAten2v9CwyQD1Kc7VXAqNPDcHZAMsfbLHCZEx6nFqk9 to 0x025596a7ff87da36860a84b0908191ce60a504afc94aac93c1abd774f182967ce6
`CreateAccountFromMnemonic` function renamed to `createAccountFromMnemonicAndDeriveAccountsForPaths`
and extended in a way that it is able to derive accounts from passed mnemonic for the given paths, if paths is empty
only an account from the given mnemonic will be generated. This endpoint doesn't store anything anywhere.
* feat: add colorId utility
it returns color id for given pubkey
* feat: populate Account with colorHash and colorId
accounts displayed to users on login page should display colorHash and
avatar fallback color (aka colorId)
Richard Ramos
Roman Volosovskyi
Andrea Maria Piana
Samuel Hawksby-Robinson
Sale Djenic
frank
Igor Sirotin
yqrashawn
Siddarth Kumar
Michal Iskierko
Jakub Sokołowski
Vitaliy Vlasov
Anthony Laibe
Patryk Osmaczko
osmaczko