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>
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.
- 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.
when checking the checkbox, the entire list was being re-rendered
we now only re-render if the `checked?` value has changed
Signed-off-by: yenda <eric@status.im>
Currently there are two ways to initiate logging in with keycard:
- enter PIN code and after that connect card to the phone
- connect card to the phone and enter PIN after that
Before this commit in both cases when connection to the keyacrd was lost
and then restored, logging in didn't resume. In result a user saw a
pop-up with endless spinner.
The reason of this bug was that `:on-card-connected` and `:on-card-read`
actions were not restored in app-db after losing connection to the card.
This commit introduces helper functions for both `:on-card-connected` and
`:on-card-read` which allow to reset these values and stash them until
particular flow of calls to keycard will be finished. In case if
connection was lost before the flow is finished the valueas are restored
so that it can be succesfully resumed on th next connection.
Also a banch of log entries were added to simplify debugging of
interactions with keycard and native module.
Signed-off-by: Andrey Shovkoplyas <motor4ik@gmail.com>
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>
Fixes#9433 : this was due to the fact that `.-response-to` was
returning nil, because of the dash in the name, instead in this cases
`(aget .. "response-to")` should be used.
Fixes#9431 : This was a left-over from the move from message-groups to
message-list, and the code was not updated.
Fixes#9430#9429 Both of these were due to the same issue, cofx were
wrongly passed to the function resulting in the db being updated but the
fxs being discarded.
There's still a separate issue that might result in messages not being
saved on logout, because of a race condition (if you logout while is
fetching messages, some of the message might not be saved). I will
address that separately as we might be able to just save messages as
they come in status-go, rather then having to pass them to status-react
and back to status-go for saving.
Signed-off-by: Andrea Maria Piana <andrea.maria.piana@gmail.com>
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>
- add option in profile on Android to enable local notifications
- use foreground service to keep the app alive when running in the background
- implement enable and disbable notification function in status module
When enabling notifications, a foreground service is started that displays
a sticky notification to make the user aware that the app is running in the
background.
Notifications are updated whenever a new.message signal is handled on java side.
Currently only one to one chats are generating notifications but that can be
easily extended to other types of messages, including mentions and keywords.
The ens name of the user as well as keywords to follow should then be passed
to the native side when calling the enable function.
Signed-off-by: yenda <eric@status.im>
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>
The from parameter was left out, tests did not pick it up as they were
not running, probably I have wrongly rebased the code and did not
include the new namespace in runner.cljs
Signed-off-by: Andrea Maria Piana <andrea.maria.piana@gmail.com>
This commit does a few things:
==== Ordering of messages ====
Change the ordering of messages from a mixture of timestamp/clock-value to use
only clock-value.
Datemarks are now not used for sorting anymore, which means that the
order of messages is always causally related (not the case before, as we
were breaking this property by sorting by datemark), but datemark
calculation is unreliable (a reply to a message might have a timestamp <
then the message that is replied to).
So for timestamp calculation we
naively group them ignoring "out-of-order timestamp" messages, although
there's much to improve.
It fixes an issue whereby the user would change their time and the
message will be displayed in the past, although it is still possible to
craft a message with a lower clock value and order it in the past
(there's no way we can prevent this to some extent, but there are ways
to mitigate, but outside the scope of this PR).
==== Performance of receiving messages ====
The app would freeze on pulling messages from a mailserver (100 or so).
This is due to the JS Thread being hogged by CPU calculation, coupled
with the fact that we always tried to process messages all in one go.
This strategy can't scale, and given x is big enough (200,300,1000) the
UI will freeze.
Instead, each message is now processed separately, and we leave a gap
between processing each message for the UI to respond to user input
(otherwise the app freezes again).
Pulling messages will be longer overall, but the app will be usuable
while this happen (albeit it might slow down).
Other strategies are possible (calculate off-db and do a big swap,
avoiding many re-renders etc), but this is the reccommended strategy by
re-frame author (Solving the CPU Hog problem), so sounds like a safe
base point.
The underlying data structure for holding messages was also changed, we
used an immutable Red and Black Tree, same as a sorted map for clojure, but we use
a js library as is twice as performing then clojure sorted map.
We also don't sort messages again each time we receive them O(nlogn), but we
insert them in order O(logn).
Other data structures considered but discarded:
1) Plain vector, but performance prepending/insertion in the middle
(both O(n)) were not great, as not really suited for these operations.
2) Linked list, appealing as append/prepend is O(1), while insertion is
O(n). This is probably acceptable as messages tend to come in order
(from the db, so adding N messages is O(n)), or the network (most of
them prepends, or close to the head), while mailserver would not follow this path.
An implementation of a linked list was built, which performed roughtly the
same as a clojure sorted-map (although faster append/prepend), but not
worth the complexity of having our own implementation.
3) Clojure sorted-map, probably the most versatile, performance were
acceptable, but nowhere near the javascript implementation we decided on
4) Priority map, much slower than a sorted map (twice as slow)
5) Mutable sorted map, js implementation, (bintrees), not explored this very much, but from
just a quick benchmark, performance were much worse that clojure
immutable sorted map
Given that each message is now processed separately, saving the chat /
messages is also debounced to avoid spamming status-go with network
requests. This is a temporary measure for now until that's done directly
in status-go, without having to ping-pong with status-react.
Next steps performance wise is to move stuff to status-go, parsing of
transit, validation, which is heavy, at which point we can re-consider
performance and how to handle messages.
Fixes also an issue with the last message in the chat, we were using the
last message in the chat list, which might not necessarely be the last
message the chat has seen, in case messages were not loaded and a more
recent message is the database (say you fetch historical messages for
1-to-1 A, you don't have any messages in 1-to-1 chat B loaded, you receive an
historical message for chat B, it sets it as last message).
Also use clj beans instead of js->clj for type conversion
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>
This commits verifies ens names when new messages or contact requests
come through.
A batch of ens names is sent to status-go which will then verifying them
and the result will be passed back in a callback to status-react.
Also temporary skipped test_ens_in_public_chat until we merge the ENS
code (blocked currently by 1.9 upgrade)
Signed-off-by: Andrea Maria Piana <andrea.maria.piana@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>
currently navigation-reset only works properly if you reset to a simple route
this fix allows us to use navigation reset with more complex routes, by
ensuring that the navigation stack is populated properly so that navigate
back doesn't end up emptying the stack.
this is temporary as the proper way to do navigation in general would be
to get rid of view id and navigation-stack entirely, since it is a duplication
of the state of react-navigation
Signed-off-by: yenda <eric@status.im>
master key
When creating the account we store as well the path specified in eip1581
https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1581.md ,
`m / 43' / 60' / 1581'`.
The reason for doing so is that eventually we might want to derive an
encryption key from it, which would require the user to re-enter their
seed phrase if we would not store this.
This commit changes the behavior not to store the master key, and
instead store `m /44'/60' /0'/0`, from which wallets are now derived.
Signed-off-by: Andrea Maria Piana <andrea.maria.piana@gmail.com>
- 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>
- renamed the macros def and defn so that they are now used with aliased
namespace `styles/def` and `styles/defn` to force user to use aliased require
instead of require-macro and refer
- this makes sure the cljs file is required which includes the require for
platform ns needed after macroexpension
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>
safe merge was using way too much inefficient code for such an important
function
it is rewritten using a reduce. the performance improvement is 10 times
and should really show up when adding messages
in repl session the new merge was much slower on the error case of merging
fx with common keys but it must never happen in production as it means
the app is broken
status-im.utils.fx> (time (dotimes [x 100] (fast-merge {:a 1 :b 2 :filters/load-filters [{:a 1 :b 2}]} {:c 3 :filters/load-filters [{:d 1 :b x}]})))
"Elapsed time: 19.000000 msecs"
nil
status-im.utils.fx> (time (dotimes [x 100] (safe-merge {:a 1 :b 2 :filters/load-filters [{:a 1 :b 2}]} {:c 3 :filters/load-filters [{:d 1 :b x}]})))
"Elapsed time: 183.000000 msecs"
status-im.utils.fx> (time (dotimes [x 100] (fast-merge {:a 1 :c 2 :filters/load-filters [{:a 1 :b 2}]} {:c 3 :filters/load-filters [{:d 1 :b x}]})))
"Elapsed time: 2224.000000 msecs"
- 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>
- remove impl/modules.cljs namespace because it was needlessly redundant
- remove `create-account` unused call
- add documentation for some calls
- only keep `(status)` check for relevant calls that are failing tests
because they are evaluated
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>
Andrey Shovkoplyas
Vitaliy Vlasov
acolytec3
yenda
Maciej Zadykowicz
Volodymyr Kozieiev
Roman Volosovskyi
Andrea Maria Piana
Serhy
elegant651
Dmitry Novotochinov
William Mruzek
tbenr
Marcus R. Brown
Alex Good
Pedro Pombeiro
bitsikka
jiachen
b-m-f