First issue I noticed is that it is really laggy once you use an actual server instead of localhost and start paying latency

Thanks you Eric for trying it out! Yes, I am also experiencing laggy performance. The closest goal of the current development phase is to get an equivalent implementation of the original OSS Croquet VM in Electric. And I found that going from non reactive implementations of Croquet to the mind blowing reactive Electric DSL required to be very accurate in a lot of aspects. For sure, the closer to Electric/Missionary architectural concepts the fewer lags will be. The current demo application on the server provides a metronome that produces a master tick every 50ms in the form of external messages flow. Plus a mouse on any e/client produces its own external events stamped by the server, which gives more stress. But, metronome doesn't have to be enabled by default, so pausing it (demo worlds contain pause button) will not affect the running Croquet VM. So, any other external messages e.g. mouse clicks, throttled move events will suit for moving forward the virtual time (Future message sends). Saying like: "animation will go, only while you are pressing buttons or moving a mouse". Metronome object just automate that. I have started describing the implementation of the VM here (https://github.com/NikolaySuslov/krestianstvo-electric/blob/dev/src/krestianstvo/docs/krestianstvo.md). Also Croquet VM requires that just every external message should reach its recipient, as the object state is computed locally on every e/client by itself, interpreting incoming messages.

This is really neat! Have you had feedback on this exploration from other Croquet folks (https://croquet.io/advisors/ Croquet Labs people)?

Thanks! Yes, I have made an announcement in the Croquet community public discord and have gotten a positive reaction. Here is the response From Yoshiki Ohshima (Chief Scientist, Co-founder at Croquet Labs) "This sounds pretty cool. Yes, I think making tick rate adaptable, or rather as you described, just make a tick when it is precisely needed is the way to go. And I like the idea of explicit notion of continuous and discreet time ala FRP or "denotative, continuous-time programming" (DCTP), as Conal Elliott himself would rather call it." But I should bring to your attention that the Croquet VM at Croquet Labs is the closed source product. And currently the company is in the active phase of developing the https://multisynq.io/ protocol (based on Croquet & Blockchain). Instead https://krestianstvo.org/ is a fully OSS project and is based on the publicly available implementations of the Croquet VM (Smalltalk, VWF/JS). And what I can say with almost certainty, is that all known implementations of the Croquet VM (including ongoing Multisynq) belong to STT (Simple TeaTime) where Time is discrete, as the full TT (TeaTime) needs Time to be continuous function. I attached the slide from Croquet - Hedgehog architecture presentation, 2005 (David A. Smith, Andreas Raab, David P. Reed, Alan Kay). You can also read the recent Multisynq Litepaper about Synchronizer Ticks that move time forward (aka Reflector in Croquet) on pp.11-12. That still follows simple TeaTime approach.(https://multisynq.io/downloads/Multisynq%20Litepaper.pdf). And today in 2024, due to Electric Clojure, there is a hope that for the Croquet application architecture in general (https://en.wikipedia.org/wiki/Croquet_Project), it's dream to get full TeaTime will finally come true!

Ah neat! And yeah it's a shame most Croquet work has been closed source until now. But I'm glad to see there's hope yet 🙂 It still amazes me that David Reed more or less described Datomic (i.e. Rich's "epochal time model") in his http://publications.csail.mit.edu/lcs/pubs/pdf/MIT-LCS-TR-205.pdf(!)