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.
yenda
Andrea Maria Piana
Andrea Franz
Roman Volosovskyi
Andrey Shovkoplyas
Goran Jovic
Dmitry Novotochinov
Vitaliy Vlasov
Igor Mandrigin
Brandon Wissmann
Julien Eluard
Pedro Pombeiro
shamardy
mestorlx
tbenr
kn
Asad Dhamani