We check that ENS does not return an empty public key. In addition to
that validation is done on status-go in order to avoid saving the chat.
Signed-off-by: Andrea Maria Piana <andrea.maria.piana@gmail.com>
There was some confusion when given ref/tag did not exist.
Script would just use the value as commit SHA1 even if it was not one.
Signed-off-by: Jakub Sokołowski <jakub@status.im>
This commits resolves ENS names in the background, implementing retries
and exponential backoff.
All is handled in the background in status-go.
Signed-off-by: Andrea Maria Piana <andrea.maria.piana@gmail.com>
Storing absolute path for different configs breaks compatibility on iOS
as app's dir is changed after upgrade. The solution is to store relative
paths and to concatenate it with `backend.rootDataDir`. The only
exception is `LogFile` as it is stored outside `backend.rootDataDir` on
Android. `LogDir` config was added to allow adding of custom dir for log
file.
Configs concerned:
`DataDir`
`LogDir`
`LogFile`
`KeystoreDir`
`BackupDisabledDataDir`
Add contact indicator in 1:1 as a text. Fixes#9826
Fix e2e
explicitly define line height
On android and iOs line height is different, explicitly define so it will be the same in both platforms.
Signed-off-by: Gheorghe Pinzaru <feross95@gmail.com>
Front end changes:
As there is no guarantee that `newblock` event will be dispatched
consequently (e.g. if there was a delay after block#1 the next event
might be dispatched for a block#2000, no guarantee that block#2 will be
the next one), `newTransactions` field was added with a map of accounts
to the number of new transactions received to this block. In result if
there are new transactions we request them all of db instead of fetching
them on for the block specified in `newblock` event, as it was done
previously.
Back end changes:
- In order to avoid handling of the reorganized blocks we use an offset
from the latest known block when start listening to new blocks. Before
this commit the offset was 15 blocks for all networks. This offset is
too big for mainnet and causes noticeable delay of marking a transfer as
confirmed in Status (comparing to etherscan). So it was changed to be 5
blocks on mainnet and is still 15 blocks on other networks.
- Also before this commit all new blocks were handled one by one with
network specific interval (10s for mainnet), which means that in case of
lost internet connection or application suspension (happens on iOS)
receiving of new blocks would be paused and then resumed with the same
"speed" - 1 blocks per 10s. In case if that pause is big enough the
application would never catch up with the latest block in the network,
and this also causes the state of transfers to be delayed in the
application. In this commit in case if there was more than 40s delay
after receiving of the previous block the whole history in range between
the previous received block and ("latest"-reorgeSafetyDepth) block is
checked at once and app catches up with a recent state of the chain.
We should only start receiving messages/processing topics once all the
initializiation is completed, so an endpoint that start the messenger
has been added.
Before we would initialize the topics/receiving messages at the same time,
which resulted in a race condition where a topic was signaled from
status-go and was considered new just because was not loaded yet.
Signed-off-by: Andrea Maria Piana <andrea.maria.piana@gmail.com>
Handle ens-name in qr reader
If user has an username generate link with it
Ensure no infinite recursion happens on qr scan event
Fix test for custom profile ens-name
Fix QR code read for ens-name
Extra check for ens name in QR code
Do not open unknown profile for bad ens name
Signed-off-by: Gheorghe Pinzaru <feross95@gmail.com>
When moving from chat to chat, component-did-mount is not fired as the
component is never unmounted, therefore messages were not loaded.
This changes the behavior to use the component-did-update lifecycle
method.
Signed-off-by: yenda <eric@status.im>
This commit fixes a couple of issues.
The first one is that when we go from offline->cellular-network->wifi
historical requests were not triggered (only when going from
offline->online, but if they are disabled in cellular network they won't
fire).
The second is due to the fact that it is possible that the connection
status gets into a bad state, (this happens for example if get-latency
returns all errors, but we are online, and it won't be retried), and no
connection attempt is made anymore.
I have changed the logic to periodically check the connection state, and
try to connect if too much time has passed since last error (10s),
similarly to what we did before, but in a tick, so we are less reliant
on having the right state in the db.
Signed-off-by: yenda <eric@status.im>
Serhy
Volodymyr Kozieiev
krzyzowiec
Jakub Sokołowski
Andrey Shovkoplyas
Gheorghe Pinzaru
Roman Volosovskyi
Andrea Maria Piana
Dean Eigenmann
yenda
Jinho Jang