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
_
_