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>
All the code has been implemented in statusgo: status-im/status-go#1466
Basically all the whisper filter management is done at that level.
Technical description
On startup we load all chats and send a list of them to status go:
For a public chat: {:chatId "status"}, we create a single filter, based on the name of the chat.
For each contact added by us, each user in a group chat and each one to one chat open, we send:
{:chatId "0x", :oneToOne true}. This will create a chats, to listen to their contact code.
Any previously negotiated topic is also returned.
Once loaded, we create our filters, and upsert the mailserver topics, both of which are solely based on the filters loaded.
In order to remove a chat, we delete/stopwatching first the the filter in status-react and then ask status-go to remove the filter. For a public chat we always remove, for a one-to-one we remove only if the user is not in our contacts, or in a group chat or we have a chat open. Negotiated topics are never removed, as otherwise the other user won't be able to contact us anymore.
On stopping whisper we don't have to ask status-go to remove filters as they are removed automatically.
Some more logic can be pushed in status-go, but that will be in subsequent PRs.
Signed-off-by: Andrea Maria Piana <andrea.maria.piana@gmail.com>
- settings are stored in a manifest that is pointed at by the contract
- during login the contract is checked to fetch the settings
Signed-off-by: yenda <eric@status.im>
[#7454] fix add basic copy to public chat empty screen state + chat messages-views intro screens for all chats
Signed-off-by: Igor Mandrigin <i@mandrigin.ru>
In network we show peer infos about you and the connect peers.
Any entry is about is clickable and will copy the value to the
clipboard. Copy info will copy all the info in a JSON string.
Signed-off-by: Andrea Maria Piana <andrea.maria.piana@gmail.com>
- add block/unblock action to user profile
- blocking deletes all messages from user and ignores future messages
- unblocking stops ignoring new messages from user but doesn't recover past ones
[feature] add contact list
[tests] added scroll to BackupRecoveryPhraseButton
[tests] added scroll to public key
Signed-off-by: yenda <eric@status.im>
This PR enables pairing outside of dev-mode and contact-recovery, which
is useful in the case a new device is added or re-installed.
Signed-off-by: Andrea Maria Piana <andrea.maria.piana@gmail.com>
- fix#5371
- fix#4345
- introduce "Connected..." status bar
- introduce fetching animation
- removes overlap of status bar with views
- add animations for status bar
Signed-off-by: yenda <eric@status.im>
When someone is sending a pfs message to us but did not include our own
device, a pop up is shown propmting the user to connect with the user.
The reason for receiving messages that are not targeting our devices are
various:
1) The account was just recovered (which means it is a new installation
id)
2) More than 3 devices are in use (we only keep max 3 devices in sync)
3) The sender has used an old bundle which does not include the current
device
Eventually we will reduce the likelihood of this scenario happening, but
we can't dismiss it completely.
It's only enabled when PFS is enabled.
Signed-off-by: Andrea Maria Piana <andrea.maria.piana@gmail.com>
This commits allow users to toggle pfs in dev-mode (it is already used
for pairing and group chats).
Once enabled direct and public messages sent will only be received by
users running >= 0.9.32.
Also this does not guarantee PFS (both devices need to have it enabled
it), and there still some UX work to do to ensure that, but it is useful
for testing.
A warning is displayed explaining the limitations when enabling.
Members will now have to explicitly join a group chat to start receiving
messages from it.
Messages are still sent to users who have not joined for backward
compatibility.
Group updates are unaffected.
Some more changes
Changes
Fix review items
Rename init-settings to restore-native-settings
Restore application name (thanks @churik !)
Remove org name/domain setting for desktop
Change organization name to include domain
Re-use default values in :desktop/desktop
Signed-off-by: Vitaliy Vlasov <siphiuel@gmail.com>
Add section separator for logging-display
Refactor user-login-callback
Add comment to AppConfig class definition
Fix mobile compilation error
Use reference in AppConfig singleton; remove obsolete CMake directives
Styling changes
Disable status-go logs by default on desktop
Signed-off-by: Vitaliy Vlasov <siphiuel@gmail.com>
We now check that we are only connected to some `peers` instead of using `NetInfo` from `react-native`.
This is because it has been reported to be quite flaky at times, not reporting online status after sleeping, and for privacy concerns (on ios it pings `apple.com`, on desktop `google.com`).
Adds a new banner `Wallet Offline` and change `Connecting to peers` to `Chat offline`.
A message will be marked as `Sent` only if it made it to the mailserver you are connected to, which will increase the guarantees that we can make about a message (if you see it as sent, it has reached at least a mailserver), this has the consequence that:
- If you are not connected to any mailserver or the mailserver is non responsive/down, and you send a message, it will be marked as `Not sent`, although it might have been actually made it in the network.
Probably this is something that we would like to communicate to the user through UX (i.e. tick if made it to at least a peer, double tick if it made to a mailserver )
Currently I have only enabled this feature in nightlies & devs, I would give it a run and see how we feel about it.
There is no need to wait for `Statusgo.Login` callback in order to start
unlocking realm db: currently it is encrypted via a key which is derived
from user’s password, so we can try to unlock that DB before starting
node. That’s how password will be checked. Right after that `:home`
screen is shown, the node is started, then `Statusgo.Login` executed.
The difference in sign in duration is more noticeable on Android
devices, where `Statusgo.Login` is much slower because of PFS database
encryption.
Migration failures are handled separately from other errors which might appear
during opening account's realm DB. In case if user chooses to erase
the account's database, only this database will be removed and other accounts
will not be touched.
Serhy
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
Volodymyr Kozieiev
Julien Eluard
Alexandre Magno
decanus
lokalise-bot
Igor Mandrigin
Zed Tan
mestorlx
Bruce Hauman