NOTE: This could be a terrible idea if implemented badly... but you just don't know how many others might think it could be useful to them unless you share, so here goes...
Prerequisite communication
This feature requests proposes that Authenticator Pro could run in the background and listen for some kind of incoming external communication. This would likely need to come via the Internet somehow, possibly in the form of a Google or Apple push notification sent by an external 3rd party source (silently processed by Authenticator Pro directly, so not shown to the user as a regular notification). I'm not massively a fan of Google/Apple involvement, but I'm struggling to think of anything that would be quite as ubiquitous, in terms of an intermediate to relay the information from the external 3rd party source and Authenticator Pro.
Prerequisite Security
The user would need to explicitly opt-in and tell Authenticator Pro to trust that particular external communication source, and the data received should solely be a single correctly formatted ID number. If it contains anything else, then the data received should be immediately rejected. That ID number would correspond to an entry that is inside of whichever database you've set Authenticator Pro to open by default. If someone were to spy on this external communication, the ID number should be practically useless to them as it's only useful if you've got access to the correct (and open) Authenticator Pro database, to even remotely know what it corresponds to. Additionally no information needs to be sent back, this is strictly one way communication.
If you're uncomfortable with Authenticator Pro receiving a remote request (no matter how much opt-in there might be)... then we could instead have a separate service application that you'd need to explicitly install alongside. That service application could then (either directly or via Authenticator Pro) read the TOTP code and generate the local system notification. A separate application might also be needed anyway if it used proprietary libraries or services from Google or Apple to receive this external data, so it doesn't contaminate the code of the main Authenticator Pro application (e.g. the F-Droid version), in terms of licensing.
Feature
Authenticator Pro would take the ID number... self-unlock the default database... lookup the current TOTP code for the entry that corresponds to that ID... locally generate a system notification to show that TOTP to the user... and immediately re-lock the database.
What would use this?
The main thing I'm thinking of that could generate these incoming external requests is password managers, whether they're running on your desktop or cloud based.
Imagine you're using a password manager on your desktop (e.g. KeePassXC) and you're someone that believes you shouldn't put your passwords and TOTP seeds in to the same application, database, or access them on the same device. I'm in two minds about this philosophy, but I accept that a great many people hold this opinion.
This new feature would mean, that just after your password manager sends a password to something (e.g. via auto-type or a browser extension) it could tell Authenticator Pro to locally generate a TOTP code and show it to you automatically. You'd then type it in manually as normal, without having to do up to 5 of the following steps...
unlocking your phone (but you might want to do this anyway to see a notification, so this is user choice)
open Authenticator Pro
unlock the database (if you've enabled password or biometric locking)
scroll down or search to see the correct entry (and hope you read the right one)
close Authenticator Pro
Really!?
You might think this is a trivial ease of use thing. But I do think that a lot of people give up on the idea of using a separate device for TOTP because of the hassle of having to find the right code in a long list. Especially if you've got hundreds of TOTP seeds programmed in, and some of them have very similar logos or names, particularly for multiple accounts of the same service.
This behaviour would also mimic the kind of behaviour that is seen when logging into crappy websites (e.g. Apple) that insist on sending a 2FA code via SMS. Whilst SMS has many downsides (too long to go in to)... the only upside is that the user doesn't need to do anything to find that code, other than to glance at their smart phone or watch (optionally unlocking it if they've told their device OS that it's required to see notifications).
Other projects would need to join in
If there is an appetite for this feature... then the next challenge would be convincing something like KeePassXC (or any other password manager) to send these requests!
I do think that however this external communication is received (with the ID number to lookup) it perhaps be as agnostic as possible. So that it'll work no matter what mobile OS, password manager, or TOTP generating app you use.
So different password managers (and not necessarily KeePass-related ones too) can send these communications out... and any number of different TOTP-generating apps could receive them.
NOTE: This could be a terrible idea if implemented badly... but you just don't know how many others might think it could be useful to them unless you share, so here goes...
Prerequisite communication
This feature requests proposes that Authenticator Pro could run in the background and listen for some kind of incoming external communication. This would likely need to come via the Internet somehow, possibly in the form of a Google or Apple push notification sent by an external 3rd party source (silently processed by Authenticator Pro directly, so not shown to the user as a regular notification). I'm not massively a fan of Google/Apple involvement, but I'm struggling to think of anything that would be quite as ubiquitous, in terms of an intermediate to relay the information from the external 3rd party source and Authenticator Pro.
Prerequisite Security
The user would need to explicitly opt-in and tell Authenticator Pro to trust that particular external communication source, and the data received should solely be a single correctly formatted ID number. If it contains anything else, then the data received should be immediately rejected. That ID number would correspond to an entry that is inside of whichever database you've set Authenticator Pro to open by default. If someone were to spy on this external communication, the ID number should be practically useless to them as it's only useful if you've got access to the correct (and open) Authenticator Pro database, to even remotely know what it corresponds to. Additionally no information needs to be sent back, this is strictly one way communication.
If you're uncomfortable with Authenticator Pro receiving a remote request (no matter how much opt-in there might be)... then we could instead have a separate service application that you'd need to explicitly install alongside. That service application could then (either directly or via Authenticator Pro) read the TOTP code and generate the local system notification. A separate application might also be needed anyway if it used proprietary libraries or services from Google or Apple to receive this external data, so it doesn't contaminate the code of the main Authenticator Pro application (e.g. the F-Droid version), in terms of licensing.
Feature
Authenticator Pro would take the ID number... self-unlock the default database... lookup the current TOTP code for the entry that corresponds to that ID... locally generate a system notification to show that TOTP to the user... and immediately re-lock the database.
What would use this?
The main thing I'm thinking of that could generate these incoming external requests is password managers, whether they're running on your desktop or cloud based.
Imagine you're using a password manager on your desktop (e.g. KeePassXC) and you're someone that believes you shouldn't put your passwords and TOTP seeds in to the same application, database, or access them on the same device. I'm in two minds about this philosophy, but I accept that a great many people hold this opinion.
This new feature would mean, that just after your password manager sends a password to something (e.g. via auto-type or a browser extension) it could tell Authenticator Pro to locally generate a TOTP code and show it to you automatically. You'd then type it in manually as normal, without having to do up to 5 of the following steps...
Really!?
You might think this is a trivial ease of use thing. But I do think that a lot of people give up on the idea of using a separate device for TOTP because of the hassle of having to find the right code in a long list. Especially if you've got hundreds of TOTP seeds programmed in, and some of them have very similar logos or names, particularly for multiple accounts of the same service.
This behaviour would also mimic the kind of behaviour that is seen when logging into crappy websites (e.g. Apple) that insist on sending a 2FA code via SMS. Whilst SMS has many downsides (too long to go in to)... the only upside is that the user doesn't need to do anything to find that code, other than to glance at their smart phone or watch (optionally unlocking it if they've told their device OS that it's required to see notifications).
Other projects would need to join in
If there is an appetite for this feature... then the next challenge would be convincing something like KeePassXC (or any other password manager) to send these requests!
I do think that however this external communication is received (with the ID number to lookup) it perhaps be as agnostic as possible. So that it'll work no matter what mobile OS, password manager, or TOTP generating app you use.
So different password managers (and not necessarily KeePass-related ones too) can send these communications out... and any number of different TOTP-generating apps could receive them.