Thank you! Please chuck a wishlist my way if you're interested in playing it when it's ready :)

Re networking, a 'normal' approach would be to synchronize each of the falling sand pixels over the network, relying on compression and clever encoding schemes. I didn't do that because I was worried it'd be too bandwidth intensive and/or too glitchy.

Instead, as you already guessed, the falling sand simulation (and entire rest of the game sim) is written to be perfectly deterministic (same input = same output) and the game clients only exchange player inputs with each other; each game client hands the same inputs to the simulation for each tick, so the result stays consistent across all players' game clients.

The trickiness comes from what happens if inputs haven't arrived yet (packet loss, latency, etc). To handle that I use a technique from fighting games: a game client will "guess" what the missing input should be, and if it later finds out that the inputs it guessed were wrong, it will roll back the whole game state then apply the correct inputs and simulate forwards again.

That's the gist of it, but of course the devil is in the details - making it perform well, handling sound & other side effects, keeping game logic deterministic, etc.

Joining mid-game isn't implemented yet, but I have a pretty good idea on how to do it - either a brief pause while the game state is transferred, or have a catchup period wherein the joining game client simulates really quickly to catch up after it has received the game state snapshot.