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>
- 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>
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>
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>
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>
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.
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 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
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.
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.
Before we fetched ALL user-statuses with `status=received` (which means that
a message hasn't been seen), iterated them, grouped by chat and then stored
`message-ids` of these `user-statuses` in chat's `:unviewed-messages` key.
This commit introduces :unviewed-messages-count field in chat entity.
That means that there is no need to iterate `user-statuses` in order to count
a total number of unviewed messages, it is always stored along with chat.
In the rest of it, the difference is only that chat's db record should be
updated each time when unviewed messages are seen.
- aliased namespace keywords are used for local subs used for caching
- synthetic :chat namespace is used for subs used elsewhere
Signed-off-by: yenda <eric@status.im>
functions defined in subs need to be reusable and testable independently
from re-frame framework. they are moved into db namespace for that purpose
Signed-off-by: yenda <eric@status.im>
- in future PRs we want to reduce the expensive sort operations
on list of messages while keeping the possibility to get a message
by its ID
- priority map allow to keep a map sorted by it's value which
is what we want to do here. we want to keep the messages ordered
by clock-value
Signed-off-by: yenda <eric@status.im>
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>
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>
- chat name is not updated with contact name
- when a contact adds the user and is added back by user, the name
of the chat is still the random name of the contact
- in active-chats subscriptions, replace the name of the chat by the current
name of the contact
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>
* Set custom sound
* Tap on notification opens chat
* Show message notifications when app in foreground
Signed-off-by: Dmitry Novotochinov <dmitry.novot@gmail.com>
Fetch transactions state from etherscan every 15 seconds
if there are any unconfirmed transactions
Signed-off-by: Dmitry Novotochinov <dmitry.novot@gmail.com>
Label component located inside `status-im.ui.components.react`
namespace, called i18n-text. It replaces the need for the standard way
of creating labels using both `react/text` and `i18n/label`.
Signed-off-by: Goran Jovic <goranjovic@gmail.com>
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>
Andrey Shovkoplyas
Andrea Maria Piana
Vitaliy Vlasov
yenda
Igor Mandrigin
Andrea Franz
Roman Volosovskyi
Pedro Pombeiro
Julien Eluard
tbenr
Goran Jovic
Bruce Hauman
Aleksandr Pantiukhov
Dmitry Novotochinov
janherich
Max Risuhin
lokalise-bot
Chad
Eric Dvorsak
Dmitry Novotochinov
yevh-berdnyk
deme
Cheuk Yin Ng