* onboarding sync devices after scan to sign in
* using subscription to get the status of pairing progress
* update following reviews
* polished code following reviews
* fixed showing unknown devices
This is the introductory work to support the new requirements for unfurling
URLs (while the message is a draft) and displaying link previews (after the
message is sent). Refer to the related status-go PR for a lot more interesting
details https://github.com/status-im/status-go/pull/3471.
Fixes https://github.com/status-im/status-mobile/issues/15469
### Notes
- The old link preview code will be removed separately, both in status-go and
status-mobile.
- I did the bulk of the work in status-go
https://github.com/status-im/status-go/pull/3471. If you want to understand
how this is all implemented, do check out the status-go PR because I heavily
documented the solution, rationale, next steps, etc.
### Performance
Does the feature perform well? Yes, there's very little overhead because
unfurling URLs happen in status-go and the event is debounced. I also payed
special attention to use a simple caching mechanism to avoid doing unnecessary
RPC requests to status-go if the URLs are cached in the client.
I have some ideas on how to improve performance further, but not in this PR
which is already screaming for reviews.
* Dont check app-state for android before routing PN
On Android devices, right after account creation and before a log out, the :app-state value in reframe db is set to background. The value becomes active after a log out and then log in which causes tapping on push notifications to do nothing.
This behaviour breaks E2E and hence in this PR, I remove the checking of this case only for Android platforms.
More work should be done to figure out why the app state event handler is behaving this way on Android but for now I would like to unblock E2E.
* e2e: remove xfailed tests
---------
Co-authored-by: Churikova Tetiana <tatiana@status.im>
* use debounce-and-dispatch to improve mention performance
* increase time to 400ms
* decrease time to 300ms
* update status-go-version.json
* update status-go-version.json
e8ceed11...213dc463
Both replies and pinned messages relied on subscribing their data from messages.
This worked only as long as we loaded the message in the database, so it would break say if another user replied to a message that wasn't in the current user view.
It also changes the way pinned messages are handled, before the notification was actually sent over the wire, but that's unnecessary, since it can be generated locally on both parts.
This is a bit of a breaking change with the previous version, since if you pin a message with this version, older version will not see a system message. this can be easily fixed by restoring the previous behavior of sending the message, but not sure it's worth it.
It also adds the ability to Delete message for everyone that have Deleted for me (discussed with John) and the ability of unpin messages that have been deleted for me.
This commit solves the problem described in detail in issue #15606, but in
essence, it fixes the clear icon by integrating rudimentary support for SVG
icons.
Fixes https://github.com/status-im/status-mobile/issues/15606
- Hopefully, if SVG icons prove to be a solid solution, we can easily and
progressively migrate PNG icons to SVGs, but for the moment, it was aligned
with @flexsurfer
https://github.com/status-im/status-mobile/issues/15606#issuecomment-1514631270
that we'll only use SVG icons on demand.
- Note that it's possible to import SVGs directly via js/require by installing
the library react-native-svg-transformer, but this approach is only good when
we don't want/need color customization, which is rarely the case with icons
where we want to change the foreground and/or background colors. I opted for
rendering the SVG icon as hiccup to support color customization.
- Since icons are fully memoized, the app's performance is on the same ballpark
as PNGs rendered with RN Image.
- It's possible to trim down SVGs by using a tool such as
https://github.com/svg/svgo, but this is obviously outside the scope of this
PR.
* fix: remove contact from mutual contact list after contact is blocked
* remove our contact from remote user contact list when contact is blocked
719af90f...9dea0aae
290579f7...44a0f5b7Fixes: #15290
This commit adds collapsing of categories.
It also adds ordering of chats/categories as it was previously ignored.
It also removes the communities/enabled? flag as it's not used anymore,
and communities should always be enabled.
- Display Activity Center unread badge with the unread counter.
- Use the new seen state stored in `status-go` to change the color of the
notification.
- Performance: split the `top-nav` component into left and right section
components and render the unread indicator in a separate component to not
trigger the re-render of the entire `top-nav` (as was before).
Fixes https://github.com/status-im/status-mobile/issues/14851
Demo: https://user-images.githubusercontent.com/46027/224299978-770dd5f1-302b-4375-af2b-3cd181ffdc9d.webm
Notes
=====
- Fix/improve: `quo/counter` displayed `NaN` to the user if the input value was
an empty string.
- In Figma, there's a border around the unread indicator. I didn't implement
this because the ideal solution IMO involves changing the `quo/counter`
component a little bit because the width of the component varies according to
the content displayed (1, 9, 99, 100, etc) and I wanted to the right thing in
a separate PR.
Design notes
============
There's an ongoing conversation with the Design team to decide what to do with
the gray indicator on top of the bell icon, since there's little contrast when
it's is in the `seen` state.
Platforms
=========
- Android
- iOS
Steps to test
=============
- Open Status
- Receive one or more notifications in the Home screen and check the unread
indicator is blue and has a counter.
- Open the AC and close it, notice the unread indicator is now in the `seen`
state. You can close the app and re-open and the state is persisted.
- Mark notifications as read/unread at will, check the unread counter is
correct.
Implements swipe actions for notifications with call to action (e.g. pending
contact requests, unverified identity verifications, etc).
Fixes https://github.com/status-im/status-mobile/issues/15118
According to the Design team, the goal is to deliver a consistent experience to
users, so whenever the user sees a notification with buttons, the same actions
can be taken via the swipe buttons.
Note: swipe buttons are using placeholder icons while the Design team works out
which ones to use
Additionally, a bunch of fixes:
- Fix: outgoing pending contact requests were not being removed from the UI when
cancelled.
- Fix: Membership tab not showing unread indicator.
- Fix: dismissed membership notification not marked as read.
- Fix: dismissed membership notification was displaying decline/accept buttons.
Regression came from changes in status-go related to soft deletion of
notifications.
- Fix: incorrect check for the pending state of a contact request.
- Fixed lots of bugs for identity verification notifications, as it was
completely broken. Unfortunately, somebody made lots of changes without
actually testing the flows.
- Add basic error handling and log if accepting, declining or canceling contact
requests fail.
The demo shows an identity verification with swipe actions to reply or decline.
[identity-verification-swipe-to-reply.webm](https://user-images.githubusercontent.com/46027/223565755-b2ca3f68-12e2-4e1e-9e52-edd52cfcc971.webm)
Out of scope: The old quo input is still in use in the identity verification
notification. This will eventually be solved by issue
https://github.com/status-im/status-mobile/issues/14364
### Steps to test
Notifications with one or more buttons (actions) are affected by this change,
because now the user can also swipe left/right to act on them.
- Membership notifications: private group chat. The following PR explains how to
generate them https://github.com/status-im/status-mobile/pull/14785
- Contact requests, and community gated requests to join (Admin tab).
- Identity verifications. I believe the only way to test identity verification
flows at the moment is to use the Desktop app, since initiating the challenge
is not implemented in Mobile yet.
- Mentions and replies don't have new swipe buttons because they don't have call
to action buttons throughout their lifecycle.
Steps to test identity verification flows:
#### Identity verification flow 1
- `A` and `B` are mutual contacts.
- `A` sends a verification request to `B`.
- `A` should not see any notification yet.
- `B` should receive an identity verification notification. `B` can either
decline or reply.
- `B` declines and the status `Declined` is shown instead of buttons.
- `B` can now either swipe to toggle read/unread or swipe delete the
notification.
- `A` should not receive any notification after `A` declined.
#### Identity verification flow 2
- `A` and `B` are mutual contacts.
- `A` sends a verification request to `B`.
- `A` should not see any notification yet.
- `B` should receive an identity verification notification. `B` can either
decline or reply.
- `B` press `Reply` and a bottom sheet is displayed with a text input.
- `B` sends the reply/answer message and the status `Replied` is shown instead
of buttons.
- `B` can now either swipe to toggle read/unread or swipe to delete the
notification.
- `A` should receive a notification with the reply from `B`.
- `A` can either mark the answer as untrustworthy or accept it (trust it) via
the normal buttons, as well as via the swipe left/right buttons.
- If `A` accepts the answer, then the status `Confirmed` is shown instead of
buttons. On the other hand, if `A` marks as untrustworthy, then the status
`Untrustworthy` is shown instead of buttons.
- `B` should receive no further notifications due to `A`s actions.
- `A` can now either swipe to toggle read/unread or swipe delete the
notification.
Fixes#15215. Redesign the app db state for the Activity Center. Please, see the issue being fixed for more details about the problems being solved.
TL;DR: There's a lot less state to keep track and reconcile and way less nesting in the app db because we're only managing the state of the *current tab*, not all tabs.
Additionally:
- [x] While updating unit tests, found a bug on the sorting notifications' logic.
- [x] While updating unit tests, found a bug where notifications that are not of the type *contact request* were being removed from the app db.
- [x] Fixed regression where pressing on a notification would not open the chat.
- [x] Hardened unit tests.
#### Platforms
- Android
- iOS
##### Non-functional
- Less memory consumption.
- Faster reconciliation of notification coming from signals and from synchronous responses from RPC calls.
Make the popover delay in milliseconds configurable.
To open the Activity Center, 30ms delay seems to be more than enough. It's a quick fix because the current 250ms to open the AC gives the wrong impression to users (and confuses even us developers) who think the AC has a performance issue to open.
See issue https://github.com/status-im/status-mobile/pull/15222 for the full discussion.
* nix: upgrade zprint from 1.2.4 to 1.2.5
To address issue described in:
https://github.com/kkinnear/zprint/issues/273
Signed-off-by: Jakub Sokołowski <jakub@status.im>
* chore: use zprint :multi-lhs-hang
* refactor: re-format clojure using zprint 1.2.5
---------
Signed-off-by: Jakub Sokołowski <jakub@status.im>
Co-authored-by: yqrashawn <namy.19@gmail.com>
Partially implements https://github.com/status-im/status-mobile/issues/14712Fixes#14744
### Summary
This PR implements the first, among what will probably be many different kinds of membership notifications. For this PR, I started with implementing a particular flow for private group chats because it's already supported by `status-go` (albeit I had to make some changes, see [PR in status-go](https://github.com/status-im/status-go/pull/3088).
1. `A` and `B` are mutual contacts.
2. `A` creates a private group chat with `B` as member.
3. `B` sees the group chat in the app, but doesn't interact with it.
4. `B` reinstalls the app (remember to back up the seed phrase).
5. `A` mentions `B` in the group chat.
6. `B` should see a group chat notification, which can be accepted/declined.
- [x] Also fixes#14744
### Demo
In the video I'm simulating the steps outlined in the *Summary*, but using the approach described in *Steps to test*, because it's way easier to iterate during development.
[demo.webm](https://user-images.githubusercontent.com/46027/212470798-c135d229-948d-4ba5-98db-ee73cc5495cd.webm)
### Review Notes
Some changes had to be made in `status-go` ([PR](https://github.com/status-im/status-go/pull/3088)), namely:
- According to [Figma](https://www.figma.com/file/eDfxTa9IoaCMUy5cLTp0ys/Shell-for-Mobile?node-id=3806%3A586901&t=xLTAjLXjG1UtorpI-0), users should be able to see `accepted` group chat notifications. Until now, `status-go` hardcoded that `accepted` notifications would *not* be returned in query results, and so it would be impossible to show them to users. This was changed and now the RPC endpoint accepts an additional filter. The implementation on the backend is backwards compatible so as to not break Status desktop.
- The `Membership` tab needs to display various types of notifications (group chat, community, etc), but the membership type doesn't exist on the backend. To overcome this constraint, this PR makes the membership type a logical/virtual type, i.e. a Clojure set of types. `status-go` was changed to support querying for multiple notification types (also backwards compatible).
#### Platforms
- Android
- iOS
### Steps to test
Please, follow the steps described in the Summary and you should be able to test.
But during development, I followed these steps (recommended by @cammellos). I documented them here for reference.
1. Checkout `feature/e2e` in status-go. Apply the diff below.
2. `cd cmd/e2e && ./e2e`
3. This will create a temporary account automatically, let's call it `A`.
4. On another device, create account `B`.
5. Follow the steps documented in bdc406ea2e/cmd/e2e/README.md (L2) in order for user `A` to create a group chat with `B` as member. Don't make `A` and `B` mutual contacts.
6. On `B`'s device, a notification should appear, and `B` should be able to accept or decline the "invitation" (actually *invitation* is another concept and related to another feature).
```diff
modified cmd/e2e/main.go
@@ -283,6 +283,11 @@ func defaultNodeConfig(installationID string) (*params.NodeConfig, error) {
nodeConfig.NetworkID = 1
nodeConfig.LogLevel = "ERROR"
nodeConfig.DataDir = "/ethereum/mainnet_rpc"
+ nodeConfig.HTTPEnabled = true
+ nodeConfig.HTTPPort = 8545
+ nodeConfig.HTTPHost = "localhost"
+ nodeConfig.HTTPVirtualHosts = []string{"localhost"}
+
nodeConfig.APIModules = "wakuext,ext,waku"
nodeConfig.UpstreamConfig = params.UpstreamRPCConfig{
modified protocol/messenger_group_chat.go
@@ -26,17 +26,17 @@ func (m *Messenger) validateAddedGroupMembers(members []string) error {
}
contact, _ := m.allContacts.Load(contactID)
- if contact == nil || !(contact.Added && contact.HasAddedUs) {
- return ErrGroupChatAddedContacts
- }
+ if contact == nil {
+ contact, err = buildContactFromPkString(contactID)
+ if err != nil {
+ return err
+ }
+ }
}
return nil
}
func (m *Messenger) CreateGroupChatWithMembers(ctx context.Context, name string, members []string) (*MessengerResponse, error) {
- if err := m.validateAddedGroupMembers(members); err != nil {
- return nil, err
- }
var response MessengerResponse
logger := m.logger.With(zap.String("site", "CreateGroupChatWithMembers"))
```
* [Fix][#14823] Admin Notification unread issue
* [Fix][#14823] Changed dispatch of event from the PR feedback
* [Fix][#14823] Organize dispatch of event from the PR feedback
* [Fix][#14823] Organize dispatch of event from the PR feedback
* we are now able to navigate to desktop communities
b4bdfd3d...d2e95eee
In this commit we add support for various status-go methods in mobile :
- `multiformatSerializePublicKey`
- `multiformatDeserializePublicKey`
- `compressPublicKey`
- `decompressPublicKey`
- and my personal favourite `deserializeAndCompressKey`
When someone pastes a community joining share url into chat and taps on it, we check whether the community was generated on a desktop or mobile.
We need to do this because currently both the clients have different urls for joining a community.
Once we have identified that the url is generated via desktop we then convert that url to something that the mobile client is used to.
This enables the mobile client to view this community and interact with it.
However more work needs to be done in the future to ensure that mobile implements these compressed keys end to end, we need to get this feature in so that
by the time RC1 is released mobile client is able to join communities created by Desktop.
* ui for local pairing
lint-fix
removed un-necessary +
addressing some of the feedback on PR
more feedback + removing feature toggle from ui
getting rid of comments/log messages over here
tidy up logs
fix typos and more i18n stuff
swap % with a named parameter
getting rid of global state + lint-fix
get rid of un-used function
icon guidelines and more kebab case stuff :>
moving stuff to events and utils namespace
:main-icons -> :i :)
address feedback and adhere to guidelines etc
fixed the :t/ qualification
moree feedback :-D
referring status-im.utils.security for now
adding "cs" to constants
make tests pass
re-frame to rf
addressing feedback
moving icons to icons2 & renaming stuff
trying to make this file the way it was before
missed out on updating these references
getting rid of the icons moved to icons2
This reverts commit be8552c0d3daaf7a7333cfeaf304d97c86d50d3e.
fixing mistakes
getting rid of the s
* this rename makes sense to me
* adding an alias to the view
* fixed broken up namespaces
flexsurfer
frank
andrey
John Ngei
Icaro Motta
Mohamed Javid
Siddarth Kumar
Alexander
Ajay Sivan
Parvesh Monu
Omar Basem
Ibrahem Khalil
Volodymyr Kozieiev
Andrea Maria Piana
Jamie Caprani
yqrashawn
Roman Volosovskyi
erikseppanen
Brian Sztamfater
Vitaliy Vlasov
Ulises Manuel Cárdenas
Jakub Sokołowski
Erik Seppanen
Christoph Pader
Ibrahem Khalil