I have read Gambetta, Gaffer, and Valve's writing on game networking and have implemented a basic platformer using FSMs to control character behavior. In offline mode, inputs/collisions are sent to the FSM, which correctly sets the animation according to the state. In online mode, the client receives only positional updates and the FSMs aren't used. I figure I can add the current state to the updates, but am unclear on how to interpolate between 2 different states and how to time my animations. For example, consider an authoritative server simulating at 60Hz and sending updates every 6 ticks (10Hz). Assume my jumping animation takes 6 frames @ 60Hz.

tick    |input|State  |y	|offline anim frame|  client anim frame
-------------------------------------------------------------------
0 (sync)|     |idle   |0	|       idle       |  idle
1       |jump |jumping|1	|       jump1      |  ?
2       |     |jumping|2	|       jump2      |  ?
3       |     |jumping|3	|       jump3      |  ?
4       |     |jumping|4	|       jump4      |  ?
5       |     |jumping|5	|       jump5      |  ?
6 (sync)|     |jumping|6	|       jump6      |  ?

When the client receives the update for server tick 6, its 2 most recent states are {t: 0, y: 0, state: idle} and {t: 6, y: 6, state: jumping}. The y position is easy to lerp, but how do I interpolate the state/animations? Do I instead need to send a list of state changes w/ timestamps on each updates? That sounds kind of heavy.

Alternatively, I could send inputs with timestamps directly to all clients and let the clients simulate on their own (instead of interpolation). This seems like it would be the most accurate, but I've never heard of anybody doing it that way before. Positional interpolation seems to common practice.

Generally, you will just say “changed to state X at step number Y” and call it good. For the “jump” animation, because the movement replication and the FSM replication happens with the same step numbers, It'll still sync up. (Unless you extrapolate, in which case any user action will cause “jumps” – that's the problem of extrapolating user actions.)

Sending client inputs to other clients, is totally a thing people do – it's the core of “deterministic simulation” and is the ONLY thing done in the “lockstep determinism” model of networking. For FPS style games, the latency involved is generally not desirable, and thus extrapolation and/or server rewind is used instead, but it's totally a thing that can work. As long as it's OK to show other players “behind time” (or extrapolate them based on old state and keep re-simulating,) you can totally do this.