Friday, June 14, 2019

Krestianstvo Luminary for Open Croquet architecture and Virtual World Framework in peer-to-peer Web

Everyone who is familiar with Croquet architecture are anticipating (waiting breathless) the updates for Open Croquet architecture from Croquet V by David A. Smith and Croquet Studios!

However, while working on project by that is heavily based on Virtual World Framework (containing elements of Open Croquet architecture), I have started revising the current Reflector server.

Let me introduce to you an ideas and early prototype of the Krestianstvo Luminary for Open Croquet architecture and Virtual World Framework. 
Krestianstvo Luminary potentially could replace Reflector server in flavour of using offline-first Gun DB pure distributed storage system. That allows instead of ‘Reflecting’ messages with centralised Croquet’s time now, to ‘Shining’ time on every connected node using Gun’s Hypothetical Amnesia Machine, running in peer-to-peer Web. Also to secure all external messages streams by using peer-to-peer identities and SEA cryptographic library for Gun DB. More over running Luminary on AXE blockchain.
Krestianstvo Luminary simply transforms the only server related Croquet’s part - Reflector (taken from VWF version) into the pure peer-to-peer application, running on a client’s Web Browsers.

For those who are not familiar with Open Croquet architecture, just want to mark key principals behind it in simple words. 

Croquet Architecture

Croquet introduced the notion of virtual time for decentralised computations. Thinking on objects as stream of messages, which lead to deterministic computations on every connected node in decentralised network. All computations are done on every node by itself while interpreting an internal queue of messages, which are not replicated to the network. But these queues are synchronised by an external heartbeat messages coming from Reflector - a tiny server. Also any node’s self generated messages, which should be distributed to other nodes are marked as external. They are explicitly routed to the Reflector, where the are stamped with the Reflector’s time now and are returned back to the node itself and all other nodes on the network. 
Reflector is not only used for sending heartbeat messages, stamping external messages, but also it is used for holding the list of connected clients, list of running virtual world instances, bootstrapping new client connections.


So, in Croquet architecture for decentralised networks, the Reflector while being a very tiny or even being a micro service - it remains a server. 
It uses WebSockets for coordinating clients, world instances, providing ‘now time’ for the clients, reflecting external messages.

Let’s look how it works in Virtual World Framework (VWF). I will use the available open source code from VWF, which I am using in project by

That’s a function returning time now by Reflector. Time is getting from a machine, running a Reflector server:
(server code from lib/reflector.js)

function GetNow( ) {
    return new Date( ).getTime( ) / 1000.0;

Then it uses to make a stamp for a virtual world instance:

return ( GetNow( ) - this.start_time ) * this.rate

Reflector send this time stamps using WebSockets. And on a client side VWF has a method for dispatching: 
(client code from public/vwf.js)

socket.on( "message", function( message ) {
  var fields = message;
  fields.time = Number( fields.time );
  fields.origin = "reflector";
  queue.insert( fields, !fields.action );

Look at send and respond methods, where clients use WebSocket to send external messages back to the Reflector:
   var message = JSON.stringify( fields );
   socket.send( message );


Now, let’s look at how Krestianstvo Luminary could identically replace the Reflector server.

First of all clients are never forced using WebSockets directly from the application itself for sending or receiving messages. Instead Gun DB responds for that functionality internally. All operations which previously relay on WebSocket connection are replaced by subscribing to updates and changes on a Gun DB nodes and properties.
So, instances, clients - are just Gun DB nodes, available to all connected peers. In that scene, the required Reflector’s application logic is moving from the server to the clients. As, every client on any moment of time could get actual information about instance he is connected to, clients on that instance, etc. Just requesting a node on Gun DB.

Now, about time.

Instead of using machine’s new Date().getTime(), Krestianstvo Luminary uses state from Gun’s Hypothetical Amnesia Machine which combines timestamps, vector clocks, and a conflict resolution algorithm. So, every written property on a Gun’s node stamped with HAM. This state is identical for all peers. That’s meaning that we could get this state just on any client.
Taking in consideration that Gun DB guaranteers that, every change on every node or property will be delivered in right order to all peers. We could make a heartbeat node and subscribe peers to it updates.

Here is the code for creating a heartbeat for VWF:

Gun.chain.heartbeat = function (time, rate) {
              // our gun instance
              var gun = this;
                  'start_time': 'start_time',
                  'rate': 1
              }).once(function (res) {
                  // function to start the timer
                  setInterval(function () {
                      let message = {
                          parameters: [],
                          time: 'tick'
                  }, 50);

              // return gun so we can chain other methods off of it
              return gun;
Client, which start firstly or create a new virtual world instance, create heartbeat node for that instance and run a metronome (that part could be run on Gun DB instance somewhere on the hosting server, for anytime availability):

let instance = _LCSDB.get(vwf.namespace_); //
instance.get('heartbeat').put({ tick: "{}" }).heartbeat(0.0, 1);

So, every 50 ms, this client will writes to property ‘tick’ the message content, thus changing it, so Gun HAM will move the state for this property, stamping it with the new unique value, from which the Croquet time will be calculated later.
The start time will be the state value of HAM at ‘start_time’ property, of heartbeat node. Please notice, that actual Croquet timestamp is not calculated here, as it was in Reflector server. The timestamp used for the Croquet internal queue of messages will be calculated on reading of ‘tick’ by the VWF client in its main application.

Here is the simplified core version of dispatching ‘tick’ on VWF client main app, just to get the idea: (full code on public/vwf.js, links below)

let instance = _LCSDB.get(vwf.namespace_);
instance.get('heartbeat').on(function (res) {
   if(res.tick) {
  let msg = self.stamp(res, start_time, rate);
  queue.insert(fields, !fields.action);
this.stamp = function(source, start_time, rate) {
            let message = JSON.parse(source.tick);
            message.state =, 'tick');
            message.start_time = start_time; //, 'start_time');
            message.rate = rate; //source.rate;
            var time = ((message.state - message.start_time)*message.rate)/1000;
            if (message.action == 'setState'){
                time = ((_app.reflector.setStateTime - message.start_time)*message.rate)/1000;
            message.time = Number( time );
            message.origin = “reflector";
            return message
The main point here is the calculation of Croquet time using Gun’s HAM state: ( node, property )

for message:

message.state =, ‘tick’); // time of updating tick
message.start_time =, ‘start_time'); //start time of the instance heartbeat
message.rate = source.rate;
var time = ((message.state - message.start_time)*message.rate)/1000;

So, all peers will calculate exactly the same Croquet time on getting an update from Gun DB,  regardless of the time when they get this update (network delays, etc).

As you could imagine, sending external messages will be as simple as just writing the message by a peer to an instance heartbeat with a new message’s content. All connected peers and a peer itself will get that message, stamped with Croquet time, while they are subscribed on changes on heartbeat node (look above at instance.get(‘heartbeat’).on() definition )


Actually that’s it!


  • Reflector server is no longer required for running virtual worlds (any existed GunDB instance on a network fits, could know nothing about Croquet and clients)
  • clients, world instances, connecting logic are hold by a distributed DB
  • stamping messages are doing by clients themselves using Gun’s HAM
  • one dedicated peer, producing metronome empty messages for moving time forward (could be anywhere)

All advantages that Gun DB provides, could be applicable inside a Croquet Architecture. One of scenarios could be the use of Gun’s Timegraph. That’s will allow to store and retrieve the history of messages for recording and replaying later. Using SEA Security, Encryption, & Authorization library, will allow to create a highly secure instance’s heartbeats using peer-to-peer identifies and being deployed anywhere, anytime available on AXE blockchain.


For making a fully functional prototype, there are still an issues in porting Reflector application logic to a functional-reactive Gun DB architecture nature. That concerns to the procedure of connecting clients to a running instance. As it is connected with getting/setting instance state, pending messages and then replaying them on a new connected peers. But, all that is not critical, as does not affect the main idea behind Krestianstvo Luminary.
There are performance issues, as Gun DB is using RAD storage adapter. But configuring several RAD options could be helpful, concerning opt.chunk and opt.until (due to RAD or JSON parse time for each chunk).

Source code

The raw code is available at GitHub repository under the branch ‘luminary’.

The branch ‘luminary-partial’ contains working prototype of partial Luminary, when one master-client is chosen for reflector logic, it uses Gun.state() for stamping messages, as it was done in the original reflector app, and then distribute as updates to other peers through Gun DB.

Thanks for reading and I will be gladfull if you will share your comments and visions on that.

Nikolai Suslov

Thursday, March 23, 2017

Virtual World Framework & A-Frame

In this post I want to share the details about the latest project being done on Krestianstvo SDK.
Virtual World Framework provides a robust decentralised architecture for building virtual world apps based on replicated computation model. It's JavaScript version is strongly based on ThreeJS ibrary for programming apps with 3D visualisation and deep interaction support. So, for building such apps, the developer should be aware of ThreeJS internals, not to mention the knowing of the VWF component's architecture. But, actually VWF is working just with any programmable elements whatever simple they are. The A-Frame framework solves the problem of ThreeJS —Āomplexity for developing Web apps for Virtual Reality. It provides the component-based architecture for that. A-Frame incapsulates ThreeJS, hiding the internals, and providing high-level interface for describing web app declaratively.
So, I have developed a model and view drivers for VWF, that provides basic support for using A-Frame components in Virtual World Framework apps. That allows to build a VWF collaborative apps with 3D visualisation, WebVR, HMD, trackers and mobile devices support easily.

Source code at GitHub

Here is a small video demonstration, that shows the interaction within collaborative Virtual World Framework app, which is composed by the A-Frame components.

In the video three Google Chrome web-browsers are directing to the same VWF app instance's URL. Every browser shows the replicated A-Frame scene with components in it. The users are represented with small cubes and are visible to each other. The cube on the right is holding the simulation, which is staying the same on all browsers.

Try online demo here:

Simple scenario for collaboration:

  • Open in Web-browser the given URL (
  • Copy the generated URL and open it in another browser window
  • or direct Web-browser to,
  • where you could find all running VWF app instances to join to.
  • Open the generated URL at your phone or tablet.
  • Move in space with arrows or WASD and point objects with a cursor in the centre of the screen (this will generate Click event).
  • You could create any number of isolated VWF app instances, but for connecting to them you will need to know the generated URL.

So, how a simple VWF app with A-Frame is look like?
Here is a simple code of index.vwf.yaml:
      value: "Virtual World Framework & A-Frame"
      textColor: "#b74217"
      position: [-2, 2.5, -2]
      position: [1, 1.25, -4]
      color: "#e0e014"
      radius: 1
      wireframe: true
          position: [2, -1.25, 0]
          color: "#2167a5"
          depth: 1
      color: "#ECECEC"
      position: [0, 0, 0]
          look-controls-enabled: true
          forAvatar: true

Wednesday, October 09, 2013

ADL Sandbox project and Virtual World Framework

I am very excited with the ADL Sandbox project and Virtual World Framework at all, and that it is available in open source to experiment with.
By the way, I am from Smalltalk world and an acceptor of OpenCroquet architecture, which has it's own history. OpenCroquet in it's latest form of OpenQwaq take all the features and benefits from the platform being realized on (the open source Smalltalk language dialect Squeak).
But, Virtual World Framework goes further now, especially in moving from class based language architecture to prototypes, that gives a shared code and behaviours used in distributed computation, to be modified at runtime!
So, that's one of the main criteria, I am start moving now from OpenCroquet to Virtual World Framework, despite of sadness of parting with all the benefits of Smalltalk language and it's IDE, comparable to JavaScript and Ruby. Although, I have the insights of looking a Smalltalk language as a DSL language for Virtual World Framework in the future (for example as Seaside web framework for HTML and JavaScript).
ADL Sandbox project uses already one JavaScript language for all stuff.  And one interesting thing to realize in it is having OMeta'JS workspace inside Sandbox script editor, which will allow to define own language's grammar and replicate it through the application instances, then have a running scripts on that shared grammar. Almost all JavaScript language dynamic capabilities will be used in distributed computation then. For example, you could have all the languages down from Logo (Turtle graphics) to Smalltalk available for scripting the virtual world just in the Web browser.
More over the integration between LivelyKernel and Virtual World Framework will give the endless capabilities of in browser project development and editing.
So, I have started using the ADL Sandbox project and Virtual World Framework to build a Virtual Learning Environment for modern mathematics and phisics, exploring the new ways of developing the concrete tools for modelling, rendering and interaction with the content of the virtual world.
Will post about the progress here.

Sunday, July 28, 2013

Curved Space Explorer for Squeak

Want to introduce the Curved Space Explorer for Squeak project,  known as CCSE by Krestianstvo SDK.
It is a Smalltalk port version of Curved Spaces, originally developed by Jeff Weeks ( in C language.
This Squeak version is derived from Krestianstvo SDK project's version, where Curved Space Explorer is collaborative in it's nature and available mainly for distributed computation.
The aim of this project is to make Curved Space Explorer in Smalltalk being available for the large Smalltalk audience and mainstream Squeak distribution, so that anybody interested could work with it.
The project is Open Source and the code is available here:

To run the CCSE you need to download the latest Squeak distribution from the official site
Also I recommend to use the latest Smalltalk CogVM from the
and in the running image, execute in the workspace:

"1. Load FFI"

(Installer repository: '')   
 install: 'FFI-Pools';   
 install: 'FFI-Kernel';    
install: 'FFI-Tests'.

"2. Load 3DTransform "

(Installer repository: '')
    install: '3DTransform'.

"3. Load OpentGL and CCSE"

(Installer repository: '')
    install: 'OpenGL-Pools';
    install: 'OpenGL-Core';
    install: 'OpenGL-NameManager';
    install: 'CCSpaceExplorer'.

"4. Run sample application"

CCSEMorphRender runApp

" Help

In running application there are some options available using the keyboard and mouse:

"up" and "down" arrows on the keyboard - speed of the ship movement
"left" and "right" arrows on the keyboard - change aperture

mouse move with left button pressed - rotation of the ship
mouse move with left button pressed and shift pressed - translation of the ship

press "o" on keyboard - switch between "head" and "body" rotation
press "p" on keyboard - switching on stereo (anaglyph) mode
press "l" on keyboard - switching shaders support (only for Mac OS X for now)


Also you can use the preinstalled image from here:

Happy exploring!

OpenGL procedural textures generator (by David Faught) for Squeak 4.4

Repost from mail list to blog

I have successfully proceeded in running TweakCore on the recent Squeak 4.4 trunk image (from Jenkins).
And one of the famous existed applications developed in Tweak is the OpenGL procedural textures generator by David Faught.
I make it also loadable to the current Squeak.  

You could download the ready to run image from here:
execute in the workspace in own image:

"1. Load FFI"
(Installer repository: '')
    install: 'FFI-Pools';
    install: 'FFI-Kernel';
    install: 'FFI-Tests'..

"2. Load CroquetGL " 
(Installer repository: '')
    install: '3DTransform';
    install: 'OpenGL-Pools';
    install: 'OpenGL-Core'.

"3. Load TweakCore and Procedural textures application for Tweak"
(Installer repository: '')
    install: 'tweakcore';
    install: 'Tweak-OpenGL-sn.3'.

"4. Set the default settings in Tweak"    
CDefaultWidgetLibrary setDefaultSettings.

"5. Run one of two examples"
CProjectMorph open: Wrinkle1.
CProjectMorph open: Wrinkle2.

The attached screenshot shows the running application. 


Monday, April 09, 2012

Virtual World Framework (aka Croquet 2) goes live!

"The Virtual World Framework (VWF) is a fast, light-weight, web-based architecture for creating and distributing secure, scalable, component-based, and collaborative virtual spaces. It leverages existing web-based standards, infrastructure, and emerging technologies with the intent of establishing a powerful yet simple to use platform that is built on top of the next generation of web browsers. " from

Here is the information about VWF, that is available on Internet for now:
The VWF source code, published during the conference
Video showing the Virtual World Framework, starting from 0:40 min.
Slides from WebGl camp 4 about VWF architecture.
I have tested the installation process of VWF server on Mac OS X Lion 10.7.3, here are the steps:
Launch a terminal window:
1. Load the source code from VWF Git repository:
$ git clone vwf
2. Install RVM
$ curl -L | bash -s stable
2. Reload your shell environment
$ source ~/.bash_profile
3. Find the requirements (follow the instructions)
$ rvm requirements
4. Install ruby
$ rvm install 1.9.3
5. cd to your VWF development directory
$ cd vwf/
6. Install bundler
$gem install bundler
7. Install the RubyGems to the system
$bundle install --binstubs
8. Edit the file "", correcting the file paths:
require "init.rb"
change to
require "./init.rb"
5. Set Ruby 1.9.3 as the default for current shell.
$ rvm use 1.9.3
6. Run the VWF server:
$ ./bin/thin start
7. Open http://localhost:3000 in WebGL enabled web-browser (for full experience you will need the latest Mozilla Firefox web browser)
If you want to start VWF server as a background service, just add -d key:
$ ./bin/thin start -d
Also I tested the installation procedure on FreeBSD 8.1
and has successfully ran the VWF server instance on

Happy Birthday to Virtual World Framework!

Wednesday, January 25, 2012

Krestianstvo SDK at C5-2012 conference

This year I was very happy to be at the The Tenth International Conference on Creating, Connecting and Collaborating through Computing 18-20 January 2012 (Institute for Creative Technologies, University of Southern California, CA, USA) and to demonstrate Krestianstvo SDK's projects and quit new features of it, like Microsoft Kinect and CAVE support for OpenQwaq. The primerily proceedings are available for download (publication to appear).

Almost all Viewpoints research institute's team was there!
There was a great tour of USC Institute for Creative Technologies and demonstrations of their projects.

Coach Mike (programming robot with blocks)

ICT Graphics Lab: Light Stage X, Gunslinger: Virtual Human integration demonstration, ICT Mixed Reality.

in.. Los Angeles, California...

Wednesday, December 21, 2011

David A. Smith has revealed a new Croquet-like framework available in March 2012

David A. Smith, one of six principal architects of the Croquet Project has revealed a new Croquet-like framework that is built on WebGL and HTML, on which he is working now!
"We plan to have an open beta in March 2012" - David A. Smith said.
That's incredible!
Merry Christmas and Happy New Year!