Hi Bumble Team,
I’ve been using the on_authentication_user_confirmation_request method in device.py and noticed that some IO capability combinations currently result in na (not available) methods, which may be incomplete.
For example,
- when
peer_io_capability is KEYBOARD_ONLY and local_io_capability is DISPLAY_YES_NO, the method is currently marked as na, but based on the IO capability logic, it should be: display_number for the local device and passkey_entry for the remote device
Do you have any plans to implement these missing cases?
Additionally, I found a few combinations that seem to be incorrectly mapped:
For example,
- when both
peer_io_capability and local_io_capability are DISPLAY_ONLY, the method should be auto_confirm, not display_auto_confirm.
- when
peer_io_capability is NO_INPUT_NO_OUTPUT and local_io_capability is DISPLAY_ONLY, the method should also be auto_confirm, not confirm.
Could you please help verify these mappings and let me know if any updates are planned?
Thanks for your time and support!
Best Regards,
Can Wang
Hi Bumble Team,
I’ve been using the
on_authentication_user_confirmation_requestmethod indevice.pyand noticed that some IO capability combinations currently result inna(not available) methods, which may be incomplete.For example,
peer_io_capabilityisKEYBOARD_ONLYandlocal_io_capabilityisDISPLAY_YES_NO, the method is currently marked asna, but based on the IO capability logic, it should be:display_numberfor the local device andpasskey_entryfor the remote deviceDo you have any plans to implement these missing cases?
Additionally, I found a few combinations that seem to be incorrectly mapped:
For example,
peer_io_capabilityandlocal_io_capabilityareDISPLAY_ONLY, the method should beauto_confirm, notdisplay_auto_confirm.peer_io_capabilityisNO_INPUT_NO_OUTPUTandlocal_io_capabilityisDISPLAY_ONLY, the method should also beauto_confirm, notconfirm.Could you please help verify these mappings and let me know if any updates are planned?
Thanks for your time and support!
Best Regards,
Can Wang