This PR is part of network incentivisation. It adds a way for a client
to pull nodes from a contract.
This is done by selecting the `eth.contract` fleet. If that is selected
on login it will fetch nodes from a contract and pass them to status-go.
If these can't be fetched, it will default to `eth.beta`.
Currently contract information are hard-coded, but eventually the user
will be able to add their own (probably).
Toggled off in release.
Signed-off-by: Andrea Maria Piana <andrea.maria.piana@gmail.com>
[#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>
* `open-sign-transaction-flow` cleaner version of
`open-modal-wallet-for-transaction`
* The contract namespace provides the `call` effect:
- takes contract identifier from contracts, method, params and callback
- select the correct contract address based on current network
- encode params, decodes results
- start wallet transaction flow for write calls
Signed-off-by: yenda <eric@status.im>
- support for ipfs only
- provides fns to encode and decode contenthashes as defined in EIP1577
- provides cat fx to retrieve contenthash
Signed-off-by: yenda <eric@status.im>
- remove web3 parameter for ethereum/call
- remove first parameter for callback of ethereum/call which
was always nil
Signed-off-by: yenda <eric@status.im>
In some cases (say the clock of the device has drifted) specifying a `to` parameter
is decrimental and might result in missing messages.
We have changed the mailservers to default `to` if not present to `now`,
which should gives us better guarantees.
We also removed the 24 hours limit as now all the requests will be
paginated according to the `limit` parameter.
Signed-off-by: Igor Mandrigin <i@mandrigin.ru>
Sometimes it happens that the expired signal is received while the
there's a new request in flight.
This happens in cases such as:
1) We send a request (A)
2) We get disconnected from the mailserver
3) We connect to a new mailserver
4) We send a request (B)
5) We receive an expired signal for A
In such cases the request should not be retried or counted as a failure.
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>
Currently the separate topic was not used, as it's a bit tricky to
coordinate when multiple devices from different versions are present,
with the partitioned topic, probably this optimisation is not necessary
anymore, so removing this for now.
Signed-off-by: Andrea Maria Piana <andrea.maria.piana@gmail.com>
When we are offline, we don't try to change mailserver, and we don't
show a pop up to the user, as it is not that the mailserver is not
working, we are just offline.
Signed-off-by: Andrea Maria Piana <andrea.maria.piana@gmail.com>
If the initial request fails we immediately show the error pop-up. This
PR changes the behavior so that it is retried just like any other
request. If 3 requests in a row fail, we show the error pop up if the
user has specifically set a mailserver, otherwise is changed
automatically.
Signed-off-by: Igor Mandrigin <i@mandrigin.ru>
The denormalized-clock-value was erroneously set to the one of the last
message received. This meant that on chats were the clock-value raced
ahead of the timestamp (#status), a message from the mailserver or a
message from someone with an old clock-value would basically make those
messages be sorted in the past.
The correct behavior is that last-clock-value for a given chat should be
the maximum last clock value ever seen for that chat.
Signed-off-by: Andrea Maria Piana <andrea.maria.piana@gmail.com>
bddae03ab2
broke adding a user to contacts, this fixes by serializing the contact
before saving it.
Signed-off-by: Andrea Maria Piana <andrea.maria.piana@gmail.com>
This is a backward/forward compatible change with status-go.
We are changing the way messages are confirmed from passing the
raw-object to status-go to a dedup-id instead, which needs to be sent
back.
Based on the response from status-go we detect whether they are ids or
object and act accordingly.
Signed-off-by: Andrea Maria Piana <andrea.maria.piana@gmail.com>
We keep tokens synchronized across devices, so that the user can notify
us on any paired device.
Currently we record the installation id associated to the fcm-token even
though is not necessary, but it will be once we send device-to-device
messages, in which case we want to notify only those devices.
Signed-off-by: Andrea Maria Piana <andrea.maria.piana@gmail.com>
- screens definition is separated from configuration
(deduplicates screens which are used among several stacks)
- all four stacks moved to separate namespaces
- configuration is just a data
- remove usage of native checkboxes on android and desktop to ensure proper
design
- rename plain-checkbox to radio button and make sure it is only used where
radio button should be used (one possible choice beyond many)
- update autotest
Signed-off-by: yenda <eric@status.im>
Currently it's very easy for contact details to get out of sync, the
simplest example is:
A & B are contacts.
A changes name.
B receives the updated name.
B re-install the app.
Until A changes name again, B will not see their name, picture and won't
be able to send push notifications.
This PR changes the behavior to publish account informations to contacts
every 24 hrs, to add some redundancy in this cases.
It also publishes a contact code every 12hrs.
Signed-off-by: Andrea Maria Piana <andrea.maria.piana@gmail.com>
Before we checked filters are exactly the same as the chats.
If there's any state mismatch, this will result in not fetching messages
from the mailserver.
This might not be necessarily what we want, we probably want to be
resilient to this case.
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>
Currently we use a single topic for discovery.
This provides the best obscurity at the cost of bandwidth, as a message
sent on the discovery topic will be received by any peer.
This PR changes this behavior and start listening on a partitioned
topic.
Each pk will be hashed to a limited number of topics.
Everytime someone is in a conversation with someone from another topic
they will have to listen as well to avoid loosing obscurity, because we
only forward messages that we also advertise in the bloom filter.
The choice for the number of partitions depends on 2 factors:
1) The expected number of users using the network
2) The average number of contacts each user
Any change to the discovery topic will need to be split across 3
releases, to avoid breaking compatibility:
1) Listen to the new and old topic, publish to the old topic
2) Listen to the new and old topic, publish to the new topic
3) Listen to the new topic, publish to the new topic
This is step 1.
when the last used chat was a public chat, the public-key of
the recipient to populate the `:to` key in the notification data
was taken from `:current-chat-id`in app-db.
this fix ensures that the right chat-id (the actual public-key of
the contact) is used instead of current-chat-id by changing the arity
of `send-push-notification`
Signed-off-by: Igor Mandrigin <i@mandrigin.ru>
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>
StatusService was only used to handle `signalEvent:` from status-go.
This commit simplifies this interaction and getting rid of the service
and all the problems that come with it.
Signed-off-by: Igor Mandrigin <i@mandrigin.ru>
- 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>
current-account is duplicated in `:qr-modal` key when tapping on `share my
profile` button in the Profile screen
this removes the mnemonic from the duplicated data so that it does persist
there after user backed up his mnemonic
this was only happening until logging out/restarting the app
Signed-off-by: yenda <eric@status.im>
As per announcement, we need to switch our Infura project IDs.
> As previously announced, accessing Infura will begin requiring a Project ID generated from the new Infura Dashboard. If you are using Infura and have not yet migrated your project, please take the time to do so now. The first milestone in this transition will be activated next week on January 23, 2019 at 20:00 UTC.
https://blog.infura.io/infura-dashboard-transition-update-c670945a922a
The new project is created with ID `f315575765b14720b32382a61a89341a`
and the API keys are updated.
Signed-off-by: Igor Mandrigin <i@mandrigin.ru>
Seems like the current version of status-go does not contain some of the
code that was in the previous, so disabling this for now until we verify
it works.
Signed-off-by: Andrea Maria Piana <andrea.maria.piana@gmail.com>
Previously `:message/message-persisted` was dispatched for each incoming
message because its argument was not a vector. The event was renamed to
`:message/messages-persisted`.
10 last chats are loaded to `app-db` before showing `:home` screen, in
result a user will not see two consequent activity indicators. In this
case opening of `:home` screen is a bit slower but looks better from
UI/UX pov. As it is limited to 10 chats on initialization, the time
necessary for opening `:home` screen will not depend on a total number
of chats in `app-db` if an account contains 10+ chats.
Signed-off-by: Igor Mandrigin <i@mandrigin.ru>
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.
This commit moves group chats to their own topic, based on the randomly
generated chat-id. It falls back on the discovery topic for those peers
who we can't fingerprint the version, for backward compatibility.
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.
The bug was introduced in #7055.
`message-type` was stored and used instead of `content-type` which
caused incorrect displaying of the last message preview if the one was a
command.
This commit changes the way how keys are restored:
1. batch of `ssh.addSymKey` requests for all sym keys is sent at once
2. `:status-im.transport.core/sym-keys-added` event is dispatched with
results of all successful `ssh.addSymKey` calls
3. filter is created via `ssh.newMessageFilter`
4. `:shh.callback/filters-added` event is dispatched with all added
filters as a parameter
5. profit
In ideal case only 2 `re-frame` events are dispatched.
Paginating using the count of loaded messages might result in some
messages being skipped and not being loaded in the database, in case of
out-of-order messages received.
This commit changes the behavior to sort by `clock-value` and
`message-id`, which gives a consistent sorting.
The initial idea was to use a cursor `clock-value-message-id` and
iterate on that, but realm does not support filtering on string (</>),
so instead we keep track of messages with identical clock-value and
exclude those in the next page query.
The change might result in pages that have duplicates (so messages needs
to be deduped), but won't result in skipped messages.
In order to get `:last-clock-value` one extra query was executed for
each chat during initialization.
Implementation:
- `:last-clock-value` field was added to `chat` entity
- this field is updated when the message is sent/received
- extra query was removed
The crash was caused by RPC calls which happened after `StopNode` call.
Implementation:
- The first suggestion was to `StopNode` only after all `.stopWatching`
calls are done, but this only lowered probability of the crash,
but did not fix the issue.
- Another suggestion was to prevent RPC calls after `StopNode` call,
but it also only lowered probability of the crash.
- So the last resort was a fix on `status-go` side
https://github.com/status-im/status-go/pull/1329,
and it actually worked.
- Advanced settings are hidden until `Statusgo.Login` is finished
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>
Leftover after #7032. The node hasn't been started if the user entered a
wrong password, that's why `Statusgo.Verify` call has failed (it works
properly only with running node atm).
Implementation:
- the node is started with "dummy" configs if it's necessary to call
`Statusgo.Verify` method
- on `Statusgo.Verify` callback node is stopped so that it can be
started with proper configs on the next sign in attempt.
- signing in is disabled while the node is running
disable sign in while node is running
_
_
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>
The last messages of the chats are necessary to properly show the chat
list, which is shown right after signing in. Before this commit, the
last message was retrieved as one of 20 last messages fetched for each
chat.
Implementation:
- `:last-message-content` and `:last-message-type` fields were added to
`chat` entity
- both fields are updated when messages are received/sent
- loading of the last 20 messages for each chat was removed as
initialization step
This commit changes the way how/when the node is started/stopped:
1. `node` is not started on the app startup
2. When the user presses "Sign in" button the node is started
with user specific configs (`InstallationID`, custom bootnodes, etc),
and only after that `Login` call is performed.
3. When the user creates a new account, at first the node is started
with default params (the same as would be used when user signs into
the app after account creation whithout changing any setting), then
`CreateAccount` call happens, then `Login`.
4. When the user restores their account, the flow is the same as `3`
but with `RecoverAccount` instead of `CreateAccount`
5. When the user logs out the node is stopped. That's it.
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.
unread-messages-count fn, based off Maciej's comment on #6749
adding test, some difficulty running the test suite locally via clj
actually use the new functionality for displaying on desktop
first pass at updated styling for unread count chat icons
styling pass 2: finer attention to detail for the purple/blue icons
a bit more padding bloat to accomodate for the number 1, which occurs
frequently :)
remove counter from "home" icon on desktop
Signed-off-by: Vitaliy Vlasov <siphiuel@gmail.com>
Connection check should be skipped if the user has logged out, otherwise
`app-db` may end up in an invalid state which causes an error and red screen
in dev mode.
There is a tiny chance that without this fix some users which had message
duplicates because of issues with `message-id` calculation **BEFORE** `0.9.31`
still have duplicates in their DB and migrations will not pass without
this change. It only checks if the message with a new `message-id` has been
added and removes duplicate. The same way it removes duplicates from
`user-status` entity.
Currently, we calculate `message-id` as `sha3(from + raw_payload)`,
but we do not store `raw_payload` and it might be problematic
to restore it from DB because:
1) `content` field might be changed and so `Message` record
will differ from the original one
2) it is even more problematic for `GroupMembershipUpdate`
message because we don't save it in DB
In order to handle this, we can store `sha3(raw_payload)` as `raw-payload-hash`
prop of `message` entity and use it in case of emergency :)
`message-id` will be calculated as `sha3(from + sha3(raw_payload))`
Implementation:
1. `transport.utils/message-id` function is called only in three places now
and accepts `from` and `raw_payload` as parameters.
ID is calculated as `sha3(from + raw_payload)`.
2. This means that for wrapped private group chat message
the raw payload of `GroupMembershipUpdate` is used.
Issue was caused by https://github.com/status-im/status-react/pull/6722
Implementation:
1. `old-message-id` field (indexed) was introduced in `message` entity
and is calculated as `message-id` was calculated in `0.9.31`
```clojure
(defn old-message-id
[message]
(sha3 (pr-str message)))
```
2. When a reply message is sent from the PR version of app both `response-to`
and `response-to-v2` fields are sent as a part of `message`'s `content`
field, so that it can be recognized by `0.9.31`.
3. When PR version of app receives reply from `0.9.31` we check whether
message's `content` contains `response-to` but doesn't contain
`response-to-v2`, and if so we check whether DB contains message with
`old-message-id=response-to`. If such message has been found we assoc
`response-to-v2` to content.
4. If message from DB contains only `response-to` but not `response-to-v2`
attempt to fetch the message by `old-message-id` is done.
We add syncing of account fields in pairing messages (only photo-path &
name for now). Also a sync message is sent each time we send a
contact-update, to keep other devices in sync. The change is compatible
with previous clients as it's just an accretion of transit.
Signed-off-by: Andrea Maria Piana <andrea.maria.piana@gmail.com>
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.
Previously we were only checking whether `network-status` is equal to
`:offline`, therefore allowing the user to send messages even when no
peers are connected (i.e. the app is displaying Connecting to peers..).
Signed-off-by: Andrea Maria Piana <andrea.maria.piana@gmail.com>
Before we fetched ALL user-statuses with `status=received` (which means that
a message hasn't been seen), iterated them, grouped by chat and then stored
`message-ids` of these `user-statuses` in chat's `:unviewed-messages` key.
This commit introduces :unviewed-messages-count field in chat entity.
That means that there is no need to iterate `user-statuses` in order to count
a total number of unviewed messages, it is always stored along with chat.
In the rest of it, the difference is only that chat's db record should be
updated each time when unviewed messages are seen.
Go blocks parse try catch blocks and turn them into event
dispatches. This captures the original intent of the code to catch
errors and terminate the current async worker execution.
Signed-off-by: yenda <eric@status.im>
- aliased namespace keywords are used for local subs used for caching
- synthetic :chat namespace is used for subs used elsewhere
Signed-off-by: yenda <eric@status.im>
functions defined in subs need to be reusable and testable independently
from re-frame framework. they are moved into db namespace for that purpose
Signed-off-by: yenda <eric@status.im>
- in future PRs we want to reduce the expensive sort operations
on list of messages while keeping the possibility to get a message
by its ID
- priority map allow to keep a map sorted by it's value which
is what we want to do here. we want to keep the messages ordered
by clock-value
Signed-off-by: yenda <eric@status.im>
To simplify testing and debugging, there is a very simple sync indicator
(debug) for LES. This UI is not even close to being production and will
be reworked in the future.
Signed-off-by: Igor Mandrigin <i@mandrigin.ru>
Everytime a contact request is sent/confirmed a sync message is also
sent to other devices so the contact is kept in sync.
Signed-off-by: Andrea Maria Piana <andrea.maria.piana@gmail.com>
Adds ST token to list of available assets.
- Open Status
- Go to Manage Assets, add ST.
- You'll see that you can now add ST.
status: ready
Fixes#6624
Signed-off-by: Goran Jovic <goranjovic@gmail.com>
The initial purpose of the allowed keys macro was to only accept maps
with a defined set of keys so that the maps can be serialized into the db.
The way maps are serialized has been changed so that only the existing keys
in the db are cherry picked so passing maps with extra keys is no longer a
problem