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>
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>
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>
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.
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.
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
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>
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>
- do not logout and remove previous mailserver
from peers when changing mailserver
- rename wnode mailserver
- move transport.inbox to mailserver.core
- fix all subs and db keys
Signed-off-by: yenda <eric@status.im>
Adds a `chat-id` field in `content` map.
The reason it has been added to the map instead of augmenting transit is
that it would simplify the calculation of `message-id`, which in this
case is consistent for both old & new clients.
`chat-id` also represents the `chat-id` with respect of the sender, as
in 1-to-1 chats that is asymmetric.
Signed-off-by: Andrea Maria Piana <andrea.maria.piana@gmail.com>
- 1-1 chats don't have a topic anymore because they only use the
discovery topic so topic is nil for these chat
- this was causing an error when initializing whisper because the app
was trying to start a filter for each of the chat including the 1-1 with
no topic
- we now filter the transport/chats to only recover sym-key and start filter
for those with a topic
- group requests by last-request to request multiple topic at once
- fix bug where fetching popup was shown when the app was actually in error
state
Signed-off-by: yenda <eric@status.im>
- fetch 7 days of history when joining a chat
- make 7 24h requests to request 7 days because mailservers
ignores requests for a timespan > 24h
- make requests sequentially to avoid timeouts
- change mailserver after 3 timeouts on a request
Signed-off-by: yenda <eric@status.im>
