You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
a once published QR code (business cards, web) should work in a multi-device-setup if any of the devices are online.
this has at least two issues:
the INVITENUMBER is transferred only on backup export/import to other devices
if the INVITENUMBER is shared, Bob must be prepared to handle two or more Alices at the same time, i doubt, this is working (Alice shows QR code, Bob scans QR code) EDIT: after a/v with @flub it seems there are good chances that this aspect works. adding a test seems reasonable, however.
scanning QR code group-invites are blocking and make the device unusable until the protocol is finished. this is very annoying as this may take several minutes (bad network, greylisting).
also, Bob's state is kept in RAM, so a prgram restart (may easily happen on iOS) would abort any progress.
it should be possible to revoke one published QR codes - and maybe also to re-active them
actionable items/ideas:
allow multiple states of Bob and persist them in a database until the protocol is finished (maybe also cleanup after some time) (Alice can already handle several Bobs scanning at the same time, so changes affect Bob only).
this idea lives on in a separate issue at Allow multiple BobStates #2777
dc_join_securejoin() should always return immediately a chat_id and the protocol should always run in background - currently, this happens for 1:1 secure joins only, not for groups.
however, for groups, we can create a "dummy" group, where we can also add the progress. the dummy group already has a name and we can add progress information using add_info_msg(). member list, avatar and protection state is added to the group once the protocol is finished.
as the dummy group does not have SELF as member, most things should already be blocked.
to target 3 and also 1.i., the idea is that on scanning the own QR code, one is asked if one wants to revoke it. if so, the corresponding INVITENUMBER is removed from the database. same way, once revoked QR codes can be reactivated.
1.i. should be improved further by a self-sent message that contains the INVITENUMBER, so that multi-device QR handlng works without further actions needed.
The text was updated successfully, but these errors were encountered:
AEAP requires some tweaks for QR code handling:
a once published QR code (business cards, web) should work in a multi-device-setup if any of the devices are online.
this has at least two issues:
the INVITENUMBER is transferred only on backup export/import to other devices
if the INVITENUMBER is shared, Bob must be prepared to handle two or more Alices at the same time, i doubt, this is working (Alice shows QR code, Bob scans QR code) EDIT: after a/v with @flub it seems there are good chances that this aspect works. adding a test seems reasonable, however.
scanning QR code group-invites are blocking and make the device unusable until the protocol is finished. this is very annoying as this may take several minutes (bad network, greylisting).
also, Bob's state is kept in RAM, so a prgram restart (may easily happen on iOS) would abort any progress.
it should be possible to revoke one published QR codes - and maybe also to re-active them
actionable items/ideas:
allow multiple states of Bob and persist them in a database until the protocol is finished (maybe also cleanup after some time) (Alice can already handle several Bobs scanning at the same time, so changes affect Bob only).
this idea lives on in a separate issue at Allow multiple BobStates #2777
dc_join_securejoin()
should always return immediately a chat_id and the protocol should always run in background - currently, this happens for 1:1 secure joins only, not for groups.however, for groups, we can create a "dummy" group, where we can also add the progress. the dummy group already has a name and we can add progress information using
add_info_msg()
. member list, avatar and protection state is added to the group once the protocol is finished.as the dummy group does not have SELF as member, most things should already be blocked.
to target 3 and also 1.i., the idea is that on scanning the own QR code, one is asked if one wants to revoke it. if so, the corresponding INVITENUMBER is removed from the database. same way, once revoked QR codes can be reactivated.
1.i. should be improved further by a self-sent message that contains the INVITENUMBER, so that multi-device QR handlng works without further actions needed.
The text was updated successfully, but these errors were encountered: