This commit moves all the processing of messages to status-go.
Messages are going arrive to status-react already saved an processed.
Receiving/sending/retrieving from db is now using the same identical
structure. The only processing left in status-react is to mark the
messages as seen and update the unviewed count locally (only
status-react knows whether the count should be updated).
Partially remove commands as well as won't be used anymore.
Signed-off-by: Andrea Maria Piana <andrea.maria.piana@gmail.com>
To make it work `encryption-public-key` and `whisper-private-key` are
stored on the devices when a user chooses this option. The former key is
used for multiaccount's database encryption, the latter is needed for a
messaging. In case if a user wants to sign a transaction the card is
still needed, we don't store wallet's keys on the device.
Other things were fixed/added:
- A user can enable biometric auth for a regular account when chooses
to save the password on the device (if biometric auth is available).
This is done for feature parity between keycard and "on device"
accounts.
- The option to create/restore an account on a keycard is not shown on
the devices which do not support NFC. Currently, the app just crashes
if the user continues a flow which is not supported by the device.
Currently we have two ways to restore a multiaccount:
- by entering a mnemonic phrase
- by pairing a keycard with an existing multiaccount
In both cases, when we detect that a user tries to recover an existing
multiaccount we interrupt recovering and propose them to unlock that
multiaccount instead.
find account by key-uid
show pairing slots info on pairing
fix pin reset flow
pass retry-counter
fix sign with keycard button in wallet
Signed-off-by: Dmitry Novotochinov <dmitry.novot@gmail.com>
There are some instances on the keycard screens that read `Recover key` rather than `Access key`, this is dated language so I've changed it. There are a few other instances of the word 'recover' in relation to keycard that may also need to be changed, but I'm not sure what context they are in.
Signed-off-by: Andrey Shovkoplyas <motor4ik@gmail.com>
A user can type in their existing name in the registration flow. Status can
confirm if they own it. After signing a transaction, the user can update the
Whisper ID to their new one.
Instead of using a hardcoded contract for stateofus, the standard `owner`
method is called to find the resolver contract of a ens name.
This allows users to set the pubkey even for ens names that are not
subdomains of stateofus
Signed-off-by: yenda <eric@status.im>
Fixes copy update in #8447
In the UI we want to refer to a watch only address as `address` instead of `account`. Interactions with an address are limited compared to an account in wallet. e.g. there is no option to send assets from this account as Status wallet does not have the key to sign for transactions.
Signed-off-by: Andrey Shovkoplyas <motor4ik@gmail.com>
replace i18n/message-status-label by regular label to avoid repeating
this issue in the future
recover the following labels:
- status-not-sent-click
- status-not-sent-tap
- status-sent
Signed-off-by: yenda <eric@status.im>
Resolves https://github.com/status-im/status-react/issues/8694
Old 'About names' copy:
Your identity is secure and private by design. You get a locally generated cryptographic keypair. The name and image are a readable version of this. They are unique. Nobody can pretend to be you. Nobody sees your name unless you provide it.
New 'About names' copy:
Your identity is secure and private by design. You get a locally generated cryptographic keypair. The name and image are a readable version of this. They are unique. Nobody can pretend to be you. Nobody sees your real name unless you provide it.
Signed-off-by: Andrey Shovkoplyas <motor4ik@gmail.com>
In preparation for v1 this commits adds a few options so we can get
start debugging the protocol for v1.
This options are:
1) Datasync: If enabled it will send datasync messages
2) V1Messages: If enabled it will send v1 messages (just adding a
signature to the message)
3) Disable discovery topic: If enabled it will stop listening/publishing
on the discovery topic. You will be able to receive messages only from
clients who have this enabled as well.
If any of this option is on, it will only be compatitle with builds >=
this one. A logout is required for any change to take effect.
All this options will be removed before v1, they are there just to make
it easier for us to test and find potential issues.
Signed-off-by: Andrea Maria Piana <andrea.maria.piana@gmail.com>
Andrey Shovkoplyas
Roman Volosovskyi
Andrea Maria Piana
Churikova Tetiana
elegant651
Dmitry Novotochinov
Rachel Hamlin
William Mruzek
yenda
Vitaliy Vlasov
Marcus R. Brown
hesterbruikman
tbenr
acolytec3
bitsikka
MajorTomSec
Pedro Pombeiro