- if multiaccount settings are saved on top of an empty map or nil,
this means something went wrong, the state of the app is unstable,
and actually saving will result in loss of data. It should never
happen, but if it does, throw and error and abort.
- sometimes two fxs are merged when they shouldn't, this is caused by
bugs and should never happen, but if it does, throw an error with arguments
for both effects to help localize the error
Signed-off-by: yenda <eric@status.im>
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>
- Use community net-info, react-native-webview instead of deprecated react-native classes
- Remove react-native-tcp
- Upgrade react-native libs (react-native-camera, react-native-firebase, react-native-mail, react-native-udp, react-native-webview-bridge)
- Do not include `:react-native-android` module explicitly
- Take advantage of RN AutoLinking
- nix: Update Gradle dependencies
fix#8702
- use ethereum.utils sha3 function to hash passwords before sending them
to status-go
- some native calls take password as one of their params: they now take
hashed-password (still a string, only relevant for status-react caller)
- some native calls take password within a map of rpc params: it now
needs to be hashed with `ethereum.core/sha3`
Signed-off-by: yenda <eric@status.im>
fix#8786
- multiaccount recovery wasn't saving the root key properly
- this resulted in the impossibility to add new accounts in the wallet
Signed-off-by: yenda <eric@status.im>
This commit does a few things:
1) Move messages to status-go
2) Use message-id computed from status-go
3) Remove old replies
Old message id was used for compatibility of replies with older clients.
Given that v1 is breaking, this is not needed anymore and simplifies
moving messages to status-go. No protocol/data-store change is made, to minimize
changes.
Signed-off-by: Andrea Maria Piana <andrea.maria.piana@gmail.com>
Contacts are now in status-go, no migration of contacts is provided so
all contacts will be lost upon installing this build.
I have left the initialization of filters a bit sketchy (we wait that
load-filters is called twice), as the next step will be to avoid calling
load-filters altogether, as now that both contacts & chats are in
status-go, there's no reason to call it from status-react, and can be
called directly from status-go on loading.
Signed-off-by: Andrea Maria Piana <andrea.maria.piana@gmail.com>
This commit moves chats to status-go.
I have changed the logic to load all chats in one go for simplicity and
while that might have a performance impact, I think it's premature to
optimize this flow as there will be more changes to the login flow.
Also currently this is likely to be slower as we need to wait for the
status-service to be initialized, as well as realm.
No migration is provided as we are past the point of no return, so by
installing this version you will lose your chats.
Signed-off-by: Andrea Maria Piana <andrea.maria.piana@gmail.com>
Currently on some devices there are still some legacy chats(?) that are
one-to-one but don't have a public key as an id (transactor,demo-bot).
We were wrongly sending those to status-go to create filters.
Signed-off-by: Andrea Maria Piana <andrea.maria.piana@gmail.com>
This commits changes the behavior to read from a signal instead of
polling each filter.
We receive a signal from status-go every 0.3 seconds, only if new
messages are received. We receive a single signal for all the chats, and
we don't dispatch anymore on every message.
Signed-off-by: Andrea Maria Piana <andrea.maria.piana@gmail.com>