[WIP]: Fallback flow for pairing #20766
Conversation
Jenkins BuildsClick to see older builds (40)
|
cammellos
force-pushed
the
feature/fallback-pairing-seed
branch
4 times, most recently
from
fa92da3
to
49a7b20
Compare
cammellos
force-pushed
the
feature/fallback-pairing-seed
branch
3 times, most recently
from
29f62e5
to
451532f
Compare
Parveshdhull
force-pushed
the
feature/fallback-pairing-seed
branch
from
451532f
to
bd530c4
Compare
Parveshdhull
force-pushed
the
feature/fallback-pairing-seed
branch
from
0ccd21c
to
aa28678
Compare
|
Issues so far
I am working on these issues. CC @qfrank @churik UPD: pushing fix for last 2 issues in separate PR - #20883 |
Parveshdhull
changed the title
|
Marking the PR as draft for now, as its moved to next milestone |
|
On top of what @Parveshdhull shared above #20766 (comment) Given the circumstances and the tight schedule for 2.30 and available capacity for QA, we have decided that:
cc @qfrank |
yeah, v2.30 can parse QR generated by v2.29, but not the other way around. We may ignore the opposite use case, I mean ppl won't use v2.29 to scan the QR generated by v2.30 right?
so once status-go PR get merged, we actually won't support fallback flow for pairing for v2.30? according to this message, we will support it in v2.30.1 ? |
Edit: Further discussions with the desktop team led to a different decision. @cammellos will reach out to you @qfrank until Monday for more technical details. |
|
Hey @qfrank, can we close this PR for now given PR status-im/status-go#5614 won't require changes in clients once merged? |
I think so, we can reopen it later or create new one if needed |
This PR adds a fallback flow in case syncing does not work.
The flow is as follow:
Devices need to be connected to the internet for this to work, but don't need to be on the same network.
I have tested the happy path yesterday, and the two devices are paired correctly, there's some issues with the actual data being synchronized, but @qfrank will be looking into it, he will be taking over the status-go pr.
@xAlisher can share the design and flows.
Things left to do:
fire pair installation when generating a code, to facilitate correct discovery
When displaying a QR code from the sending device, it would be nice if we could call
SendPairInstallationRPC, so that metadata is available.Styling & translations
Styling and translations needs to be checked
Double modal
When/if the data confirmation modal is merged, there could be a clash of modals when logging in if the user of the receiving pair is on mobile network (i.e two modals opened at the same time), something to watch out for.
Testing
Please use this PR for both A1 & A2, as this is a breaking change 2.30 will only local pair with 2.30. Or you can use desktop if @jrainville has finished with his part.
Client A1 is logged in
Client A2 is logged out
key-uidfrom the QR code, A2 should callFinishPairingThroughSeedPhraseProcesswith the installation id passed in the QR code. This will send installation information over waku. The user should be shown its own installation id and prompted to check the other device.Enable and Sync, which should call theEnableAndSyncInstallationendpoint. This should finish the fallback syncing flow.Other areas of testing: Pairing flow when no error is returned.
Status-go pr: status-im/status-go#5567