It's difficult to find activity in a large friends list at odd hours when majority are inactive. My playtime today was spent clicking on the friends list, sending invite requests and joining on people that were asleep with their headset on. I logged out feeling like I had wasted my time. This problem is not new, and probably hasn't been for anyone with a decent friends list playing at odd hours.
I found one very brief suggestion in the canny about AFK detection from over a year ago, when the game was at a different state as it is today. I decided to write out a more detailed suggestion since I really think it could make a difference.
Borrowing concepts from Noise Gating, I suggest an automatic activity detection system. Add client side logging of voice/character movement, and tracked points translation/rotation delta over a time period. Start with conservative thresholds with a separate threshold for regaining activity, and a big bump to the timer when regaining activity to reduce repeated prompts. Adjust the sensitivity for tracked points with a power function such as t=t^1/2 making it more sensitive to minor activity the less active you are. This way setting the headset on the floor makes you inactive faster compared to ambient movement. Values for desktop users should be considered separately as they can't rely on tracked points, but have window focus, mouse movement, and push to talk. Run a test to record data into a spreadsheet and establish real world values, aiming to reduce false positives that would be disruptive to users while providing the most benefit to people browsing the friends list.
The client then toggles a single boolean flag once all tracked stats are considered AFK, which is sent to the server with some data which can be used to refine the thresholds. In the social panel inactive users are separated to a category, or otherwise visually indicated. Upon going inactive, the user gets a ZZZ icon in the corner, and can respond to a "are you still there?" notification in the menu which forces an active state for a moderate period and logs a false positive.
This system could help increase quality of life for many users, while having minimal performance and bandwidth cost, relatively small development time, and minimal false positives. Only part that isn't straightforward is adjusting the sensitivity. A simpler system like a screensaver timer polling the headset status would not work to solve the issues, and due to the trust system relying on user activity a separately tunable tailored system is needed to reduce the ability to use it to game the trust system. Most importantly the system as suggested could be consistent, allowing users to rely on it, assuming limited ability to override the functionality.