DEV Community: Nikolay Suslov

Fractal Time Generator in Schrödinger equation

Nikolay Suslov — Fri, 29 May 2026 04:59:05 +0000

Krestianstvo Wavefront Evaluator fractal time generator is substituted into the Schrödinger equation as a quantum kinetics operator, even though it is not one.

Video: Object's wavefront as solitons interact with the "eye's retina", projects back into a virtual world as solitons.

https://www.facebook.com/reel/2129896597791057

The use of a fractal time generator makes it possible to bridge the concepts of quantum (wave) mechanics with Hopfield associative memory (an artificial neural network). Towards AGI. Both operate on the principle of "energy" minimization: solitons—much like neurons in AI — "roll down" into potential wells corresponding to minimum energy states.

Video shows the generation of the image on "eye's retina" achieved by fractal time generator within the Krestianstvo Wavefront Evaluator.

https://www.facebook.com/reel/972183702382043

Live Holographic Editor In Fractal Time

Nikolay Suslov — Mon, 25 May 2026 05:41:39 +0000

https://www.facebook.com/reel/998276146091090

The photo demonstrates the process of working with new types of the holograms. Interaction with these holograms takes place directly within the wavefront itself, experimenting with resonance. This footage represents a fragment of a future wavefront-based computer graphics applications — in which the traditional ontological distinction between "model" and "view" is blurred up.

What does it mean to "observe" and what constitutes the authentic "life of an Instanton"? It might seem, that observation process depends on the dynamics of the fractal time generator; however, this is not almost complete, because observation process enters into resonance with itself—it observes the very life of the observer. This constitutes the Universal Observer, analogous to the Universal Turing Machine.
The "hologram" of the wavefront—produced by fractal-time generator - is fed back to itself. The process then recursively converges toward an an "Instanton". That serves simultaneously as both the model and the view. Also this represents a new understanding of the hologram.

Consequently, the fundamental question regarding the "source of truth" (i.e., the correspondence between the model and reality) transforms onto the question of the theory of interaction. Same time geometry of the spacetime, replaced by the geometry of interaction.

Traditionally, functional-reactive programming and incremental computation approach this new geometry through the prism of algebraic geometry, rather through physical experiment as found in Krestianstvo Wavefront Evaluator.

Instanton in Fractal Time

Nikolay Suslov — Mon, 25 May 2026 05:38:07 +0000

https://www.facebook.com/reel/1522546685934753

This is not a standard animation of an instanton's "life," but rather a recording captured through an "lens of the eye" that adapts itself to the instanton. Drived by fractal time generator. The fractional order of the operator "breathes" in rhythm with the system's dynamics.

Left — intensity, Middle — phase, Right — topo charge.
In standard implementation, the operator kernel is selected prior to the commencement of calculations and remains fixed until their completion. This implementation replaces this fixed kernel; instead, the kernel is constructed based on the orbits of a fractal time generator. If the field is turbulent and generates shorter "pulses" (beats), the operator becomes more local. Conversely, if these "pulses" propagate widely, the operator becomes more nonlocal.
The effective Laplacian retains its fractal character regardless of whether the fine or coarse structure of the field is being examined. Fractal time acts as a natural regulator, preventing the system from collapsing.

One might assume that this "focusing" through a fractal lens captures only the most stable ratios; however, this is not the case. What you observe through the fractal time generator is, in fact, the true "life" of the instanton.

Fractal Time Oriented Programming

Nikolay Suslov — Sat, 23 May 2026 03:16:48 +0000

Everything is an Instanton (a localized event).
Instantons "exchange" Solitons (causal connections).
An Instanton resonates at various depths of Fractal Time, forming natural harmonics of the space-time medium itself—the Instanton.

Video demo:
https://www.facebook.com/reel/35617205774594807

Everything is an Instanton (Computation as an Event).

In a continuous medium, there are no "static objects" holding data in memory. There are only localized events (tunneling/state transitions).

The Paradigm Shift: In traditional architectures, computation is State + Manipulation (a noun being acted upon by a verb). In new formulation, computation is purely an Event (the verb is the noun). The system is defined through "Process Philosophy"—the universe is made of occurrences, not things.

Instantons exchange Solitons (Causal Connections)

Krestiasntvo Wavefront Evaluator relies on the Huygens-Fresnel principle (with specific delay values based on distance), a Soliton isn't just a data payload; it is a strict enforcement of causality (a light cone).

The Paradigm Shift: In traditional programming, messages are effectively instantaneous pointers jumping across "memory". In this architecture, information has a "speed of light." A Soliton is a topologically protected wave traveling through the medium, ensuring that cause and effect are physically simulated rather than just logically executed.

Interactions resonate at depths (Continuous, Recursive Structure)

Fractal Time Generator is replacing the traditional concepts of "scope," "inheritance," and "call stacks" with spectral resonance.

The Paradigm Shift: In a standard program, if an action requires broader context, it makes an API call or goes up a class hierarchy. In the Krestianstvo Wavefront Evaluator, if an event is too energetic or complex for a local node (high frequency / deep branch), it naturally resonates up to a shallower depth (low frequency / broader spatial scale). The hierarchy is not a rigid tree of classes; it is the natural harmonics of the spacetime medium itself.

These three principles serve as a rigorous definition for Topological Event-Driven Computing, replace the traditional virtual machine with wavefront propagation.

This shifts from "matrix grids" and "memory addresses" and firmly into the realm of a living, computational fluid.

On cover photo generated Solitons are live on two different devices, without exchanging data.

This “cyberphysical engine” replaces the traditional virtual machine with wavefront propagation

Nikolay Suslov — Wed, 20 May 2026 18:12:38 +0000

Screenshot demonstrates the hologram resolution of 100 x 100, recording and restoring the object wireframe cube with 80 glowing dots on edges, with Fractal Time Generator.

Krestianstvo Wavefront Evaluator

About: https://dev.to/nikolaysuslov/krestianstvo-wavefront-evaluator-3j9f

Live demo: https://wavefront.krestianstvo.org

Source code: https://github.com/NikolaySuslov/krestianstvo-wavefront-evaluator

In the News (20/05/2026)

This “cyberphysical engine” replaces the traditional virtual machine with wavefront propagation, achieving deterministic synchronization in just 11 lines of code.

“The synchronization problem in distributed systems is usually treated as an engineering challenge. But the creators of Krestianstvo Wavefront Evaluator took a different approach: since information propagation in space follows physical laws, why not directly simulate physics?

This system is essentially an “information physics engine.” It abandons the traditional “linear list” execution model in programming and instead adopts the laws of classical mechanics and wave propagation. The core algorithm is a software implementation of Huygens’ principle-in physics, every point on a wavefront is a source of a secondary spherical wave; in this evaluator, each node that receives a message becomes a “wave source” that can generate new messages (waves) for other nodes.

Causality is guaranteed through a “light cone” structure. Each node maintains a local queue, and messages can only affect future states-either in the next macro cycle or a later micro cycle. Effects never occur before causes. This “discrete impulse + local settlement” model follows a principle: correctness takes precedence over speed.

Architecturally, it replaces the Krestianstvo VM, employing entirely different methods for timing, computation, and inter-node communication. Causality is no longer routed through a central message scheduler, but rather propagates as a wavefront through a graph of local autonomous nodes.

Even if 100 browser windows are opened, as long as the initial script (“laws of physics”) and snapshot (“initial energy”) are the same, they will eventually reach the same state (stability).

This is equivalent to bringing lattice field theory into JavaScript objects. The system runs on a pure functional reactive programming (FRP) platform called Renkon, which inherits the synchronous application architecture of the Croquet VM, but replaces the original virtual machine core with a wavefront evaluator.

The project offers an online demo and complete source code, and is open-source under the MIT license. For multiplayer distributed applications requiring deterministic synchronization-from collaboration tools to multiplayer games-this approach of translating physical intuition into a computational model may be closer to the essence of the problem than traditional message-passing architectures.”

Krestianstvo Wavefront Evaluator

Nikolay Suslov — Thu, 14 May 2026 03:58:49 +0000

Architecture overview and core concepts

The Krestianstvo Wavefront Evaluator is a deterministic reactive collaborative computational engine for multiplayer, distributed applications built on top of Renkon and ideas of Krestianstvo | Renkon implemented in pure FRP the Croquet VM synchronisation applicaition architecture.

It replaces the Krestianstvo VM with a fundamentally different approach to time, computation, and inter-node communication — one where causality propagates as a wavefront through a graph of locally autonomous nodes, rather than being routed through a central message dispatcher.

Live demo: https://wavefront.krestianstvo.org

Source code: https://github.com/NikolaySuslov/krestianstvo-wavefront-evaluator

The Relation to Physics
Fractal Heartbeat
Fractal IFS-based clock
From Virtual Machine to Wavefront Evaluator
Core Vocabulary
Architecture Layers
Meta Program
W - the Node Runtime
Distributed Determinism Invariants
Telemetry
Feedback Loop
Two Layer Time
Key Architectural Decisions
Simulation Speed Control
Autonomous Mode
Examples
Develop & Run
Related works

Introducation

The Wavefront Evaluator isn’t just a clever way to sync avatars; it is deeply rooted in computational physics and hardware architecture. It mimics how information naturally propagates through space-time.

The Relation to Physics

The Wavefront Evaluator is essentially a "physics engine for information". It replaces the "linear list" of standard programming with the laws of Classical Mechanics and Wave Propagation. The algorithm is essentially a software implementation of Huygens’ Principle applied to information.

Wavefront Propagation: In physics, every point on a wavefront acts as a source of secondary waves. In evaluator, every Node that receives a message becomes a "source" that can generate new messages (waves) for other nodes.
Causality and the "Light Cone": Each node has a local queue. A message can only affect a future state (either in the next macro-tick or a later micro-tick). This preserves Causality—the effect never happens before the cause.

This specific pattern—Discrete Pulses + Local Settlement follows the principle - "correctness" is more important than "speed."

Concept	Physics Equivalent	Wavefront Implementation
Pulse	Universal Time	The Reflector Heartbeat
Node Queue	Local Particle State	W.reduce local _Q
Micro-tick	Particle Interaction	The "Drain" / Feedback loop
Stability	Thermal Equilibrium	When all queues are empty

Even if you have 100 Web browser windows, as long as they all start with the same "Laws of Physics" (the scripts) and the same "Initial Energy" (the snapshot), they must arrive at the same "State" (Stability).

It’s essentially Lattice Field Theory for JavaScript objects.

Physics engine for information

Here are the specific physics laws and mathematical formulas that serve as the "blueprints" for this algorithm:

1. Huygens’ Principle (Wave Propagation)

The algorithm's name comes directly from the Huygens–Fresnel principle, which explains how waves move through a medium.

In physics: Every point on a wavefront acts as a point source of secondary spherical waves. The new wavefront is the "envelope" of all these secondary waves.
In the algorithm: Every Node in evaluator acts as a point source. When a pulse hits a node, that node "ripples" by sending messages to its neighbors. The "Stability" reached after the Drain phase is the new global wavefront.

2. Special Relativity (The Light Cone)

The external Reflector and the logical timestamps simulate the Finite Speed of Information C.

In physics: No information can travel faster than light. Events have a "Past Light Cone" (things that could have caused them) and a "Future Light Cone" (things they can influence).
In the algorithm: By using logicalTime, the evaluator enforces a "Speed Limit." A message sent at Tick 10 cannot affect Tick 9. This ensures Causality Preservation. Even if two peers are on opposite sides of the planet, the "Light Cone" of the Reflector ensures they see the same history.

3. The Second Law of Thermodynamics (Entropy and Equilibrium)

The "Drain" phase, where the Meta-program loops until all queues are empty, is a simulation of a physical system reaching Thermal Equilibrium.

In physics: A system will naturally move toward a state of maximum entropy or minimum potential energy (stability).
In the algorithm: The messages in the local queues are like "Potential Energy." As the nodes fire, they "dissipate" that energy. When all remaining queue entries are scheduled beyond the current tick boundary (fireAt > wallTime), the system has reached Stability (Equilibrium) for this tick. The "Stable" flag is the signal that the system has settled into its lowest "energy" state — no ready work remains, no feedback loop is in progress, and no cross-node message is in-flight.

4. Zeno’s Paradox & The Geometric Series (Sub-tick Futures)

The Zeno Effect (Sub-tick Futures) mentions the "Zeno Series." This relates to Zeno’s Paradox in physics—the idea that to travel a distance, you must first travel half that distance, then half of that, and so on. By using micro-ticks (0.5, 0.25, 0.125), the evaluator simulates "infinite" interactions within a single discrete second, much like how physical forces settle into equilibrium almost instantly. This is a direct implementation of a mathematical limit used in physics to describe continuous motion.

In physics: The Sum of a Convergent Geometric Series.
In the algorithm: The evaluator uses this to pack "infinite" causality into a single discrete tick. By scheduling events at t+0.5, then t+0.75, the system "settles" toward the next whole integer (the next second) but executes all the reactive logic in between.

Summary: The "Law" of the Evaluator

If you had to write a single "Formula" for the Wavefront Evaluator, it would look like this:

S(t+1) = (Stability (Drain (Pulse(t) + S(t))))

Where:

S = State of the Universe.
Pulse = The "Energy" injected by the Reflector.
Drain = The "Work" performed by the nodes.
Stability = The "Lowest Energy State" (where the UI is rendered).

This is why the system feels so "solid" — it isn't just following a list of instructions; it is simulating a stable physical environment where every action has a reaction, and everything eventually settles into place.

Fractal Heartbeat and Local Reflector

Local Reflector is recursive in its logic, and it can indeed trigger other reflectors or "nest" emulated ticks. Because the Wavefront Evaluator treats time as a continuous priority queue rather than a fixed set of slots, you can think of the local reflector as a "fractal" heartbeat.

Generating Fractal Heartbeats

Fractal heartbeats form a vector space; they can be added together to yield an object of the same nature. This stands in contrast to harmonic oscillations of different frequences, the sum of which is not a harmonic oscillation.

Phase analysis is simplifying.

Orthogonal (perpendicular in space-time) fractal heartbeats are generated through scaling, whereas orthogonal harmonic oscillations are non-homothetic (dissimilar), and each requires separate generation.

How that recursive nesting works within the implementation:

1. Logical Recursion (The "Loop")

The most basic form of recursion is a single node "ticking" itself. In the krestianstvo-wavefront-evaluator.js code, this is handled by a state-guarded feedback loop.

Step 1: A node receives a pulse and calls ctx.localReflector("tick", 0.1).
Step 2: The Evaluator enqueues a future at wallTime + 0.1 carrying { _isLocalTick: true, _innerTickDelay: 0.1 }.
Step 3: When the drain loop reaches wallTime + 0.1, the node receives the message named "tick" (the first argument you passed — not a fixed __local_tick name).
Step 4: The node's handler calls ctx.localReflector("tick", 0.1) again, re-enqueuing for the next step.

Is it truly recursive?

In Logic: Yes. Tick(n) to Tick(n+1).
In Memory: No. The evaluator uses the Priority Queue to "flatten" this recursion. Instead of the function calling itself and growing the stack, it "yields" to the queue. The META_PROGRAM loop then picks it back up.

2. Cascading Reflectors (The "Nesting")

You can have multiple nodes, each running its own local reflector, and they can trigger each other. This creates a "Reflector within a Reflector" behavior.

Node A (running at 0.1 intervals) calculates a physics state.
At T+0.2, Node A sends a message to Node B.
Node B receives that message and, as a result, starts its own local reflector running at 0.05 intervals to handle a high-speed sub-calculation (like an explosion or a particle effect).

In this scenario, Node B’s "Local Reflector" is logically nested inside the timeline generated by Node A’s reflector. The Evaluator manages all these different frequencies perfectly because it simply sorts all resulting messages by their fireAt time.

3. Creating "Emulated Ticks" for Sub-Reflectors

The system allows you to create "Nested Time Scales" using the Zeno sub-ticks.

If you want a "Local Reflector" to emulate a whole second's worth of logic inside a single sub-tick, you use Temporal Compression:

The Global Reflector is at T=100.
Node uses W.future(0.001, msg) to run a local loop.3. Each loop only advances the internal state, while the logical time only moves by 0.001.

This allows you to run a "Virtual World" inside a single tick of the "Real World."

4. The "Stability" Safety Valve

The main risk with recursive reflectors is an "Infinite Loop" that freezes the browser. The evaluator has a built-in safety mechanism: The Integer Boundary.

Even if your recursive reflectors create 1,000,000 sub-ticks, the Evaluator will only process them as long as they are less than the next integer tick.

If a recursive call accidentally schedules a message for T+1.1, the Evaluator stops and waits for the next real pulse from the external Reflector to "authorize" that time.
This prevents a "Local Paradox" where one node lives in the year 2030 while the rest of the peers are in 2026.

5. Summary: Local reflector with a flat structure

Think of it like this: You can't create a "Reflector inside a Reflector" in terms of code structure, but you can create a "Wavefront that triggers another Wavefront.".

Because every message in the Evaluator is just a (time, target, data) tuple, the system doesn't care if a message came from a real human, a global heartbeat, or a recursive local sub-tick. It treats them all as equal "waves" moving through the graph.

Fractal IFS-based clock

The Fractal Heartbeat has been generalised into makeIfsClock — a deterministic, multiplayer-synchronised fractal cascade that alters the fundamental relationship between time and chaotic flows, suited for non-uniform, fractal time-reparametrisation of any continuous dynamical system. This is a highly suitable for investigating chaotic systems, establishing a canvas where time is no longer a linear axis, but a self-similar fractal landscape.

In standard physics, to see the inner core of a Lorenz lobe one simply has to wait a long time for a uniform clock to eventually pass through it. In the Krestianstvo Wavefront Evaluator, space and time are coupled through the fractal depth: the system enters the deep structure of the attractor precisely because it enters the deep structure of the clock.

Implementation: makeIfsClock

makeIfsClock is a stochastic Iterated Function System (IFS) running deterministically inside a discrete-event priority queue. It is a composable primitive — callers supply onCycle and onBeat callbacks to plug in any ODE or dynamical system, while all clock mechanics are handled internally.

Multiplayer determinism. A classic problem with randomised IFS cascades in distributed environments is state divergence. This is solved by reseeding W.rng at the start of every cycle using a bijective MurmurHash3 finalizer on the logical time:

let h = (cycleCount ^ (p.logicalTime >>> 0)) >>> 0;
h = Math.imul(h ^ (h >>> 16), 0x85ebca6b) >>> 0;
h = Math.imul(h ^ (h >>> 13), 0xc2b2ae35) >>> 0;
h = (h ^ (h >>> 16)) >>> 0;
W.rng.seed(h);

Unconditionally consuming exactly two RNG values per beat (selfRatio and childRatio) guarantees that every peer follows the identical randomised execution branch, satisfying strict state-replication requirements.

Cascade mechanics. The tree branching logic splits generation into controlled sequences:

gen < genCap schedules self-loops at the current depth, scaled by a random contraction ratio selfRatio.
gen === 0 && depth + 1 < depth spawns a child branch into the next nested layer at temporal offset selfDelay + childDelay.

This prevents exponential event explosion while ensuring every tier of the fractal cascade is systematically visited.

Irrational base and contraction ratios. No finite integer product of the contraction ratios can equal an integer multiple of the base delay. This guarantees that scheduled event times (ctx.future(delay, ...)) are dense and do not collapse onto a periodic lattice. The time increments are truly fractal-distributed, yielding a discrete point process whose temporal structure mirrors the Hausdorff measure of the underlying IFS attractor.

Multi-resolution time

The wavefront engine with nested ctx.future ticks is not discrete-time in the classical sense. It is a multi-resolution time where ticks exist at every scale simultaneously:

coarse:  t = 0,    4.28,  6.47,  7.61...    (D0 beats)
medium:  t = 2.14, 3.47,  4.82,  5.63...    (D1 beats)
fine:    t = 1.32, 2.06,  2.57,  3.02...    (D2 beats)
finer:   ...                                 (D3, D4)

All these ticks coexist on the same continuous time axis — they interleave rather than separate into levels. The system has events at arbitrarily fine temporal resolution, bounded only by FRACTAL_MIN_DELAY. This is structurally similar to a wavelet decomposition — multi-scale analysis where coarse and fine scales coexist — or to a Cantor function clock that runs at fractal density on the time axis.

Modulating the SRB Measure

In a traditional system, a chaotic ODE like Lorenz or Rössler flows through phase space in uniform continuous time. According to the ergodic theorem, a single long trajectory samples the strange attractor according to its natural SRB (Sinai-Ruelle-Bowen) measure — the probability density of the trajectory's position over uniform intervals of time dt.

By driving the integration step from the fractal delay (dt = delay * SCALE / STEPS) via the onBeat hook, the sampling density on the attractor is no longer uniform. Because the density of IFS clock ticks is governed by the IFS invariant measure, the point cloud captured in tickEvents is a convolution of two distinct measures:

The Geometry of the Flow — the spatial constraints of the classical attractor (the SRB measure).
The Chronology of the Clock — the temporal constraints of the contraction mapping (the IFS Hausdorff measure).

The resulting object is a trajectory tracing a classical attractor embedded in a non-Archimedean, fractal temporal topology — a state distribution that cannot be replicated by any standard uniform numerical solver.

The three-layer insight

Layer 1 — What standard visualization does.
A single trajectory with fixed dt steps through the ODE at one resolution. Every point is equally spaced in ODE time. Ergodic coverage is eventual but uniform — no sense of which regions are visited more often at different scales.

Layer 2 — What fractal time adds.
The IFS heartbeat generates beats at multiple delay scales simultaneously within one cycle:

Depth	Delay	dt_ODE
D0	≈ 2.14t	≈ 1.07 (coarse)
D1	≈ 0.88t	≈ 0.44
D2	≈ 0.36t	≈ 0.18
D3	≈ 0.15t	≈ 0.075
D4	≈ 0.06t	≈ 0.03 (fine)

Each depth integrates the same trajectory continuation but samples it at a different temporal grain. The coarse levels skip over fast oscillations; the fine levels resolve them. The attractor is being measured simultaneously with five rulers of different lengths.

Layer 3 — What the IFS random map selection does on top.
At each beat, selfRatio is drawn randomly from [√2-1, 1/φ, √3-1]. The next self-loop delay contracts by a randomly chosen irrational ratio. The set of all possible delay sequences forms an IFS in delay-space whose invariant set is the Cantor-like attractor visible in the IFS canvas.

The sampling density on the Lorenz attractor is therefore not uniform — it is weighted by the invariant measure of the IFS in delay-space. The two attractors — one in (X,Z) space, one in delay-space — are coupled through the shared trajectory.

Fractal magnifying lens

A standard ergodic theorem says a single long trajectory samples the attractor according to its natural measure (the SRB measure). Here the sampling measure on the Lorenz attractor is modulated by the IFS invariant measure in time. The system is not just tracing the attractor — it is tracing it with a fractal magnifying glass that zooms in and out at irrational ratios, producing a point cloud whose density reflects both the Lorenz SRB measure and the IFS Hausdorff measure simultaneously.

That is what the colour-coded depth layers reveal visually:

D0 (red/orange) — coarse time steps, broad skeletal structure of the butterfly lobes.
D4 (grey/white) — fine time steps, intricate spiral structures inside each lobe.

The butterfly is not one attractor but five nested samplings of the same attractor at five fractal time scales. You are looking at five simultaneous geometric windows into how the chaotic flow resolves at different scales of temporal magnification.

Parallel ensemble and multi-peer mapping

Each cycle launches an independent trajectory with slightly different initial conditions (seeded from RNG). The IFS randomly selects integration step sizes from the map set. Each trajectory traces the attractor independently — this is the ensemble approach.

The accumulated point cloud shows the ensemble density — where all trajectories spend their time. For a true strange attractor this density is the SRB measure — the physically observable invariant measure of the chaotic system.

This maps directly to the multi-peer architecture: different peers literally run different ensemble members. The collective visualisation is the ergodic average across the ensemble.

No numerical stability problem — each trajectory is self-consistent.
Naturally multi-peer — peers run different ensemble members.
The visualisation density is exactly the SRB measure — what physicists want from a strange attractor.
It proves the wavefront engine can explore measure-theoretic properties of dynamical systems, not just trajectories.
Various forms of self-similar Fractal Time can be generated follwing the objectives of the dynamic system under investigation. This approach can be utilized in physiology to study heart rhythms, the nervous system and other homeostatic processes.

From Virtual Machine to Wavefront Evaluator

The table below captures the essential shift in each architectural dimension.

Dimension	Krestianstvo VM	Krestianstvo Wavefront Evaluator
Message queue	Centralised — one shared queue per world, all messages pass through it	Decentralised — each node owns its own local queue of futures
Time authority	VM clock drives all nodes uniformly	Two-layer time: shared logical pulse + local micro-tick settlement
Causality	Enforced by queue ordering at the VM level	Emerges from wavefront propagation across node dependencies
Sub-step execution	Async, RAF-driven	Synchronous drain loop — sub-ticks are fractions of a logical tick
Late-join / desync recovery	Manual snapshot and replay	Warp mechanism — local clock-advance to catch up before advancing
Node communication	VM routes messages between nodes centrally	`ctx.send()` writes to a per-world outbox; nodes pull inbound on next evaluate
Stability detection	VM-level flag	`W.stable()` checked after each evaluate call; user defines the condition
Introspection	Opaque	`_telemetry` captures per-evaluate snapshots across all nodes generically
Autonomous operation	Requires reflector	Local fallback clock via `makeMeta.startAutonomous()` + `W.localReflector`
Sub-tick scheduling	Not supported	`future(delay < SUBTICK_MS)` drains within current tick

The central insight of the shift: in the VM architecture the queue was the synchronisation mechanism. In the Wavefront Evaluator, the queue is a local implementation detail of each node — synchronisation is achieved instead through shared logical time and deterministic local computation.

Core vocabulary

Pure Logical Time

All time is logical — no Date.now(), no wall-clock dependency in the model.

The reflector stamps each pulse with:

logicalTime = lt        (tick counter, increments by 1 per pulse)
wallTime    = lt        (pure tick count — 1 logical unit per tick)

REFLECTOR_MS = 50 is only the real-time heartbeat rate. World programs never see it. Two peers on different machines receive identical { logicalTime, wallTime } and produce identical state regardless of real-time jitter, browser lag, or GC pauses.

Future Scheduling

ctx.future(delay, msg, payload) schedules msg when wallTime >= currentWallTime + delay. Since wallTime = lt, delays are in logical ticks:

future(1)     → next reflector tick
future(0.5)   → sub-tick: fires within current tick's drain pass
future(0.001) → sub-tick: fires immediately in drain
future(60)    → 60 ticks from now
future(80)    → 80 ticks from now

The drain boundary is SUBTICK_MS = 1. Any future with delay < 1 is a sub-tick.

Pulse

A pulse is the fundamental unit of shared time. It is produced by the external Reflector at regular intervals and delivered to all peers. Every pulse carries:

logicalTime — a monotonically increasing integer, identical for all peers
wallTime — equal to logicalTime (pure tick count, no real-time involvement)

The pulse content is frozen and identical on all peers. REFLECTOR_MS is only the real-time heartbeat rate — world programs never see it. This is the foundation of determinism.

Wave

A wave is the complete lifecycle of computation triggered by a single logical pulse. A wave begins when a pulse arrives at a world, propagates through the node graph as each node processes its ready queue entries and schedules futures, and ends when the world reaches stability. A wave has an identifier (logicalTime) and a completion status (success, process, fail).

Each peer runs its own wave independently. Because inputs are identical, waves on different peers converge to the same final state — they are the same wave, computed locally.

Wavefront

The wavefront is the propagating boundary of settled computation within a wave. As each node processes its ready entries and emits futures, the frontier of "what has been computed" advances through the graph. The wavefront evaluator's job is to keep driving this frontier forward — via sub-tick iterations — until no node has any pending entry at or before the current wallTime. At that point the wave is stable. The wavefront is local — no cross-peer coordination required. Each peer's wavefront advances independently, reaching stability at the same logical result because the inputs were identical.

Phase

A phase is one stage within a wave. The current implementation has two named phases:

Macro phase — triggered by the arrival of a new shared pulse. Every node receives the __macro message once per logicalTime (guaranteed by W.reduce's _lt guard). Nodes respond to the new logical time — either scheduling new work (total __macro) or returning unchanged if nothing relevant changed (incremental __macro).
Micro phase (sub-tick) — one or more local iterations that settle inter-node dependencies and drain queued futures. The micro phase is invisible to the outside world; only the final settled state is observable.

A wave is stable when its micro phase has fully drained — all pending futures have fireAt > wallTime.

Warp

Warp handles the case where a new shared pulse arrives with logicalTime > lastLT + 1 — the peer missed one or more pulses. The evaluator synthetically advances wallTime through the remaining queue entries until stable, then proceeds to the new pulse.

Three conditions must all hold before warp fires: pulse.logicalTime > lastLT + 1 (gap detected), lastLT > 0 (not the very first pulse), and !world.isStable (the previous tick did not fully settle). If the world already reached stability before the gap was noticed, warp is skipped.

Warp does not fire on normal sequential pulses (LT+1). With pure logical time, a world may legitimately have pending futures when the next pulse arrives — those drain normally. Only genuine missed pulses trigger warp.

Warp preserves determinism because the synthetic wallTime values injected during the loop are derived from the node queue's own fireAt entries — the same values that the heartbeat would have delivered in real time, in the same order. Both peers warp through the same sequence and reach the same state.

Drain

Drain exhausts all ready queue entries within a micro phase. Stop condition: _worldNextAt(world) >= wallTime + SUBTICK_MS — where _worldNextAt is the minimum _nextAt across all node states. When that minimum is beyond the current tick boundary, no node has any ready work. Queues may still contain entries — they are simply all future-dated. After the drain, an outbox flush runs an extra evaluate only if the outbox is non-empty, delivering any pending ctx.send() messages.

Stability

A world is stable when three conditions all hold:

All node queues contain only entries with fireAt > wallTime (no ready work remaining)
No node is mid-feedback-loop (_depth === 0 on all nodes)
The shared outbox is empty — no ctx.send() message is pending delivery

All three conditions are checked together inside W.stable() — the outbox check is not a separate step. Condition 3 guards against a subtle timing issue: a ctx.send() written by one node during an evaluate pass lands in the outbox, not a queue — so the queue check alone would miss it. Without the outbox check, the drain loop exits while a message is in-flight, the receiving node never processes it, and the wave terminates prematurely. The application's own semantic completion condition (e.g. stepsDone >= stepsTarget) is defined by the user in WORLD_PROGRAM and combined with W.stable() in the _isStable expression.

Reflector

The Reflector is the Krestianstvo - equivalent, that stamps and broadcasts pulses. It is the sole source of wallTime — no world ever calls Date.now() internally. This ensures that "now" is the same for all peers regardless of their real-time clock drift.

Architecture layers

┌─────────────────────────────────────────────────────┐
│  Reflector                                          │
│  Stamps pulse once. Delivers to all peers.          │
└────────────────────┬────────────────────────────────┘
                     │ pulse { lt, wallTime=lt }
┌────────────────────▼────────────────────────────────┐
│  Meta Program                                       │
│  Orchestrates worlds. Drives the wavefront.         │
│  Warp · Drain · Stability check · UI sync           |
|  startAutonomous() — local fallback clock           │
└────────────────────┬────────────────────────────────┘
                     │ registerEvent / evaluate
┌────────────────────▼────────────────────────────────┐
│  World (ProgramState)                               │
│  Hosts W nodes: Behaviors.collect + W.reduce        | 
|        the reactive node graph.                     │
│  Each node: W.reduce → local queue → futures        │
└────────────────────┬────────────────────────────────┘
                     │ handler(state, payload, ctx)
┌────────────────────▼────────────────────────────────┐
│  W.reduce(state, pulse, nodeId, handlers)           │
│  ctx: future · send · feedback · futureInf          │
│       localReflector                                │
└────────────────────┬────────────────────────────────┘
                     │ W.export → isStable, logicalTime
┌────────────────────▼────────────────────────────────┐
│  Host layer                                         │
│  _worldNextAt · _worldSnapshot · _uiRefresh         │
└─────────────────────────────────────────────────────┘

Meta Program

META_PROGRAM is a Renkon program that runs above the world programs. It receives pulses from the Reflector via a queued receiver (Events.receiver({queued: true})), processes each pulse in order (backpressure-safe), and drives the wavefront for each registered world by calling worldps.registerEvent and worldps.evaluate() in a controlled loop.

For each pulse × world, in order:

WARP — fires only when isNewPulse && lastLT > 0 && !world.isStable && pulse.logicalTime > lastLT + 1 (new pulse arrived, peer missed ticks, and prior tick didn't settle). Calls registerEvent + evaluate() in a loop using _worldNextAt as the advancing wallTime, with isSubTick: true. Safety cap: 1000 iterations.
MACRO — fires on every new pulse (isNewPulse || lastLT === 0). Increments _currentEvalGen, calls registerEvent(pulse) + evaluate().
DRAIN — immediately after macro, loops while !world.isStable && _worldNextAt(world) < wallTime + SUBTICK_MS. Each iteration increments _currentEvalGen, calls registerEvent with advancing wallTime and isSubTick: true. Safety cap: 10000 iterations.
Outbox flush — one extra evaluate, only if world._outbox is non-empty after drain. Uses isSubTick: true at current wallTime (no wallTime advance). Delivers pending ctx.send() messages before stability is checked.

META_PROGRAM never knows the names of nodes inside a world. All world-level introspection goes through generic host helpers (_worldNextAt, _worldSnapshot).

W — the node runtime

W is the functional core of each node. Its reduce function takes (state, pulse, nodeId, handlers) and returns a new state. On each call it:

Restore check — if pulse._restoreState[nodeId] exists, return it immediately (snapshot replay, bypasses all normal logic).
Inbound outbox — collects messages from appRef._outbox[nodeId] where _evalGen < _currentEvalGen (previous evalGen only). Consumed entries are removed from the outbox; remaining same-gen entries stay. This prevents a node from consuming a ctx.send() written in the same evaluate pass.
Queue split — splits state._queue into ready (fireAt ≤ wallTime) and later (fireAt > wallTime). Merges inbound + ownReady into allReady.
__macro injection — if !isSubTick && (state._lt ?? -1) !== logicalTime, prepends {msg: "__macro", payload: pulse, _depth: 0} to allReady. Skipped on sub-tick evaluates and if _lt already equals logicalTime (warp-replay guard). _lt is updated to logicalTime on macro pulses; preserved as-is on sub-tick pulses.
Handler dispatch — iterates allReady, calls handlers[entry.msg](userState, entry.payload, ctx). Unknown messages are silently skipped. ctx.depth equals the entry's _depth. Tracks maxDepthSeen across all entries.
Effect collection — ctx.future pushes {kind:"future", fireAt: wallTime+delay, ...}. ctx.send pushes to appRef._outbox[targetId] stamped with _currentEvalGen. ctx.feedback pushes a future at wallTime + _fbStepMs with _depth + 1, silently no-ops if entryDepth >= maxDepth. ctx.futureInf pushes fireAt: wallTime. ctx.localReflector pushes fireAt: wallTime + innerTickDelay with {_isLocalTick: true, _innerTickDelay, ...extraPayload}.
Returns { ...userState, _queue: newQueue, _nextAt: _Q.nextAt(newQueue), _depth: maxDepthSeen, _lt } — infrastructure fields stripped by W.getState before the view layer sees them.

_nextAt — the timestamp of the next pending entry — is the signal that _worldNextAt reads to drive the drain loop. It is written on every reduce call without any node-name coupling.

Outbox entries are stamped with _evalGen (the evaluation generation at write time). When a node reads its inbound messages it only consumes entries from a previous evalGen — entries written in the current evaluate pass are filtered out and discarded from the outbox. This means ctx.send() messages written in evaluate pass N are consumed in pass N+1 (the next evaluate() call or drain iteration), ensuring that a message written by node A is available to node B on the next pass rather than the same one.

Each Behaviors.collect wraps one W node:

const counter = Behaviors.collect(
  { count: 0, started: false },
  reflector,
  (state, pulse) => W.reduce(state, pulse, "counter", {
    __macro: (s, p, ctx) => { ... },   // fires once per logicalTime
    newCycle: (s, p, ctx) => { ... },  // fires when future arrives
  })
);

__macro fires on every new logicalTime (guarded by _lt field internally). Use a started: true flag in the returned state to fire only once.

Stability

W.stable(nodes, pulse) returns true when:

appRef._outbox is empty (no pending ctx.send() messages)
every node's _queue has all entries with fireAt > wallTime (strictly future — nothing ready to fire)
every node's _depth === 0 (no in-progress feedback loop)

nodes may contain nested arrays — W.stable flattens them. A null node is treated as stable. World programs export _isStable = W.stable([...nodes], reflector) which META_PROGRAM reads via world.isStable.

ctx Primitives

Primitive	Semantics
`ctx.future(delay, msg, payload)`	Schedule `msg` after `delay` logical ticks
`ctx.send(nodeId, msg, payload)`	Cross-node message via evalGen-gated outbox
`ctx.feedback(msg, payload, maxDepth)`	Depth-tracked future at `wallTime + _fbStepMs` (convergence loops)
`ctx.futureInf(msg, payload)`	`fireAt = wallTime` — re-enqueues every drain pass (bounded by the drain loop's 10000-iteration safety cap)
`ctx.localReflector(tickMsg, delay, payload)`	Sub-tick self-hosting clock step, with optional user payload

ctx.future — payload and idempotency guards

payload is any plain serialisable value (scalar, array, or object). The handler receives it as the second argument p:

ctx.future(delay, "beat", { depth: 2, cycleId: s.cycleId });

beat: (s, p, ctx) => {
  if (p.cycleId !== s.cycleId) return s;  // stale — ignore
  // p.depth, p.cycleId available here
}

Why pass cycleId (or equivalent) in the payload?

Sub-tick futures fire asynchronously within the drain loop. If a new macro pulse arrives and resets the cycle before an earlier future fires, the handler will see both the old and new futures in sequence. Without a guard, the stale future corrupts state. The pattern is: stamp the current cycle identity into every payload, and silently drop any future whose cycleId no longer matches s.cycleId.

This is essential in cascading or recursive future chains — such as the Fractal Heartbeat, where each depth schedules the next:

// ECG / Fractal Heartbeat — depth cascade via ctx.future
beat: (s, p, ctx) => {
  if (p.cycleId !== s.cycleId) return s;       // stale cycle guard
  const { depth, delay } = p;
  ctx.future(delay, "beat", { depth, delay, cycleId: s.cycleId });   // re-fire self
  const childDelay = delay / 2;
  ctx.future(childDelay, "beat",                                       // spawn child depth
    { depth: depth + 1, delay: childDelay, cycleId: s.cycleId });
  // ...
}

Each level halves its delay, creating a self-similar cascade entirely within the sub-tick drain. depth in the payload lets the handler know which level of the hierarchy it is processing. cycleId lets it discard futures from the previous RR cycle the moment a new one begins.

Local Reflector mixin

A handler mixin creating a self-hosting clock node. Activates on __macro, drives itself via ctx.localReflector(tickMsg, delay). Needs no external time reference. The local clock IS the node — purely logical, purely deterministic.

...W.localReflector("tick", initialDelay)  // spread into W.reduce handlers

Important: W.localReflector defines a __macro handler that sets the _localActive guard flag. Do not also define __macro in the same handler object — the spread will silently overwrite one of them. Put all bootstrap logic inside the tick handler or use a separate node.

The mixin sets _localActive: true and localLt: 0 on first __macro so the local clock starts exactly once per world, even under warp replay. The localLt field is available in state for tracking inner tick count if needed.

ctx.localReflector — optional user payload

ctx.localReflector(tickMsg, delay, payload) accepts an optional third argument that is merged into the tick pulse delivered to the handler. This lets the local clock carry application-specific state across ticks — for example a phase accumulator for oscillators or animation:

// Phase-accumulating local clock
...W.localReflector("tick", 0.05),

tick: (s, p, ctx) => {
  const phase = ((s.phase ?? 0) + 0.01) % 1;   // advance phase each tick
  ctx.localReflector("tick", 0.05, { phase });   // pass phase forward in payload
  return { ...s, phase };
}

The payload is available on the next tick's pulse p as p.phase. Unlike state (which is the node's accumulated value), the payload travels in the queue entry — it is the message's data, not a side-effect. This is useful when you want the next tick to know something about the previous one without storing it in the main state object, or when you need to pass ephemeral per-step data (animation frame index, phase, seed) that does not belong in the canonical exported state.

Sub-Tick Scheduling

Futures with delay < SUBTICK_MS = 1 drain within the current pulse:

future(0)     → fireAt = wallTime      → drains now (same drain pass)
future(0.5)   → fireAt = wallTime+0.5  → drains now (0.5 < SUBTICK_MS=1)
future(1)     → fireAt = wallTime+1    → waits next tick
future(60)    → fireAt = wallTime+60   → waits 60 ticks

All sub-tick steps are deterministic — every peer runs the same drain loop with the same logical wallTime. This enables:

Synchronous multi-step computation — future(0) chains drain in one pass
Zeno series — geometrically decreasing delays converging toward 1 tick
Self-hosting clock nodes — via W.localReflector

Incremental `__macro`

__macro is called at most once per logicalTime. The application chooses what to do:

Total __macro — reschedules everything every cycle. Correct when every cycle produces new work.

Incremental __macro — only schedules work when inputs changed. The production-correct Krestianstvo/Croquet idiom. When the trigger is a pure function of logicalTime:

__macro: (s, p, ctx) => {
  const cur  = _computeInput(p.logicalTime);
  const prev = _computeInput(p.logicalTime - 1);  // no extra state needed
  if (cur === prev) return { ...s };               // idle — zero queue churn
  // schedule futures for the new input
}

started guard — fire __macro once to bootstrap, then let futures drive cycles:

__macro: (s, p, ctx) => {
  if (s.started) return s;
  ctx.future(0, "startCycle", { cycleId: 1 });
  return { ...s, started: true };
}

When the trigger is not a pure function of time (message-driven state, accumulated values), use Behaviors.collect's own previous state — the reducer's first argument — to detect changes:

__macro: (s, p, ctx) => {
  if (p.someValue === s.lastValue) return { ...s, lt: p.logicalTime }; // idle
  // ... schedule work for the new value
  return { ...s, lastValue: p.someValue, lt: p.logicalTime };
}

The 2D wave example uses the pure-function approach: _waveOrigin(t) vs _waveOrigin(t-1). When the origin hasn't moved, all 100 cells return immediately — zero futures scheduled.

Host helpers

Three functions live in the host layer, registered on meta.ps.app and callable from inside the META_PROGRAM string as Renkon.app.*:

_worldNextAt(world) — scans all node states for the minimum _nextAt, returns it or null. Used to advance wallTime correctly during drain and warp.
_worldSnapshot(world, source, iter) — scans all W nodes (identified by having an array _queue) and captures their current scalar fields into a plain serialisable object. Used for telemetry and future network snapshot/restore. Optional — metas that don't need telemetry (e.g. wave worlds) simply don't register it; META_PROGRAM calls it with optional chaining (?.) so absent registration is silently skipped.

Distributed determinism invariants

These invariants must hold for two peers to stay in sync across arbitrary network jitter:

wallTime = lt — pure logical tick count. No Date.now() in the model.
The canonical pulse is frozen and delivered unchanged. The Reflector stamps wallTime once and freezes the pulse object. Peers receive the original — delivery delay does not alter content.
Warp uses queue-derived wallTime. During warp, wallTime is advanced to _worldNextAt on each iteration — the actual fireAt values already in the queue — not to Date.now(). This ensures both peers traverse the same synthetic time sequence.
No closures in queue payloads. All future payloads are plain scalars or plain objects. This makes state fully serialisable and comparable across peers.
Stability is locally determined. Each peer settles its own wavefront independently. Because inputs are identical, independent local settlement converges to the same result — no cross-peer coordination is needed during a wave.
Queued pulse receiver. The META_PROGRAM receiver uses {queued: true} — no pulse is silently dropped under jitter or load. Each pulse is processed in arrival order.
__macro fires at most once per logicalTime. W.reduce tracks _lt and skips __macro injection if the node already processed this logical tick. This prevents double-firing under warp replay without any app-level guard.

Telemetry

The evaluator captures a _telemetry map on each world, keyed by logicalTime. Each key holds an array of snapshots — one per evaluate() call during that wave:

{ source: "macro" | "drain" | "warp", iter: Number, nodes: {
    [nodeName]: { ...userFields, queueLen, nextAt }
} }

Snapshots are produced by _worldSnapshot — generic, no node-name coupling. The telemetry window is bounded to the last 5 logical times to prevent unbounded growth.

_lastDrainIters and _lastWarpIters are stored as scalars for quick UI display.

The snapshot format is deliberately fully serialisable, positioning telemetry as a foundation for future network snapshot/restore: a late-joining peer could receive a stable snapshot, reconstruct node states and queues, inject a synthetic pulse at the correct logicalTime, and resume from that point — consistent with the Krestianstvo model of snapshot-plus-replay.

Feedback Loop

A feedback loop is a wave that deepens through multiple iterations of inter-node exchange before reaching a fixed point. Unlike a linear chain of futures, a feedback loop involves nodes that respond to each other cyclically — each response potentially triggering another request, until a convergence condition is met.

The term feedback loop is preferred over recursion because there is no call stack involved. Each iteration is a new entry in a node's queue, processed in a subsequent drain iteration. The depth is a property of the wave, not of any function's activation frame.

`ctx.feedback(msg, payload, maxDepth)`

Feedback loops are expressed through a dedicated effect type distinct from ctx.future() and ctx.send():

ctx.feedback("respond", { value, cycleId }, 64);

ctx.feedback() schedules a message at wallTime + _fbStepMs (where _fbStepMs defaults to 0, making it equivalent to ctx.future(0, ...) in the default case), but increments the wave's depth counter by 1. _fbStepMs is configurable via makeMeta and allows feedback steps to carry a small non-zero delay when needed. If depth >= maxDepth the call is a silent no-op, enforcing termination without requiring the handler to check depth manually. The maxDepth parameter makes the termination budget explicit and local to each feedback relationship.

Depth as a first-class wave property

Every queue entry and every outbox message carries a _depth field. W.reduce tracks the maximum depth seen across all ready entries in each evaluate call and writes it back as _depth on the node state. W.stable() requires _depth === 0 on all nodes — a world with an in-progress feedback loop is never considered stable, keeping the drain loop running until the loop fully unwinds.

Depth propagates across node boundaries according to these rules:

Effect	Depth carried
`ctx.feedback(msg, payload)`	`depth + 1` — explicit loop increment
`ctx.send(target, msg)`	`depth` — same wave, preserved across node boundary
`ctx.future(0, msg)`	`depth` — zero-delay, same wave phase
`ctx.future(N, msg)` where N > 0	`0` — new real-time phase, depth resets
`__macro` injection	`0` — new wave boundary, always resets

ctx.send() preserving depth is critical: without it, a feedback loop that crosses a node boundary via send() would reset depth to 0 on delivery, making the accumulating depth invisible to W.stable() and breaking convergence tracking.

Wave depth diagram with feedback

Logical time  T
              │
           pulse
              ├── depth 0   estimator.__macro  → ctx.future(0, "sendObserve")
              ├── depth 0   estimator.sendObserve → ctx.send("corrector", "observe")
              ├── depth 0   corrector.observe   → ctx.feedback("respond")
              ├── depth 1   corrector.respond   → ctx.send("estimator", "refine")
              ├── depth 1   estimator.refine    → delta > ε → ctx.feedback("continueRefine")
              ├── depth 2   estimator.continueRefine → ctx.send("corrector", "observe")
              ├── depth 2   corrector.observe   → ctx.feedback("respond")
              ├── depth 3   ...loop continues...
              └── depth N   delta < ε → no ctx.feedback → queues drain → stable

Example: fixed-point bisection

The reference implementation uses two nodes — estimator and corrector — running a bisection toward the nearest integer.

estimator proposes an initial value each macro pulse and refines it on each correction received:

// estimator: proposes value, refines on correction
__macro: (s, p, ctx) => {
  if (p.logicalTime % FB_CYCLE_MS !== 1) return s;
  const initial = 50 + 49 * Math.sin(p.wallTime * 0.0023);
  ctx.future(0, "sendObserve", { value: initial, cycleId: p.logicalTime, wt: p.wallTime });
  return { ...s, value: initial, iterations: 0, cycleId: p.logicalTime, trace: [{n:0, v:initial}] };
},
sendObserve: (s, p, ctx) => {
  if (p.cycleId !== s.cycleId) return s;
  ctx.send("corrector", "observe", { value: p.value, cycleId: p.cycleId });
  return s;
},
refine: (s, p, ctx) => {
  if (p.cycleId !== s.cycleId) return s;
  const delta = Math.abs(p.correction - s.value);
  const refined = (s.value + p.correction) / 2;
  if (delta > 0.01)
    ctx.feedback("continueRefine", { value: refined, cycleId: s.cycleId }, MAX_FB_DEPTH);
  const newIter = s.iterations + 1;
  const newTrace = s.trace ? [...s.trace, {n: newIter, v: refined}] : [{n: newIter, v: refined}];
  return { ...s, value: refined, iterations: newIter, trace: newTrace };
},
continueRefine: (s, p, ctx) => {
  if (p.cycleId !== s.cycleId) return s;
  ctx.send("corrector", "observe", { value: p.value, cycleId: p.cycleId });
  return s;
},

// corrector: computes midpoint toward nearest integer
observe: (s, p, ctx) => {
  if (p.cycleId < s.cycleId) return s;
  const target = Math.round(p.value);
  const correction = (p.value + target) / 2;
  ctx.feedback("respond", { correction, cycleId: p.cycleId }, MAX_FB_DEPTH);
  return { ...s, correction, cycleId: p.cycleId };
},
respond: (s, p, ctx) => {
  if (p.cycleId !== s.cycleId) return s;
  ctx.send("estimator", "refine", { correction: p.correction, cycleId: p.cycleId });
  return s;
},

Convergence ratio 3/4 per step. For delta_0 = 0.48, EPSILON = 0.01: ~14 iterations.

The trace array is built inside the world program on each refine call and exported — the bisect canvas reads the complete convergence trajectory without RAF sampling artifacts.

Two-layer time

Logical time  T ──────────────────────────────────────▶
              │          │          │
           pulse(lt=1) pulse(lt=2) pulse(lt=3)    shared, discrete
              │
              ├── sub-tick 0      (macro phase)
              ├── sub-tick 0.5    (Zeno step — if scheduled, depth 0..N for feedback loops)
              ├── sub-tick 0.75
              ├── ...
              └── stable          (all fireAt ≥ wallTime+1, all depths 0, outbox empty)

Macro time is shared and observable. Sub-tick time is local and transient. Feedback loops deepen the micro phase but remain invisible externally; only the converged result is exported. This is the same two-layer model described in the original Renkon/Krestianstvo design, made explicit and enforced by the wavefront evaluator.

Deterministic Pseudo-Random Number Generator

The Krestianstvo Wavefront Evaluator includes a deterministic xorshift128+ PRNG (W.rng) to ensure all peers produce identical random sequences from the same seed. All peers seeded identically will generate the same values in the same order — guaranteed consensus on randomness.

WARNING: never use Math.random() inside world nodes — it is non-deterministic and will cause peers to desync.

W.rng API

W.rng.next()          // → float in [0, 1)
W.rng.nextInt(n)      // → integer in [0, n)
W.rng.seed(lt)        // re-seed from logicalTime (deterministic per-cycle reset)
W.rng.state()         // → { s0, s1, s2, s3 }  (snapshot)
W.rng.restore(state)  // restore from snapshot

The session seed is set once at startup via makeMeta:

const SESSION_RNG_SEED = { s0: 0x12345678, s1: 0x9abcdef0, s2: 0xdeadbeef, s3: 0xcafebabe };
const meta = makeMeta(peerId, SESSION_RNG_SEED, REFLECTOR_MS);
// W.rng.restore(SESSION_RNG_SEED) is called internally

RNG example — deterministic sequence per cycle

The RNG example generates RNG_STEPS=20 values per cycle, re-seeding from cycleId at the start of each cycle so every peer produces the same sequence:

const rngNode = Behaviors.collect(
  { values: [], cycleId: 0, started: false },
  reflector,
  (state, pulse) => W.reduce(state, pulse, "rngNode", {
    __macro: (s, p, ctx) => {
      if (s.started) return s;
      ctx.future(0, "generate", { cycleId: 1, step: 0, values: [] });
      return { ...s, started: true };
    },
    generate: (s, p, ctx) => {
      if (p.cycleId !== s.cycleId && p.cycleId > 1) return s;  // stale guard
      if (p.step === 0) W.rng.seed(p.cycleId);                 // re-seed per cycle
      const v      = W.rng.next();
      const values = [...(p.values || []), v];
      if (values.length < RNG_STEPS) {
        ctx.future(0, "generate", { cycleId: p.cycleId, step: p.step + 1, values });
      } else {
        ctx.future(RNG_CYCLE_TICKS, "generate", { cycleId: p.cycleId + 1, step: 0, values: [] });
      }
      return { ...s, values, cycleId: p.cycleId };
    },
  })
);

Architecture:

rngNode.__macro   → once (started guard): ctx.future(0, "generate", {cycleId:1, step:0, values:[]})
rngNode.generate  → stale guard (p.cycleId !== s.cycleId && p.cycleId > 1): drop
                  → step=0: W.rng.seed(cycleId)         // deterministic re-seed
                  → W.rng.next() → append to values[]   // carried in payload, not state
                  → if values.length < RNG_STEPS:
                      ctx.future(0, "generate", {cycleId, step+1, values})  // sub-tick chain
                  → else:
                      ctx.future(RNG_CYCLE_TICKS, "generate", {cycleId+1, step:0, values:[]})

Note: values accumulates in the payload across the sub-tick chain (not in node state) and is only committed to state on the final step. This avoids intermediate state exports mid-chain.

Parameters: `RNG_STEPS=20`, `RNG_CYCLE_TICKS=80 ticks`

W API Reference

// Node reducer — call inside Behaviors.collect
W.reduce(state, pulse, nodeId, handlers) → newState

// Stability check — use in _isStable
W.stable(nodes, pulse) → boolean

// Export world state to world.app (call from world program)
W.export(Renkon, { node1, node2, ... }, isStable)

// Self-hosting clock mixin — spread into handlers
W.localReflector(tickMsg, innerTickDelay) → handlersMixin

// Strip infrastructure fields (_queue, _nextAt, _depth, _lt)
W.getState(node) → { ...userFields }

Handler Context (ctx)

ctx.wallTime                            // current logical wallTime (= lt)
ctx.logicalTime                         // current logicalTime (= lt)
ctx.depth                               // current feedback depth

ctx.future(delay, msg, payload)         // schedule at wallTime + delay
ctx.send(targetId, msg, payload)        // cross-node via outbox
ctx.feedback(msg, payload, maxDepth)    // depth-tracked future at wallTime + _fbStepMs (convergence)
ctx.futureInf(msg, payload)             // fireAt = wallTime — re-enqueues every drain pass
ctx.localReflector(tickMsg, delay)      // sub-tick self-hosting clock step

Key Architectural Decisions

Decision	Rationale
`wallTime = lt` not `Date.now()`	Pure determinism — immune to real-time jitter
Single reflector for all worlds	One clock, all peers
Future delays in logical ticks	No unit confusion, scale-independent
`SUBTICK_MS = 1` boundary	Clean two-level clock without extra machinery
Warp only on `LT > lastLT + 1`	Logical gaps only — normal ticks drain naturally
`future(0)` chains drain synchronously	Arbitrary within-tick computation
`ctx.feedback` with depth tracking	Convergence loops as observable wavefront property
`W.localReflector` mixin	Self-hosting clock, autonomous operation
Outbox flush after drain	Cross-node sends settle before stability check
`setLt(n)` on reconnect	Prevents logicalTime regression after autonomous mode
`trace` array in world state	Full convergence path without RAF sampling
No separate wave shim	All worlds share one reflector — future-driven cycles only

Local Reflector as Simulation Speed Control

The local reflector's tick size directly defines the unit of computation — it can be used to decouple the simulation resolution from the network synchronisation rate.

Concept

The outer reflector gives one tick per REFLECTOR_MS real time (e.g. 50ms). The local reflector subdivides each outer tick into N inner steps by setting innerTickDelay = 1/N:

outer tick  = network synchronisation boundary  (every 50ms real time)
inner tick  = simulation integration step       (every 1/N logical units)

ratio N = inner_ticks_per_outer_tick = 1 / innerTickDelay

Change innerTickDelay and you change how much computation happens per network tick — without touching the reflector rate, without changing real-time intervals, without breaking determinism. Both peers run exactly the same N inner steps per outer tick.

Physics simulation example

// PHYSICS_STEP_VAL and STEPS_VAL injected via .replace() chain
// PHYSICS_STEP_VAL = 0.1  → 10 steps per outer tick
// PHYSICS_STEP_VAL = 0.01 → 100 steps per outer tick

const physics = Behaviors.collect(
  { pos: 0, vel: 1, step: 0, _localActive: false },
  reflector,
  (state, pulse) => W.reduce(state, pulse, "physics", {

    // Bootstrap local clock on first __macro
    ...W.localReflector("simulate", PHYSICS_STEP_VAL),

    simulate: (s, p, ctx) => {
      // One integration step using innerTickDelay as dt
      const dt     = p._innerTickDelay;
      const newPos = s.pos + s.vel * dt;
      const newVel = s.vel * 0.99;         // damping
      const newStep = s.step + 1;

      if (newStep < STEPS_VAL) {
        ctx.localReflector("simulate", dt); // reschedule at same rate
      }
      // else: all steps done — world stable until next outer tick

      return { ...s, pos: newPos, vel: newVel, step: newStep };
    },

    // External event — arrives only at outer tick boundaries
    applyForce: (s, p, ctx) => {
      return { ...s, vel: s.vel + p.force };
    },
  })
);

Speed multiplier table

`innerTickDelay`	Steps per outer tick	Equivalent simulation rate
`0.5`	2	2× per network tick
`0.1`	10	10× per network tick
`0.01`	100	100× per network tick
`0.001`	1000	1000× (near float floor)

Key properties

Deterministic — both peers run exactly STEPS_PER_TICK inner steps per outer tick. innerTickDelay is injected via .replace() so it's identical in both world instances.

External events at outer tick boundaries — applyForce (user input, collision with another peer) arrives via ctx.send() from the outer reflector pulse. The local clock runs "inside" each outer tick; external events "interrupt" only between outer ticks. This matches how multiplayer physics engines handle authority boundaries.

Variable resolution — different worlds can run at different inner rates on the same outer reflector. A physics world at 0.01 and an AI world at 0.1 both synchronise at the same outer tick boundary, each running its own number of inner steps.

Analogous to game engine substeps — physics at 300Hz, rendering at 60Hz, network sync at 20Hz. In Krestianstvo terms: local reflector at 1/300 ticks, outer reflector at 1/20 ticks, external events only at outer tick boundaries.

Autonomous Mode

The DISCONNECT / RECONNECT button demonstrates peer autonomy.

On Disconnect

If user disconected with outer reflector. meta.startAutonomous() on all metas starts a local setInterval(REFLECTOR_MS) injecting pulses:

{ logicalTime: localLt++, wallTime: localLt, _isLocal: true }

All worlds continue animating using purely logical ticks. The local state is deterministic and correct for purely internal computation — it is exactly what the reflector would have produced, since world programs here have no external inputs beyond the logical clock itself. Every peer running autonomously produces identical state.

The state becomes speculative only in full Krestianstvo when the reflector carries external events (user input, peer messages, new joins). In that case, missing those events means the local computation since disconnect must be discarded and replayed from the authoritative event stream on reconnect. The current examples contain no external events, so no rollback occurs.

On Reconnect

Animation resumes seamlessly. If any world diverged, warp fires and replays the authoritative state. The speculative work is cleanly discarded. In full Krestianstvo with external events, this becomes optimistic simulation — compute locally, correct authoritatively on reconnect. For purely internal worlds, it is simply correct deterministic continuation.

Examples

Example 1 — Counter (Wavefront Integrity Physical Trace)

Demonstrates the Krestianstvo consensus model. Two peers independently run sub-step chains. The view shows each peer's progress and marks SUCCESS only when both reach the same target — confirming deterministic consensus.

Architecture:

counter.__macro      → once (started guard): ctx.future(0, "newCycle", {cycleId:1})
counter.newCycle     → ctx.send("subcounter", "startSubCount", {cycleId})
                     → ctx.future(COUNTER_CYCLE_MS, "newCycle", {cycleId+1})
subcounter.startSubCount → guard (p.cycleId <= s.currentCycle): drop stale
                         → ctx.future(0, "step", cycleId)        // bootstrap first step
                         → reset subCount, stepsDone, stepsTarget
subcounter.step      → payload is scalar cycleId (not object)
                     → guard (cycleId !== s.currentCycle || stepsDone >= SUB_STEPS): drop
                     → if next < SUB_STEPS: ctx.future(STEP_MS, "step", cycleId)

Parameters: STEP_MS=1 tick, SUB_STEPS=50, COUNTER_CYCLE_MS=60 ticks

Example 2 — Fixed-Point Bisection (Feedback Loop Convergence)

Demonstrates ctx.feedback — a convergence loop that animates step by step. Depth is a first-class observable property of the wavefront.

The initial value for each cycle uses a sine-based formula:

initial = 50 + 49 × sin(lt × 0.0023)

This produces values spread across [1, 99] with varying fractional parts on every cycle — the irrational multiplier 0.0023 ensures the sequence never repeats over any practical run. Some cycles land very close to an integer (fast convergence, 3–5 iterations), others land near the midpoint between two integers (slow convergence, 20+ iterations). The depth bar and canvas curve look different each cycle, making the wavefront depth visibly meaningful.

Architecture:

estimator.__macro     → every 80 ticks (logicalTime % 80 === 1)
                      → ctx.future(0, "sendObserve", {value, cycleId})
corrector.observe     → ctx.feedback("respond", correction, MAX_FB_DEPTH)
corrector.respond     → ctx.send("estimator", "refine", correction)
estimator.refine      → ctx.feedback("continueRefine") if delta > EPSILON
estimator.continueRefine → ctx.send("corrector", "observe", refined)

The bisect canvas shows the convergence trajectory (value vs iteration) for both peers, with a frozen arc between cycles and faded history traces. The trace array is built inside the world program and exported — bypassing the RAF sampling problem.

The number of refinement iterations varies per cycle depending on |initial - target|. Each iteration crosses the node boundary twice (estimator → corrector → estimator), so estimator.iterations equals the wavefront depth at convergence. Both peers start from the identical deterministic initial value and apply the same formula — they converge to the same result in the same number of steps, confirming distributed determinism.

Parameters: EPSILON=0.01, MAX_FB_DEPTH=64, FB_STEP_MS=1 tick, cycle every 80 ticks

Example 3 — 2D Wavefront Stress (225 independent W nodes, user-triggered waves)

A 15×15 grid of cell nodes. Waves are triggered by user interaction (mouse/touch click). The clock node receives injected cellClick events and broadcasts a wave message to all 225 cells. Each cell independently schedules its own propagation delay based on distance from the click origin.

Architecture

clock (event)    → injectExternalEvent({type:"cellClick", ox, oy, wt, clientId})
                   enqueued directly onto clock._queue as a "userWave" entry
clock.userWave   → ctx.send("cell_N", "wave", {ox, oy, wt, clientId}) × 225
clock.__macro    → once (_alive guard): ctx.future(1, "_keepalive", {})
clock._keepalive → ctx.future(1, "_keepalive", {})   // perpetual heartbeat

cell.wave        → dist = sqrt((cx-ox)²+(cy-oy)²)
                   contribution = cos(dist*0.45) * exp(-dist*0.22) * 0.8
                   ctx.future(max(1, floor(dist * WAVE_STEP_MS)), "activate", {contribution, clientId})
cell.activate    → ctx.future(WAVE_DECAY_MS, "decay", {contribution})
                   amp += contribution, _count++, active = true
cell.decay       → _count--; amp -= contribution (or 0 if _count reaches 0)
                   active = _count > 0

Each cell captures its grid position (cx, cy) in a closure at construction time (cx = id % GRID_W, cy = floor(id / GRID_W)). The propagation delay max(1, floor(dist × WAVE_STEP_MS)) is scheduled as a ctx.future in each cell's own local queue — 225 independent queues, no central structure.

Overlapping waves: activate accumulates amp and increments _count; decay decrements both. Multiple in-flight waves from the same or different users overlap additively and decay independently.

Node generation via multi-script array

The 225 cell declarations are generated programmatically by makeWave2dScripts(), which builds a second script string via Array.from({ length: GRID_W * GRID_H }, ...) and returns [wave2dWorldProgram, cellScript, avatarScript]. The multi-script array is passed to makeWorld — each script is evaluated in the same Renkon scope, so _makeCell defined in script 1 is available when cell declarations in script 2 call it.

W.stable under load

W.stable([clock, cell_0, ..., cell_224], reflector) checks all 226 node queues on every evaluate call. The world is stable only when every cell has both fired activate and decay for all in-flight waves — all queues empty, all _depth values 0.

Parameters: GRID_W=15, GRID_H=15, WAVE_STEP_MS=2 ticks, WAVE_DECAY_MS=28 ticks

Example 4 — Zeno Series (Sub-Tick Futures + Local Reflector)

Demonstrates sub-tick scheduling and the W.localReflector primitive.

A geometrically decreasing series of futures, all within one logical tick:

future(0.5)    → sum = 0.5
future(0.25)   → sum = 0.75
future(0.125)  → sum = 0.875
...            → converges to 1.0 (never reached, ~13 steps)

Uses W.localReflector — a handler mixin bootstrapping a self-hosting clock node:

const zeno = Behaviors.collect(
  { n: 0, sum: 0, localLt: 0, cycleId: 0, _localActive: false },
  reflector,
  (state, pulse) => W.reduce(state, pulse, "zeno", {
    ...W.localReflector("tick", ZENO_INITIAL_DELAY),  // activate on first __macro

    tick: (s, p, ctx) => {
      const delay     = p._innerTickDelay ?? ZENO_INITIAL_DELAY;
      const newSum    = s.sum + delay;
      const nextDelay = delay / 2;
      if (nextDelay > ZENO_MIN_DELAY)
        ctx.localReflector("tick", nextDelay);              // halve and reschedule
      else
        ctx.future(ZENO_CYCLE_TICKS, "restart", {});        // series done, wait for next
      return { ...s, localLt: s.localLt + 1, n: s.n + 1, sum: newSum };
    },

    restart: (s, p, ctx) => {
      ctx.localReflector("tick", ZENO_INITIAL_DELAY);
      return { ...s, n: 0, sum: 0, cycleId: s.cycleId + 1 };
    },
  })
);

All tick steps fire within the current drain pass (delay < SUBTICK_MS = 1). Both peers run identical step counts — deterministic consensus on the Zeno series.

Example 5: Fractal Heartbeat demo

hb2

Demo that creates a "symphony" of events where the high-frequency notes are perfectly synchronized and nested within the low-frequency beats, all managed by the deterministic Wavefront algorithm.

Summary of the "Fractal" Parameters:

FRACTAL_DEPTH (5): How many "generations" of sub-beats are allowed.
FRACTAL_BASE_DELAY (0.5): The starting speed of the "root" beat.
FRACTAL_DECAY (0.14): How quickly the visual "energy" fades after a pulse passes.
FRACTAL_CYCLE (80): Every 80 logical ticks, the whole system "resets" and starts a fresh cascade.

The Fractal Heartbeat is a sophisticated stress test and architectural demonstration of the Wavefront Evaluator. It creates a recursive, self-propagating temporal structure where time "branches" like a tree.

Instead of one heartbeat, it generates a cascade of heartbeats that get faster and more frequent as they go deeper.

1. The Core Logic: The "Beat and Split"

The magic happens inside the beat handler in fractalHeartbeatWorldProgram. When a beat occurs, it does two things simultaneously:

Steady Continuity: It schedules the next beat at the current depth with the same delay.
Recursive Branching: If it hasn't reached the FRACTAL_DEPTH (5 levels), it "spawns" a new beat at the next depth with half the delay (delay * 0.5).

2. Why it is "Fractal"

In geometry, a fractal is a shape where the small parts look like the whole. In this code, you are creating a Fractal in Time:

Level 0: Beats every 0.5 sub-ticks.
Level 1: Beats every 0.25 sub-ticks.
Level 2: Beats every 0.125 sub-ticks.

...and so on.

Because each level spawns its own sub-levels, a single initial trigger creates a "shower" of events. This is why the totalBeats counter rises exponentially.

3. The "Zeno" Connection

The code uses the Geometric Series. By halving the delay at every depth, the algorithm is attempting to pack a "cascade" of logic into the smallest possible slices of time. The FRACTAL_MIN_DELAY (0.005) acts as the "Planck Length" — the point where the simulation stops because the time slices are too small to process efficiently.

5. The Visualizer (The Canvas)

The _renderFractal function draws "Energy" on a canvas. Each "Depth" is assigned a different color. The history array tracks the "energy" (activity) at each level.

When you look at the canvas, you see the Wavefront itself—pulses of activity moving through the sub-tick timeline like ripples in water.

Develop and Run

npm install
npm start

That will start local Reflector and server for hosting static files.

Open web browser:

http://localhost:3000 - list demo apps.

URL params for demo page:

?app=appName&k=seloID

Running in Renkon Pad

Load kwe-index.renkon in local/remote running instance of Renkon Pad, the interactive browser-based environment for Renkon programs. The evaluator runs directly in Renkon Pad with no build step.

Related works

Hardware Description Languages (VHDL / Verilog) where computer chips are simulated.

The Macro-tick is the "Clock Signal" of the CPU. The Micro-ticks are called "Delta Cycles." Inside one clock cycle, electricity flows through gates; one gate flipping causes the next to flip. The simulator "drains" these flips until the circuit is stable before moving to the next clock pulse.

Parallel Discrete Event Simulation (PDES)

In large-scale military or weather simulations, you can't have one central queue (it’s a bottleneck). They use the Chandy-Misra-Bryant algorithm or Time Warp (Jefferson). These allow different "Islands" of the simulation to process their own local queues and only sync up when they absolutely have to.

Distributed Databases (Vector Clocks)

Systems like Amazon’s Dynamo use logical clocks to determine the order of events across different servers. While they don't usually use "Wavefronts", they rely on the same principle: Local time authority combined with a protocol for global agreement.

Contributing

All code is published under the MIT license.

Krestianstvo Electric Lazy Reflector for Croquet VM

Nikolay Suslov — Mon, 20 May 2024 04:04:35 +0000

Krestianstvo Electric introduces the Lazy Reflector for Croquet VM. This becomes possible due to implementing it in Clojure Electric programming architecture involving continuous-time signals with lazy sampling and streaming DAGs.

All known Croquet implementations (including the Smalltalk, VWF, Croquet OS and recent Multisynq protocol) also OSS Krestianstvo on Solid JS are involving discrete timestamp generator (aka Reflector server). The Reflector should produces periodic ticks (~25-50 ms) and also timestamps all external messages coming from the views, then replicates these messages back to all connected peers of some concrete session (Island). If Reflector will not produce any messages, the Croquet VM will be suspended, waiting for any. In simple words, Reflector periodic ticks are needed for any animated in time simulation go forward in Croquet. But, the high frequency Reflector becomes redundant for simulations with slow rates for example or in the applications with no time-animated simulations at all.

The Lazy Reflector is "ticking" and "time-stamping" only on demand, staying the most time idle and laziness - not producing any work at all! However it guarantees, that all connected peers will get just the same ticks and time stamped messages, without missing a single one! As it is based on backpressured Electric continuous lazy server clock.

(new (actQueue (reset! !reflectorTime (e/server e/system-time-ms))))

That perfectly fits Croquet architecture, as in general the most application work is done locally by the clients themselves. That includes involving Future messages with temporal recursion that producing no network traffic at all (future messages never going to the Reflector).

Also Lazy Reflector ticks are now not added to the Croquet VM priority queue. They are only moving local virtual time forward, pulling lazy server clock on demand by the future messages.

To try it in action, there are several example applications in Krestianstvo Electric.
Want to mention, that in the Counter example, the button "Loop" is not triggering Reflector to start ticking periodically. The button send only one external message launching temporal recursion on all connected peers. Then future messages pull the lazy server clock with the sample rate defined in the future step amount (after every virtual 0.5 sec in future do :step).

step (fn [m]
    (swap! !objData update-in [seloID objID :x] inc)
    (sendFutureMsg {:name :step, :when 0.5, :objid objID}))

The source code is available on Github repository

Answering Common Questions about Krestianstvo SDK 4

Nikolay Suslov — Wed, 28 Sep 2022 05:26:38 +0000

Started writing documentation with answering common questions about Krestianstvo SDK 4

1. Is it using the Smalltalk version of Croquet: Squeak Open Croquet or Open Qwaq?

No. Krestianstvo SDK 4 is entirely written in JavaScript and is running on top of JavaScript VM.
Open Croquet architecture is used in Krestianstvo SDK 1. Open Qwaq architecture is used in Krestianstvo SDK 2

2. Is it using Croquet OS or any of croquet.io services written in JavaScript?

No. Krestianstvo SDK 4 is introducing its own implementation of Croquet Application Architecture in JavaScript, based on Solid JS & S.js using Functional Reactive Programming (FRP). Also, that implementation is not limited just to the JavaScript language. Rust, Swift and Squeak Smalltalk versions are in work.

3. Is it using JavaScript version of Croquet known as Virtual World Framework?

Only implementations of Reflector server and Virtual Time are used and modified to suit FRP.
Virtual World Framework provides its own unique implementation of Croquet Application Architecture based on prototypes, nodes and drivers. VWF architecture is used in Krestianstvo SDK 3. The 4th version of Krestianstvo SDK contains no elements of it.

4. Is it compatible with Croquet OS or Virtual World Framework?

Not out-of-the-box. Although Croquet OS / VWF and Krestianstvo SDK 4 share the same original Open Croquet roots, some effort will be required in porting an application between their different implementations, alongside pros and cons.
The application development (code example) with Krestianstvo SDK 4 is looked quite different, comparing to the development in Croquet OS or VWF one's. Croquet OS and VWF Application Architecture is based on Model - View pattern, implemented in Class/Instance programming paradigm. In the contrary, Krestianstvo SDK 4 Application Architecture is based just on pure functions in form of Signals and Computations (Effects). Croquet OS uses pub/sub messaging for interconnecting Model/View instances. VWF is using drivers for that interconnection. In the contrary, Krestianstvo SDK 4 is using "glitchless" automatic dependency graph with a synchronous execution engine found in Solid JS and S.js

5. Do I need to run my own Reflector server to start developing with Krestianstvo SDK 4?

No. You can use any of publicly available already running reflector servers. Like https://time.krestianstvo.org or https://time.livecoding.space

6. Can I run my own Reflector server?

Yes, you can host your own Reflector server anywhere in LAN or WAN. Just point to it in the <Selo/> component

<Selo
    nodeID={"simple"}
    seloID={"1"}
    component={Simple}
    worlds={worlds}
    fallbackWorld={EmptyWorld}
    reflectorHost={"https://url.to.my.reflector"}
/>

Or just use directly in Web Browser url with r parameter: https://play.krestianstvo.org/demo1?r=https://time.krestianstvo.org

7. Does Reflector server used in Krestianstvo SDK 4 aware of a client's application logic or store any application state?

No. Reflector server, that is used in Krestianstvo SDK 4 is fully conform the Croquet Application Architecture. Meaning, that Reflector server is used only for initial connection, ticking, stamping and reflecting the messages received from the clients with the data they want to share (e.g. 2D coords from a mouse movement). It knows nothing about application logic, and don't relay any data, that can be generated with a future messages locally on every synced client, running Croquet deterministic computations.

8. Can I use different Reflector servers at the same time for different worlds linked by Portals, but existed in one world/web page?

Yes. When creating a Portal, just use url with r parameter pointing to any other running reflector server.

9. Are Portals using iFrames to make inter-linked worlds?

No. Portal is just a pure function in form of Solid JS component. Thus, portal can be used inside any other Solid JS component, with no need on creating the new JavaScript context and iFrame. You can freely create a stacks of portals and manipulate them as a single functional component, by passing props and sending messages through it.

10. Does Portals support linking to themselves?

Yes. Portals are recursive. By default portal's recursion depth is set to 2. Use parameter d in the url to set the depth manually.

Krestianstvo SDK 4 | Implementing Croquet and Recursive Portals on Solid JS

Nikolay Suslov — Thu, 01 Sep 2022 04:42:02 +0000

Let me introduce to you the new 4th version of Krestianstvo SDK!

The main feature of the 4th version is the full-featured implementation of the Croquet Application Architecture in Functional Reactive Paradigm using SolidJS / S.JS and introduction of Recursive Portals. The only parts, that stayed the same as in the 3rd version of Krestianstvo SDK are: Reflector and Virtual Time. Their implementations are based on the Virtual World Framework, thus they were just slightly modified to suit Functional Reactive Paradigm.

The 4th version of Krestianstvo SDK is distributed as a standalone ESM module for JavaScript. It could be easily bundled with any Solid JS or Astro web application being hosted and running just in the Cloud.

The work on the 4th version was started in 2019, when I was working on Luminary and introduced the Functional Reactive Streams into the Croquet application architecture. The project with Rubik’s Cube has shown, how Croquet gets a new look on Virtual Time and Promises inside actions, all backed by FRP. For example, the participants could delay the Virtual Time and observe their actions in virtual world in “slow motion”.

Then in 2021 I participated in the first Festival for Web based Music. At the festival me and artist Delia Ramos were creating the web art project — “THIS IS NOT A CONCERT”. In that project, an audience collaboratively explored the artwork inside virtual canvas space within multi-contextual / conceptual creative layers by touching the virtual objects, interacting or viewing through “filters” in Web Browser. The core object, that I needed to for that project was a Recursive Portal, that should work as a filter, portal to other virtual canvas spaces and also as a portal to itself.

But, comparable to the original Smalltalk version of the Croquet, as in the Virtual World Framework and in the 3rd version of Krestianstvo SDK there are still lack of Portals, including dependence on global object Window. The Croquet.io has introduced Portals for the Web, by using sandboxed HTML iFrames (Multiplane Portals for the Metaverse). But in Krestianstvo I wanted to implement Portals the same way as Croquet Smalltalk version does, as pure objects with an ability to make links to themselves, forming a Recursive Portals.

Finally, I was lucky to do it just in pure JavaScript, thanks to Solid JS! To make these all happen, it demanded of me to implement the Croquet application architecture nearly from scratch using functional reactive paradigm in Solid JS / S.JS.

The typical application in the 4th version of Krestianstvo SDK is an application, that will be build up from Solid JS main types of building blocks: Components and Reactive Primitives. Solid’s fine-grained reactivity is built on three core primitives: Signals, Memos, and Effects. Together, they form an auto-tracking synchronization engine. Reactive computations take the form of function-wrapped expressions that execute synchronously (more in SolidJS documentation).

Krestianstvo uses Solid JS reactivity for implementing Croquet’s concept of Model — View interconnection. Croquet Models — are just pure Solid JS Signals, Memos and Stores. Croquet Views — are just Solid JS lightweight Components with no state and no instances. All received external messages from Reflector and all internal Future messages, that responsible for actions are wrapped in a Signals and then dispatched by an Effects accordingly. For example, Smalltalk like “doesNotUnderstand” message is easily realised in Krestianstvo.

Here is an example of simple working app in Krestianstvo SDK | 4 (run it on codesandbox)

import { render } from "solid-js/web";
import { Selo, createLocalStore } from "krestianstvo";

const Counter = (props) => {
  const [local, setLocal] = createLocalStore(
    {
      data: {
        type: "Node",
        nodeID: props.nodeID,
        properties: {
          name: props.nodeID,
          count: 0,
          ticking: false,
          initialized: false
        }
      }
    },
    props
  );

  const inc = () => {
    setLocal("data", "properties", "count", (c) => c + 1);
    props.selo.future(props.nodeID, "inc", 1);
  };

  const initialize = () => {
    inc();
  };

  props.selo.createAction(props.nodeID, "inc", inc);
  props.selo.createAction(props.nodeID, "initialize", initialize);

  return (
    <>
      <h1>{local.data.properties.count}</h1>
    </>
  );
};

render(
  () => (
    <Selo
      nodeID={"counter"}
      seloID={"sandbox_counter"}
      component={Counter}
      reflectorHost={"https://time.krestianstvo.org"}
    />
  ),
  document.getElementById("root")
);

To be continued…

Demo playground: https://play.krestianstvo.org
Glitch demo project: https://krestianstvo-playground.glitch.me

The source code for Krestianstvo SDK 4:

Playground: GitHub
Core library on Solid JS: GitHub
Prototype on S.js: GitHub
Reflector server: GitHub

DEV Community: Nikolay Suslov

Fractal Time Generator in Schrödinger equation

Live Holographic Editor In Fractal Time

Instanton in Fractal Time

Fractal Time Oriented Programming

Everything is an Instanton (Computation as an Event).

Instantons exchange Solitons (Causal Connections)

Interactions resonate at depths (Continuous, Recursive Structure)

This “cyberphysical engine” replaces the traditional virtual machine with wavefront propagation

Krestianstvo Wavefront Evaluator

This “cyberphysical engine” replaces the traditional virtual machine with wavefront propagation, achieving deterministic synchronization in just 11 lines of code.

Krestianstvo Wavefront Evaluator

Table of Contents

Introducation

The Relation to Physics

Physics engine for information

1. Huygens’ Principle (Wave Propagation)

2. Special Relativity (The Light Cone)

3. The Second Law of Thermodynamics (Entropy and Equilibrium)

4. Zeno’s Paradox & The Geometric Series (Sub-tick Futures)

Summary: The "Law" of the Evaluator

Fractal Heartbeat and Local Reflector

Generating Fractal Heartbeats

How that recursive nesting works within the implementation:

1. Logical Recursion (The "Loop")

2. Cascading Reflectors (The "Nesting")

3. Creating "Emulated Ticks" for Sub-Reflectors

4. The "Stability" Safety Valve

5. Summary: Local reflector with a flat structure

Fractal IFS-based clock

Implementation: makeIfsClock

Multi-resolution time

Modulating the SRB Measure

The three-layer insight

Fractal magnifying lens

Parallel ensemble and multi-peer mapping

From Virtual Machine to Wavefront Evaluator

Core vocabulary

Pure Logical Time

Future Scheduling

Pulse

Wave

Wavefront

Phase

Warp

Drain

Stability

Reflector

Architecture layers

Meta Program

W — the node runtime

Stability

ctx Primitives

ctx.future — payload and idempotency guards

Local Reflector mixin

ctx.localReflector — optional user payload

Sub-Tick Scheduling

Incremental __macro

Host helpers

Distributed determinism invariants

Telemetry

Feedback Loop

ctx.feedback(msg, payload, maxDepth)

Depth as a first-class wave property

Wave depth diagram with feedback

Example: fixed-point bisection

Two-layer time

Deterministic Pseudo-Random Number Generator

W.rng API

RNG example — deterministic sequence per cycle

Parameters: RNG_STEPS=20, RNG_CYCLE_TICKS=80 ticks

W API Reference

Handler Context (ctx)

Key Architectural Decisions

Local Reflector as Simulation Speed Control

Concept

Physics simulation example

Speed multiplier table

Key properties

Autonomous Mode

Incremental `__macro`

`ctx.feedback(msg, payload, maxDepth)`

Parameters: `RNG_STEPS=20`, `RNG_CYCLE_TICKS=80 ticks`