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>
- add validate method to StatusMessage protocol
- spec all message types for use in validate method
- use valid method after transit/decode step to reject
invalid messages
Signed-off-by: yenda <eric@status.im>
- get wnodes from resources/config/fleets.json which is taken from
fleets.status.im
- store wnodes by fleet and not by network since they are always the same
- reset wnodes settings during migration
- add option in developper menu to select fleet
- mailservers are now presented by their real name
Signed-off-by: Igor Mandrigin <i@mandrigin.ru>
reorganize config flags
remove offline-inbox-enabled? flag
remove universal-links-enabled flag
remove add-custom-mailservers-enabled? flag
remove spam-button-detection-enabled? flag
remove flags from config files
Signed-off-by: Eric Dvorsak <eric@dvorsak.fr>
simplified flow:
- event `:ui/login` is dispatched
- node is initialized with user config or default config
- `node.started` signal is received, applying `:login` fx
- `:callback/login` event is dispatched, account is changed
in datastore, web-data is cleared
- `:init/initialize-account` event is dispatched
replace event dispatches by function composition
fix bug in universal links where url to be processed after login
was never removed
Signed-off-by: Eric Dvorsak <eric@dvorsak.fr>
When creating a new account / recovery we don't poll the mailserver anymore for historic messages, which solves the immediate issue of fetching only received messages
Handle messages sent from a different device in public chat / restore history. The message will be added, shown correctly as sent by the user, and the status will be set as sent ( need to check for seen race condition, as messages will now be added twice). This means that multidevice should now work for public chats.
Move contact updates to discovery topic. This is necessary as there is a pre-existing bug whereby contact updates would not work anymore after wallet recovery, as the code relies on the initial contact request being stored on the mailserver, which we cannot guarantee (we only pull 7 days of data). Not pulling history anymore exacerbate the problems but does not introduce it.
To make sure that contact updates will work after wallet recovery, we also need to consider a ContactUpdate in the same way we consider a ContactRequest (the other peer has no idea that the user has recovered the wallet). This does not change any behaviour in terms of obscurity/security as ContactRequest are automatically processed (in both case the contact will be set as pending?, not as accepted)
At this stage ContactRequest, ContactRequestConfirmed, ContactUpdate have all the same logic, i.e. update the contact information, leave the pending flag alone.
Only 1 day of history is fetched for newly joined chats, if catching up 7 days is the cap as before.
Signed-off-by: Andrea Maria Piana <andrea.maria.piana@gmail.com>
This handles a bug whereby we'd run receive-whisper-messages
when the user is logged out.
I could not replicate locally, but a few issues are apparent from
just inspecting the code:
1) there are some race-conditions on logout as we don't wait for all
the filters to be removed. Changing this behaviour is non trivial and
not sure if we can actually handle this completely
(status-go-has-a-message->remove-filter->logout->status-go-deliver-message).
2) no error handling is made in receive-whisper-messages.
This PR defensively handles both cases.
Signed-off-by: Andrea Maria Piana <andrea.maria.piana@gmail.com>
- fix a bug in profile where app would was returning directly to profile
screen after photo capture, showing updating to user but not actually saving
and broadcasting it
- adds support for offline contact request, confirmation and updates by
leveraging the :sent and :not-sent signal from status-go. Each chat
in the protocol layer uses a `resend?` field to keep track of the current
state of the contact, between `nil`, `contact-request`,
`contact-request-confirmation` and `contact-update`. There is no case
were it can be more than one case because if `contact-request` or
`contact-request-confirmation` was not sent yet `contact-update` is not
necessary as the latest contact infos will be sent with the request/confirmation
Signed-off-by: Eric Dvorsak <eric@status.im>
message cache was initialized when logging-in so it was basically useless
it was causing a bug when switching account and getting a contact request
from the same user in 2 accounts without killing the app because the cache
was not reset and the subsequent contact requests were ignored
Signed-off-by: Julien Eluard <julien.eluard@gmail.com>
* Do not try to reconnect when offline
* If online, but mailserver is disconnected, show notification
* Tap on notification starts reconnecting process
Signed-off-by: Eric Dvorsak <eric@dvorsak.fr>
previous naming was confusing because it actually sends using
the symkey of each chat whose simkey is passed as an argument
Signed-off-by: Eric Dvorsak <eric@dvorsak.fr>
Andrea Maria Piana
yenda
Roman Volosovskyi
Andrey Shovkoplyas
Pedro Pombeiro
Igor Mandrigin
janherich
Eric Dvorsak
Connor Christie
Dmitry Novotochinov