Thanks for the link!
We explored using browser storage for states, but you end up hitting a storage boundary at some point anyway. What we’ve done in our production code is use an LRU cache in tandem with the states-dag, so that older ancestral states would fall off over time. We also discussed a strategy where we would compress older branches to a single state before lopping off potential branches.
The action-based representation is interesting, and I’ve done that before in other projects. I suppose one way to get around super-long action chains is to bound the action chain size and then have a total-state-capture at the start of the chain that represents all archived actions. As actions fall off they are then applied to that state.
While capturing the entire state of the app in every node has the potential for large storage costs, I think the idea of time-traveling the state of applications and being able to share and capture these full-states is very compelling; there are a lot of potential uses for this in error reporting, collaboration, multi-session interactions, exploration, etc…