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.
Roman Volosovskyi
Andrey Shovkoplyas
Julien Eluard
Andrea Maria Piana
Goran Jovic
yenda
Speedy Fixer
Serhy
Dmitry Novotochinov
tbenr
Andrea Franz
Vitaliy Vlasov
Igor Mandrigin
Brandon Wissmann
Pedro Pombeiro
shamardy
mestorlx
kn
Asad Dhamani
Zach Zundel
Volodymyr Kozieiev
Rob Culliton
Tom Nash