Add section separator for logging-display
Refactor user-login-callback
Add comment to AppConfig class definition
Fix mobile compilation error
Use reference in AppConfig singleton; remove obsolete CMake directives
Styling changes
Disable status-go logs by default on desktop
Signed-off-by: Vitaliy Vlasov <siphiuel@gmail.com>
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
This commit changes the way how/when the node is started/stopped:
1. `node` is not started on the app startup
2. When the user presses "Sign in" button the node is started
with user specific configs (`InstallationID`, custom bootnodes, etc),
and only after that `Login` call is performed.
3. When the user creates a new account, at first the node is started
with default params (the same as would be used when user signs into
the app after account creation whithout changing any setting), then
`CreateAccount` call happens, then `Login`.
4. When the user restores their account, the flow is the same as `3`
but with `RecoverAccount` instead of `CreateAccount`
5. When the user logs out the node is stopped. That's it.
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.
There is no need to wait for `Statusgo.Login` callback in order to start
unlocking realm db: currently it is encrypted via a key which is derived
from user’s password, so we can try to unlock that DB before starting
node. That’s how password will be checked. Right after that `:home`
screen is shown, the node is started, then `Statusgo.Login` executed.
The difference in sign in duration is more noticeable on Android
devices, where `Statusgo.Login` is much slower because of PFS database
encryption.
unread-messages-count fn, based off Maciej's comment on #6749
adding test, some difficulty running the test suite locally via clj
actually use the new functionality for displaying on desktop
first pass at updated styling for unread count chat icons
styling pass 2: finer attention to detail for the purple/blue icons
a bit more padding bloat to accomodate for the number 1, which occurs
frequently :)
remove counter from "home" icon on desktop
Signed-off-by: Vitaliy Vlasov <siphiuel@gmail.com>
Connection check should be skipped if the user has logged out, otherwise
`app-db` may end up in an invalid state which causes an error and red screen
in dev mode.
There is a tiny chance that without this fix some users which had message
duplicates because of issues with `message-id` calculation **BEFORE** `0.9.31`
still have duplicates in their DB and migrations will not pass without
this change. It only checks if the message with a new `message-id` has been
added and removes duplicate. The same way it removes duplicates from
`user-status` entity.
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.
