Feature Request: Visual indicator for Attended vs. Unattended (Automated) station states

[m-a-r-k-d]

Is your feature request related to a problem? Please describe.

Currently, there is no structural way in JS8Call to distinguish between an attended keyboard-to-keyboard operator and an unattended station operating as an automated relay node.

Because HB (Heartbeat) and CQ queries elicit automated background acknowledgments (HB ACK), a local station's physical presence cannot be verified without initiating a manual free-text chat. This often results in a high volume of missed connections when attempting live, conversational QSOs.

Describe the solution you'd like

I would like to propose a UI/protocol indicator that flags whether a station is actively being operated by a human or running completely in automated mode. This could be achieved by:

1. An "Attended Mode" Toggle Flag: A simple checkbox or status toggle in the main UI window. When checked (Attended), any outbound CQ or directed beacon appends a structural state marker or symbol to the message packet.
2. Automated Status Column Tracking: Expanding the Band Activity or Heard List to parse the user's IDLE state time automatically. If a station hasn't had local keyboard inputs for X minutes, their callsign tag could dynamically shift color (e.g., Green for active, Amber/Grey for unattended/automated auto-reply mode).

Describe alternatives you've considered

Currently, operators have to manually type directed STATUS? or INFO? queries to guess if an operator is sitting at the keyboard based on the idle macro response. This adds unnecessary RF traffic to an already congested waterfall slot.

Additional context

Providing a native way to quickly screen for keyboard-to-keyboard capability would greatly enhance real-time networking and minimize frustration for users searching for active dialogue on the bands.

[ghost]

I understand your point, but frankly, that is what "CQ" is for -- to elicit a response from those willing to reply in real time. Otherwise, using the MSG message-storage capability allows traffic if no one is willing or able to communicate real-time.

73,
-Joe-
K0OG

[Chris-AC9KH]

This one is quite difficult. My station is running unattended about 90% of the time and yet I still handle quite a bit of MSG traffic and relays when running unattended. I typically turn off HB ACK when running unattended. But there's some stations that use @ALLCALL QEURY CALL <THEIR CALLSIGN>? that elicits a response from my unattended station. And then somebody will drop a MSG in my Inbox or query my station for HEARING? and use it for relay. And they know full well I'm not there, but it doesn't make any difference.

[Chris-AC9KH]

I moved this to the Discussion category under Ideas. Anything like this would require a considerable amount of scheming and ideas (that are practical) on how to implement such a thing. It is not really a "bug" or issue that we can do anything with until a concrete plan is laid for it.