[partdavid]

Can you say more about which prior art you think overlaps here? We have a similar use case to Figma and are implementing a similar solution. I'm not particularly concerned whether the path we're following is novel but I am particularly concerned with whether there are gotchas along it that we should be watching out for, so if there are more mature solutions, we'd be interested.

[andrewmcwatters]

Read QuakeWorld 1999, client-server prediction, Counter-Strike: Source lag compensation.

See also, “reconciliation.”

Also, debatably the article hints towards an incorrect implementation because they specifically mention sending events instead of user input.

By design, if you do this, you can create events that are supposed to eventually stop, but the user may drop packets and disconnect all the while you were processing an event that was never supposed to occur.

If you poll user input and experience loss, there’s no event to misfire.

This behavior manifests itself in games as a player that continues to walk forward despite having lost their connection to a server and is a indicator that a multiplayer server was implemented incorrectly.

[Rohansi]

Multiplayer video games are the big one. There's no reason why you couldn't apply the same kind of synchronization to a web app. You'll just need to decide on an approach because not all games do it the same way. Most likely you'd want rollback netcode.

[mweidner]

Indeed, Replicache works this way, using server reconciliation (one part of client-side prediction): https://doc.replicache.dev/concepts/how-it-works