How do you handle hidden information, or "need to know"/"potentially visible set" style revelations to player clients?
Unfortunately, this is not compatible with the rollback netcode model. However, all the world state is stored in WASM linear memory and so it is not the most straightforward to decode.
The rollback netcode model is necessary to make the multiplayer invisible to the developer. The other client-server/state-synchronization approach which is used in other multiplayer games, while great in many ways, requires you to assign authorities to every entity and to send a remote procedure call when attempting to affect entities you do not control. Rollback netcode was the only way for me to achieve the primary mission.
I may look into supporting the client-server/state-synchronization multiplayer model in the future though, which would enable "need to know" style revelations. Given we already have a deterministic programming language it is not at all infeasible as a future project.
From my experience running a multiplayer game, I only had 1 in every 50000 players attempt to perform some kind of hack and it was faster and more reliable for me to shadow IP ban the players. That feature is built into Easel. There is also a replays system built-in which makes it easy for people to submit evidence of people hacking. This is the current pragmatic solution that I suggest.
> requires you to assign authorities to every entity and to send a remote procedure call when attempting to affect entities you do not control.
You can consider every object to be server authoritative and then only send inputs from the client to the server. Other clients don't need to know about other client inputs. They only need to see state changes from the server. Clients functionally only have authority over their own input. This is a simple model of state synchronization that doesn't have the extra complexity of having authority over random objects. In this model, you only do a rollback if the server state differs from your predicted representation of the state. Besides, your game tick should be fast enough that you can rollback and resimulate every frame multiple times anyways.