I don't know of a way to correctly trace a user's reply back to the time it was sent without being vulnerable to cheating.
(eg. a cheater deliberately sends all their replies 100 ms later than normal so the server thinks their latency is realLatency + 100ms
. Then when they send their answer without this extra delay, the server back-dates it to realAnswerTime - 100ms
, letting them effectively send answers "back in time" to beat other users).
Instead, I'd recommend solving this problem with game design:
Take the maximum variance in communication latency you're willing to accept between players in one match. (ie. the maximum latency you consider playable, minus the minimum latency you expect to see) We'll use this number as a tuning parameter you can choose to make a wider or narrower window of opportunity for rival answers.
When an answer comes in, wait for that maximum allowed duration to see if other answers also arrive in that window.
If multiple correct answers come in within that window, call it a tie. You can decide whether a tie means multiple players win, or nobody wins, or the players split the victory in some way.
This window can still be quite short in terms of human perception of time (even fairly bad one-trip network latencies are on par with an eye blink) so most rounds should still have a decisive winner. And crediting multiple players with a tie is generally going to be preferable, in terms of perceived fairness, to crediting the wrong player with a win due to variability or manipulation of network timings.
Here's a few examples, assuming our window is a generous 200 ms.
First, anekix's scenario: (values in ms)
Player Latency Answer Time Arrival Time Vs Window
-----------------------------------------------------------------------
Player A 50 5000 5050 First (5050 + 200 = 5250)
Player B 100 7000 7100 Too Late (7100 > 5250)
Player C 50 8000 8050 Too Late (8050 > 5250)
Here, player A's correct answer came in way before the others, at 5050 ms. We hold the window of opportunity open for an extra 200 ms after this correct answer, but both the other player's answers arrive later than that window. So Player A takes a solo victory. Which makes sense - they were first by a margin we couldn't confuse with mere network latency.
Here's a tighter scenario:
Player Latency Answer Time Arrival Time Vs Window
-----------------------------------------------------------------------
Player A 50 5000 5050 First (5050 + 200 = 5250)
Player B 100 4960 5060 In Window (5160 < 5250)
Player C 50 5300 5350 Too Late (5350 > 5250)
Here, Player B actually answered first, but because they're on a higher-latency connection, we received Player A's answer sooner. Because the window of opportunity we chose is larger than the difference between the most and least-lagged player's latencies (200 > 100 - 50), we don't hand a solo win to Player A incorrectly. Instead, we deem the 10 ms difference in arrival times as "too close to call" and we say that player A and player B tied. Player C's answer arrived outside the window though, so they still lose the round.
For conditions where you expect players to be on very different network conditions, you'll want to allow a larger window. For conditions where you expect players to be more similar (eg. in the same room as with a Jackbox Party Pack game, or a group assembled by matchmaking that only pairs players with similar pings), you can use a smaller window to have fewer ties and more timinig precision for identifying solo winners.
You can playtest with a range of tuning values and play conditions to find the level that gives you the right perceived fairness.