[#7454] fix add basic copy to public chat empty screen state + chat messages-views intro screens for all chats
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>
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>
- 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.
