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>
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`
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>
- all messages are not shown right away, in order to paginate history
a user has to press "load more" button
- added link to etherscan before transfers list
- there is a new "fetch more" button at the end of the list
- rest of changes can be found here status-im/status-go#1775
Accounts were previously stored within the multiaccount `setting`
serialized in transit
This moves [:multiaccount :accounts] to `:multiaccount/accounts` and uses
the `getAccounts`, `saveAccounts` and `deleteAccounts` endpoints.
Signed-off-by: yenda <eric@status.im>
This commit completely remove transit for group chats. All the
processing is now done in status-go.
Also introuduces parsing and handling of mentions, needed so that system
messages can be easily built in status-go.
Signed-off-by: Andrea Maria Piana <andrea.maria.piana@gmail.com>
Account's address was used as a primary key in accounts db and as a
deterministic id of an account in some API calls. Also it was used as a
part of the name of the account specific database. This revealed some
extra information about the account and wasn't necessary.
At first the hash of the address was planned to be used as a
deterministic id, but we already have a keyUid which is calculated as
sha256 hash of account's public key and has similar properties:
- it is deterministic
- doesn't reveal accounts public key or address in plain
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>
- if not mailserver was actively selected by user,
use rpc call to get latency for known mailservers
and use the best one
- this happens when `set-current-mailserver` is called which happens
in `change-mailserver` when user unpins his preferred mailserver and when
there's been too many failed attemps to fetch messages or to connect to
then current mailserverm as well as when user logs in.
Signed-off-by: yenda <eric@status.im>
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.
Also:
- upgrade Go: 1.12 > 1.13
- upgrade Android SDK: 28.0.3 > 29.0.2
- nix: stop using system Fastlane for iOS builds
- nix: include CocoaPods in shell for iOS
- nix: concatenate shellHooks correctly
- fix gomobile status-go build by setting GO111MODULE=off
- fix gradle accepting empty STATUS_GO_SRC_OVERRIDE value
- don't use a pure shell for uploadToSauceLabs()
Signed-off-by: Jakub Sokołowski <jakub@status.im>
Fixes: https://github.com/status-im/trailofbits-audit/issues/47
Fixes: https://github.com/status-im/trailofbits-audit/issues/46
Fixes: https://github.com/status-im/trailofbits-audit/issues/44
Fixes: https://github.com/status-im/security-reports/issues/13
Fixes: https://github.com/status-im/security-reports/issues/5
Fixes: https://github.com/status-im/status-react/issues/8995
This commits re-introduce rendering of markdown text and implent a few
changes:
1) Parsing of the message content is now in status-go, this includes
markdown, line-count, and rtl. Parsing is not nested, as there's some
rendering degradation involved as we nest components, unclear exactly if
it's react-native or clojure, haven't looked too deeply into it.
2) Emojii type messages are not parsed on the sending side, not the
receiving one, using the appropriate content-type
3) Fixes a few issues with chat input rendering, currrently we use
`chats/current-chat` subscription which is very heavy and should not be
used unless necessary, and means that
any change to chat will trigger a re-render, which caused re-rendering
of input container on each received message. Also to note that
input-container is fairly heavy to render, and it's rendered twice at
each keypress on input.
The inline markdow supported is:
*italic* or _italic_
**bold** or __bold__
`inline code`
http://test.com links
\#status-tag
The block markdown supported is:
\# Headers
```
code blocks
```
> Quotereply
The styling is very basic at the moment, but can be improved.
Adding other markdown (photo,mentions) is straightforward and should
come at little performance cost (unless the component to render is
heavy, i.e a photo for example).
There are some behavioral changes with this commit:
1) Links are only parsed if starting with http:// or https://, meaning that
blah.com won't be parsed, nor www.test.com. This behavior is consistent
with discord for example and allows faster parsing at little expense to
ser experience imo. Fixes a few security issues as well.
2) Content is not anymore capped (regression), that's due to the fact that
before we only rendered text and react-native allowed us easily to limit
the number of lines, but adding markdown support means that this
strategy is not viable anymore. Performance of rendering don't see to be
very much impacted by this, I would re-introduce it if necessary, but
I'd rather do that in a separate PR.
Signed-off-by: Andrea Maria Piana <andrea.maria.piana@gmail.com>
This commit enables parsing of messages in status-go.
Currently only a few messages are supported in status-protocol-go.
For now we only enable Message types.
Status-react will conditionally use the parsed version if present.
Eventually this can be moved to a separate signal/different structure,
but for the time being is best to validate with the minimum amount of
changes.
The next step would be handle validation and processing of the field in
status-go, so we can skip saving the message from status-react.
This commit should improve performance of receiving messages from a
chat, although haven't had time to validate that.
Signed-off-by: Andrea Maria Piana <andrea.maria.piana@gmail.com>
This commit includes a few performance fixes:
1) Pass a string payload instead of an hex encoded string, to avoid
unecessary conversion
2) Don't js->clj on messages, as that's fairly expensive and we can get
away without
3) Don't use `pr-str` `read-string`, rather convert to json
Signed-off-by: Andrea Maria Piana <andrea.maria.piana@gmail.com>
Logout from keycard account was redirecting to login screen for another user
because `b.multiaccountsDB.UpdateAccountTimestamp` was not called in
`startNodeWithKey` as it was done in `startNodeWithAccount` in status-go
The fix is therefore in status-go and this PR updates status-go version to
fix that
Signed-off-by: yenda <eric@status.im>
We use the timestamp of the last message in the chat preview.
In case there's no message, the old timestamp will be displayed (last
time the chat has been updated).
Signed-off-by: Andrea Maria Piana <andrea.maria.piana@gmail.com>
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>
This commit adds datasync confirmations and enables device-to-device for
all the communications, as that's what we will go with v1.
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>
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>
Andrea Maria Piana
Roman Volosovskyi
Volodymyr Kozieiev
Jakub Sokołowski
yenda
Adam Babik
Dmitry Novotochinov
Andrey Shovkoplyas
Pedro Pombeiro