Replace all the usage of the button without component
Use quo
Fix tests
List item in multiaccounts
Use list items in contacts
Fix welcome screen button
Experiment long press
Big list item
Remove old bottom sheet
Use bottom sheet
Keycard
Add error to list item
Stickers panel button
Images panel
Fix z-index in profile
Fix android crash
Fix signing list item
Try fixing test
iOs gas sheet keyboard
Disable root alert in e2e
keycard signing sheet height
Clean up bottom sheet events
Replace flat list in profile
Memorise the manual-close value for bottom sheet
Mailserver QR scanner
Fix e2e tests
E2e fix 2
Fix e2e 3
Remove extra fn
Reduce bridging time for animation
Trick android layout
Try hooks
Fix profile missing ens-name
Disable press on control in list-view
allow disabling animations in list item
Use simple list in wallet assets settings
TBD - this screen should be rewritten from scratch. Now on every interaction the full list is re-rendered, also it makes the wallet main screen to re-render.
Fix send sheet
Handle long press in main thread
UI fixes
perf
Update e2e
fix missing user name in image long press
Signed-off-by: Gheorghe Pinzaru <feross95@gmail.com>
This commit does a few things:
Move collections top level
Move `messages`,`message-lists`,`pagination-info` from nested in
`chats` to top level at the db.
The reason for this change is that if any of the `messages` fields
change, any `sub` that relies on `chat` will be recomputed, which is
unnecessary.
Move chat-name to events
`chat-name` was computed dynamically, while it is now only calculated
when loading chat the first time around.
Remove `enrich-chats`
Enrich chats was doing a lot of work, and many subscriptions were
relying on it.
Not all the computations were necessary, for example it would always
calculate the name of who invited the user to a group chat, regardless
of whether it was actually used in the view.
This commit changes that behavior so that we use smaller subscriptions
to calculate such fields.
In general we should move computations to events, if that's not
desirable (there are some cases where we might not want to do that), we
should have "bottom/leaf heavy" subscriptions as opposed to "top heavy",
especially if they are to be shared, so only when (and if) we load that
particular view, the subscription is triggered, while others can be
re-used.
I have compared performance with current release, and there's a
noticeable difference. Opening a chat is faster (messages are loaded
faster), and clicking on the home view on a chat is more responsing
(the animation on-press is much quicker).
Before we stored only the message-id and had a subscription pulling the
message from the database when replying to the message.
This broke once we implemented offloading of messages, as the message
might not be in the database anymore.
This commit fixes the issue by storing the full message in the database,
so in the event of it being offloaded it is still shown.
Signed-off-by: Andrea Maria Piana <andrea.maria.piana@gmail.com>
In some cases message confirmations might arrive out of order, before
status-go calls the callback for a sent message.
This commit changes the behavior so that confirmations out of order are
not ignored and they are checked when the callback for sending message
is called.
Signed-off-by: Andrea Maria Piana <andrea.maria.piana@gmail.com>
Add search for contacts
Add format name inside contact
Add back button on create group
Fix current contact name and alias
fixup
Update UI for group chat profile
Fix tests
Ui clean up
fix change group chat name
Add leave group chat option
Hide options if user has left the chat
Use modal for all required chat screens
Add dark mode to group chats
Fix offset 10 pt off screen on presentation modals
Wrap keyboard avoiding view with safe area offset
Keep only leave chat
Fix search input focus
Make edit name active when title not changed
Fix lint
review cleanup
QA review
Fix group chat inviter name
Fit flat list into container
Signed-off-by: Gheorghe Pinzaru <feross95@gmail.com>
Get rid of navigation wrapper
Use new API to declare navigation
Update tabbar component
Update to use new navigation events
Add ios presentation modal
Navigation cleanups
Android specific updates
Use letsubs for stack subscriptions
Keycard did load event backward compatibility
Fix tabbar and wallet on-focus bad rebase
Do not keep welcome screen into the stack
Comment outdated test
Fix rebase on home PR
Cancel back button on screens which can't be popped
Signed-off-by: Gheorghe Pinzaru <feross95@gmail.com>
This commit allows setting waku-mode and waku-bloom-filter-mode
dynamically.
It requires a relogin for the changes to take effect.
Signed-off-by: Andrea Maria Piana <andrea.maria.piana@gmail.com>
Add bottom sheet to message long press
Make whole bottom sheet panel dragable
Fixes #9846
Use spring animation for bottom size of bottom sheet
Remove extra border height from bottom sheet
The height is already added to content height
Remove extra set value for animation
Timing and spring already mutates the animation value
Reuse chat bottom sheet in chat list
Update the size of new chat bottom sheet
Add remove to group chat
add chat id for clear history to be reused outside of current chat
Fix public chat bottom sheet missing destructoring
Replace icon for chat fetch history
Could be rotated arrow up, but this requires special handling in icons or list item
Fix remove public chat event
Dismiss keyboard on sheet mount
iOs rename arrow down icon
Fix unusable screen after close of bottom shet
The callback is called after 1.5 seconds after the animation starts. This happens because spring animation takes more time on animating post animation oscillations.
Add accessibility labels
Fix bad message destructoring
add view profile on long message press
Reset bottom value after animation
Remove pending circle from avatar in chat sheets
Do not show open profile on own messages
Signed-off-by: Gheorghe Pinzaru <feross95@gmail.com>
This commit does a few things:
1) Messages are offloaded from any chat once we go back from the home.
This allows us to ignore any message that is coming in from a chat we
are not currently focused.
2) After 5 seconds of not-scrolling activity, any received message that
is not currently visible will be offloaded to the database.
3) Similarly received messages that are not visible will be offloaded to
the database directly
Signed-off-by: Andrea Maria Piana <andrea.maria.piana@gmail.com>
Handle ens-name in qr reader
If user has an username generate link with it
Ensure no infinite recursion happens on qr scan event
Fix test for custom profile ens-name
Fix QR code read for ens-name
Extra check for ens name in QR code
Do not open unknown profile for bad ens name
Signed-off-by: Gheorghe Pinzaru <feross95@gmail.com>
This commit completely remove transit for group chats. All the
processing is now done in status-go.
Also introuduces parsing and handling of mentions, needed so that system
messages can be easily built in status-go.
Signed-off-by: Andrea Maria Piana <andrea.maria.piana@gmail.com>
Account's address was used as a primary key in accounts db and as a
deterministic id of an account in some API calls. Also it was used as a
part of the name of the account specific database. This revealed some
extra information about the account and wasn't necessary.
At first the hash of the address was planned to be used as a
deterministic id, but we already have a keyUid which is calculated as
sha256 hash of account's public key and has similar properties:
- it is deterministic
- doesn't reveal accounts public key or address in plain
This commit moves all the processing of messages to status-go.
Messages are going arrive to status-react already saved an processed.
Receiving/sending/retrieving from db is now using the same identical
structure. The only processing left in status-react is to mark the
messages as seen and update the unviewed count locally (only
status-react knows whether the count should be updated).
Partially remove commands as well as won't be used anymore.
Signed-off-by: Andrea Maria Piana <andrea.maria.piana@gmail.com>
To make it work `encryption-public-key` and `whisper-private-key` are
stored on the devices when a user chooses this option. The former key is
used for multiaccount's database encryption, the latter is needed for a
messaging. In case if a user wants to sign a transaction the card is
still needed, we don't store wallet's keys on the device.
Other things were fixed/added:
- A user can enable biometric auth for a regular account when chooses
to save the password on the device (if biometric auth is available).
This is done for feature parity between keycard and "on device"
accounts.
- The option to create/restore an account on a keycard is not shown on
the devices which do not support NFC. Currently, the app just crashes
if the user continues a flow which is not supported by the device.
- if not mailserver was actively selected by user,
use rpc call to get latency for known mailservers
and use the best one
- this happens when `set-current-mailserver` is called which happens
in `change-mailserver` when user unpins his preferred mailserver and when
there's been too many failed attemps to fetch messages or to connect to
then current mailserverm as well as when user logs in.
Signed-off-by: yenda <eric@status.im>
Currently we have two ways to restore a multiaccount:
- by entering a mnemonic phrase
- by pairing a keycard with an existing multiaccount
In both cases, when we detect that a user tries to recover an existing
multiaccount we interrupt recovering and propose them to unlock that
multiaccount instead.
Fixes: https://github.com/status-im/trailofbits-audit/issues/47
Fixes: https://github.com/status-im/trailofbits-audit/issues/46
Fixes: https://github.com/status-im/trailofbits-audit/issues/44
Fixes: https://github.com/status-im/security-reports/issues/13
Fixes: https://github.com/status-im/security-reports/issues/5
Fixes: https://github.com/status-im/status-react/issues/8995
This commits re-introduce rendering of markdown text and implent a few
changes:
1) Parsing of the message content is now in status-go, this includes
markdown, line-count, and rtl. Parsing is not nested, as there's some
rendering degradation involved as we nest components, unclear exactly if
it's react-native or clojure, haven't looked too deeply into it.
2) Emojii type messages are not parsed on the sending side, not the
receiving one, using the appropriate content-type
3) Fixes a few issues with chat input rendering, currrently we use
`chats/current-chat` subscription which is very heavy and should not be
used unless necessary, and means that
any change to chat will trigger a re-render, which caused re-rendering
of input container on each received message. Also to note that
input-container is fairly heavy to render, and it's rendered twice at
each keypress on input.
The inline markdow supported is:
*italic* or _italic_
**bold** or __bold__
`inline code`
http://test.com links
\#status-tag
The block markdown supported is:
\# Headers
```
code blocks
```
> Quotereply
The styling is very basic at the moment, but can be improved.
Adding other markdown (photo,mentions) is straightforward and should
come at little performance cost (unless the component to render is
heavy, i.e a photo for example).
There are some behavioral changes with this commit:
1) Links are only parsed if starting with http:// or https://, meaning that
blah.com won't be parsed, nor www.test.com. This behavior is consistent
with discord for example and allows faster parsing at little expense to
ser experience imo. Fixes a few security issues as well.
2) Content is not anymore capped (regression), that's due to the fact that
before we only rendered text and react-native allowed us easily to limit
the number of lines, but adding markdown support means that this
strategy is not viable anymore. Performance of rendering don't see to be
very much impacted by this, I would re-introduce it if necessary, but
I'd rather do that in a separate PR.
Signed-off-by: Andrea Maria Piana <andrea.maria.piana@gmail.com>
This commit does a few things:
==== Ordering of messages ====
Change the ordering of messages from a mixture of timestamp/clock-value to use
only clock-value.
Datemarks are now not used for sorting anymore, which means that the
order of messages is always causally related (not the case before, as we
were breaking this property by sorting by datemark), but datemark
calculation is unreliable (a reply to a message might have a timestamp <
then the message that is replied to).
So for timestamp calculation we
naively group them ignoring "out-of-order timestamp" messages, although
there's much to improve.
It fixes an issue whereby the user would change their time and the
message will be displayed in the past, although it is still possible to
craft a message with a lower clock value and order it in the past
(there's no way we can prevent this to some extent, but there are ways
to mitigate, but outside the scope of this PR).
==== Performance of receiving messages ====
The app would freeze on pulling messages from a mailserver (100 or so).
This is due to the JS Thread being hogged by CPU calculation, coupled
with the fact that we always tried to process messages all in one go.
This strategy can't scale, and given x is big enough (200,300,1000) the
UI will freeze.
Instead, each message is now processed separately, and we leave a gap
between processing each message for the UI to respond to user input
(otherwise the app freezes again).
Pulling messages will be longer overall, but the app will be usuable
while this happen (albeit it might slow down).
Other strategies are possible (calculate off-db and do a big swap,
avoiding many re-renders etc), but this is the reccommended strategy by
re-frame author (Solving the CPU Hog problem), so sounds like a safe
base point.
The underlying data structure for holding messages was also changed, we
used an immutable Red and Black Tree, same as a sorted map for clojure, but we use
a js library as is twice as performing then clojure sorted map.
We also don't sort messages again each time we receive them O(nlogn), but we
insert them in order O(logn).
Other data structures considered but discarded:
1) Plain vector, but performance prepending/insertion in the middle
(both O(n)) were not great, as not really suited for these operations.
2) Linked list, appealing as append/prepend is O(1), while insertion is
O(n). This is probably acceptable as messages tend to come in order
(from the db, so adding N messages is O(n)), or the network (most of
them prepends, or close to the head), while mailserver would not follow this path.
An implementation of a linked list was built, which performed roughtly the
same as a clojure sorted-map (although faster append/prepend), but not
worth the complexity of having our own implementation.
3) Clojure sorted-map, probably the most versatile, performance were
acceptable, but nowhere near the javascript implementation we decided on
4) Priority map, much slower than a sorted map (twice as slow)
5) Mutable sorted map, js implementation, (bintrees), not explored this very much, but from
just a quick benchmark, performance were much worse that clojure
immutable sorted map
Given that each message is now processed separately, saving the chat /
messages is also debounced to avoid spamming status-go with network
requests. This is a temporary measure for now until that's done directly
in status-go, without having to ping-pong with status-react.
Next steps performance wise is to move stuff to status-go, parsing of
transit, validation, which is heavy, at which point we can re-consider
performance and how to handle messages.
Fixes also an issue with the last message in the chat, we were using the
last message in the chat list, which might not necessarely be the last
message the chat has seen, in case messages were not loaded and a more
recent message is the database (say you fetch historical messages for
1-to-1 A, you don't have any messages in 1-to-1 chat B loaded, you receive an
historical message for chat B, it sets it as last message).
Also use clj beans instead of js->clj for type conversion
Signed-off-by: Andrea Maria Piana <andrea.maria.piana@gmail.com>
