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).

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.

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. The Croquet.io has introduced Portals for the Web, by using sandboxed HTML iFrames (Multiplane Portals for the Metaverse). And 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 from 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 with Solid JS.

Here is an example of simple working app in Krestianstvo SDK | 4 (view 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

Let me share with you the new LiveCoding.space 2020 World:  
Collaborative Robots: Rubik's Cube & Lego BOOST.

Here is the outline of the following post:

• Collaborative Rubik's Cube simulator
• Croquet VWF and Functional Reactive Streams, why this feature is must have!
• LiveCoding.space driver for Lego BOOST brick, implementation details

Collaborative Rubik's Cube simulator

Collaborative Rubik's Cube simulator transforms the original Rubik’s Cube demo (by Stewart Smith) that powers the Rubik’s Cube Google Doodle, the Chrome Cube Lab to collaborative one.
Multiple users can explore Rubik's cubes collaboratively and send commands simultaneously. Create a zoo of Rubik's Cubes in virtual worlds.
In LiveCoding.space Rubic's Cube is augmented with virtual robot, that is backed by three physical devices (Lego BOOST brick). So, virtual Rubic's Cube dispatch user commands for rotating faces and executes them sequentially on appropriate devices. Even users, that don't have a connected Lego BOOST brick, could execute commands remotely on other users devices, in the same virtual world.

Croquet VWF and Functional Reactive Streams

In Croquet VWF by default any call of Model's method, like  
vwf.callMethod(nodeId, 'methodName', [parameters]) will go trough VWF Model/View drivers chain for updating the application node tree, executing JS code as soon as possible using proxy 'traps': callingMethod and calledMethod.
That works quit well for synchronous sequential code execution. And also for executing non sequential asynchronous code.
But, that does not suited to work with Promises (async/await), which represents the eventual completion, especially sequences of promises.
So, imagine you have a real physical Rubic's Cube robot, consisting of three independent robot devices (Lego BOOST in our example), every device has for three motors, leds, sensors. And you want to synchronise their work, by sending sequential messages from virtual world, like:
robot1.motorA(90); robot2.motorA(-90); robot1.motorB(-90);. That any next operation waits for a previous operation to complete.
Functional Reactive Streams come as a solution to Croquet VWF and open an unlimited functionality for interconnecting physical world of devices with virtual world in a unique collaborative way, which was not available before!

LiveCoding.space driver for Lego BOOST brick: implementation details

LiveCoding.space 2020 update includes an experimental driver for collaborative synchronous/asynchronous controlling of the external robot device within virtual world.
The implementation of the driver is heavily based on using functional reactive streams. The communication with Lego BOOST brick is done over Web Bluetooth. There is no need for any third party software nor OS driver to start using Lego BOOST inside virtual world. You just need a computer/smart phone with Bluetooth, Web Browser and Lego BOOST brick.

When, Lego BOOST brick is connected, the initialization of reactive functional stream of promises is happened in the driver.

    self.streamScheduler = M.scheduler.newDefaultScheduler();
    const [induce, events] = M.createAdapter();
    self.streamAdapter = {
        induce: induce,
        events: events
    }

    const result = M.concatMap((x) => M.fromPromise(x()), events);
    self.eventsStream = M.tap(res => { tapFunction(res) }, result); 
    M.runEffects(self.eventsStream, self.streamScheduler);

Every method call from the Croquet VWF Model, that is considered to be a Promise, like robotA.setMotorAngle(90), will go through Lego BOOST driver, where it will be added to the stream of promises:

Example of adding LegoBOOST Led action:

let promiseAction = async function () {
    return self.boost.ledAsync(ledColor).then(r => {
        return {
            check: {
                isLegoBoost: isLegoBoost,
                isLegoBoostClone: isLegoBoostClone
            },
            action: "lego",
            nodeID: nodeID,
            methodName: methodName,
            methodParameters: [ledColor],
            res: r
        }
    })
}
self.streamAdapter.induce(promiseAction);

Then, only when Promise from stream will be fulfilled, the side effect will be performed:

    const tapFunction = function (res) {
        if (res && res.action == "lego") {
            if (res.check.isLegoBoost) {
 self.kernel.callMethod(res.nodeID, "sat_" + res.methodName, res.methodParameters)
            }
        }
        console.log(res);
    }

Finally, in LiveCoding.space code editor one could execute the sequence of async code and expect the right order of operations on connected physical devices:

robotA.setLed("red");
robotB.setMotorAngle('A', 180, -100);
robotA.setMotorAngle('B', 90, 100);
robotB.setLed("green");

Glad to share with you the long awaited 2020 update to the LiveCoding.space project, so let me introduce to you:

• What's new in 2020 update!
• Answer the question, why LiveCoding.space is still based on Croquet VWF instead of Croquet.io
• And finally dive into the details of new "Minimal" application

LiveCoding.space 2020 updates

1. LiveCoding.space is moving towards ES6 compliance! It means, that all Croquet VWF core application components are now ES6 modules (including VWF model, view, drivers etc).
2. The minimal Croquet VWF core is now distributed separately from the drivers/application entanglement, compared to original VWF. This new core consists of refactored components: Croquet Virtual Time, Reflector Client, Luminary, VWF core app, Kernel, Model, View, JavaScript etc., all in ES6 modules format. Look at example: "Minimal" application.
3. The core now has an experimental support of "stream of messages", based on functional reactive streams. That feature allows to record/replay/delay etc. external & internal (reflector/luminary) messages on peers (ongoing changes).
4. Use very fast binary heap priority queue for sorting messages on Croquet core.
5. All LiveCoding.space application components and worlds are now described in JSON format, with no YAML support anymore.
6. There is no "super" user anymore, who should own proxy components for bootsrapping worlds from decentralized storage. Now every user could own it's own proxy and built the world from corresponding components.
7. Any saved World could be used now as a World prototype for later reuse.
8. Experimental driver for communication with external hardware over Web Bluetooth and functional reactive streams. Look at example: "Collaborative Robots".
9. Finally add support for Oculus Quest/VIVE/Windows MR/Gear VR headsets in all spaces by default with teleportation control. Look at example: "Paint" application.
10. Avatars are now have virtual pointers for interaction with in-world UI's.
11. Added QR codes for world instance's URL for user friendly connection from mobile devices.
12. Added costumes functionality for avatars and pointers.
13. A-Frame library is updated to the latest 1.1 version, with support of the latest Web XR, AR JS and Layers. Look at example: "AR" application.
14. Gun DB is updated to the latest stable version 0.2020.520

Screenshot from "Paint" application.

Croquet VWF or Croquet.io?

If you are aware of LiveCoding.space project, you may noticed, that it is based on Croquet architecture (VWF version). While working with VWF just from 2012, I have started this project in 2017. VWF is known as Virtual World Framework an open source version of Croquet architecture for Web Browser.
Later in 2019 the latest version of Croquet was introduced Croquet.io, known nowadays as just Croquet (no version supplement) - and which is Awesome!
Check here experimental projects, where I explore the potential features.
Yet, that latest version of Croquet requires Internet connection and is closed sourced, but provides the SDK for developers. The SDK is well documented and allows to create collaborative apps just in minutes using Croquet.io architecture in Web Browser, but with two restrictions:

• you could not modify/extend the Croquet core, as it is closed sourced
• you are only allowed to use Croquet specific reflector servers, that are provided by Croquet.io on Internet, and could not create your own ones

Actually, for the most applications, that are developed using Croquet architecture, these restrictions are not limitations, as may appear. In most cases, the developer will never need to touch the Croquet core, as applications are fully client side. And geo-distributed reflector servers running 24/7 are also can satisfy nearly every needs.
But, unfortunately, for the LiveCoding.space project these two restrictions are the critical limitations, as there is no way to implement the latest Krestianstvo Luminary and other decentralized extensions in the Croquet core.

For now LiveCoding.space project will remain to be based on the open source version Croquet (VWF).

While looking closely on the latest Croquet.io, one can find, that the new version is implemented on the latest ES6 standards, have introduced pub/sub events for inter - Model/View communications and other things, but architecturally still relies on specific reflector servers and snapshots much like in Croquet VWF.

In comparison, LiveCoding.space alongside with using own standard minimal reflector servers, it moves Croquet VWF architecture towards decentralization, by introducing Krestianstvo Luminary.

So, the combination of  Croquet VWF & Krestianstvo Luminary does not need any Croquet specific reflector servers at all, comparing to the original Croquet VWF or Croquet.io architectures.

Example of LiveCoding.space application: Minimal

Let's explore the  "Minimal" application details:

This "Minimal" application every virtual second updates a world property with Croquet Time and shows it on a web page and debug console; counts clicks on Model on every peer, without transmitting this data; generating a random number in Model on every peer.  
There are only three steps needed to complete a working application:

1. Create World's description file in JSON format:

{
  "extends": "proxy/node.vwf",
  "properties": {
    "timeCount": 0,
    "clicks": 0,
    "randomNumber": null
  },
  "methods":{
    "initialize": {},
    "run": {},
    "incClicks": {},
    "decClicks": {},
    "getRandom": {}
  },
  "scripts":{
    "source": "minimal.js"
  }
}

2. Create minimal.js file with Model driver methods

this.initialize = function () {
    this.run()
}

this.run = function () {
    this.timeCount = this.time;
    console.log(this.timeCount);
    this.future(1).run();
}

this.incClicks = function () {
    this.clicks = this.clicks + 1
}

this.decClicks = function () {
    this.clicks = this.clicks - 1
}

this.getRandom = function () {
    this.randomNumber = this.random();
}

3. Create/modify default index.vwf.js file with View driver methods.

import { h, text,patch } from "$host/lib/ui/superfine.js"

class UserView {

    constructor(view) {
        this.view = view;
        this.init();
    }
    

    init() {
        let self = this;

        vwf_view.initializedNode = function (nodeID, childID, childExtendsID, childImplementsIDs,
            childSource, childType, childIndex, childName) {
            
            if (childID == vwf_view.kernel.application()) {

                ["time", "clicks", "random"].forEach(name => {

                    let el = document.createElement(name);
                    el.setAttribute("id", name);
                    document.querySelector("body").appendChild(el);

                })

                self.satTime(0);
                self.satClicks(0);
                self.satRandom(0);

            }
        }

        vwf_view.satProperty = function (nodeID, propertyName, propertyValue) {

            if (propertyValue === undefined || propertyValue == null) {
                return;
            }
            //let el = document.querySelector("[id='" + nodeID + "']");

            if (!document.getElementById("time"))
                 return


            if (propertyName == 'timeCount') {
                self.satTime(propertyValue);
            }

            if(propertyName == 'clicks'){
                self.satClicks(propertyValue)
            }

            if(propertyName == 'randomNumber'){
                self.satRandom(propertyValue);

                //update body color
                let randomColor = Math.floor(parseFloat(propertyValue)*16777215).toString(16);
                document.body.style.backgroundColor = "#" + randomColor;
            }

        }
    }

    satTime(state) {
        patch(
            document.getElementById("time"), 
            h("time", {style: "position: absolute; top: 100px; margin-left: 20px;" }, [
                    h("h2", {}, text('Time: ')), 
                    h("h1", {}, text(state))
        ]))
    }

    satClicks(state) {
        patch(
          document.getElementById("clicks"),
          h("clicks", {style: "position: absolute; top: 240px; margin-left: 20px;"}, [
            h("h2", {}, text('Clicks: ')), 
            h("h1", {}, text(state)),
            h("button", { onclick: () => vwf_view.kernel.callMethod(vwf.application(), "incClicks") }, text("+")),
            h("button", { onclick: () => vwf_view.kernel.callMethod(vwf.application(), "decClicks") }, text("-"))
          ])
        )
    }

    satRandom(state) {
        patch(
          document.getElementById("random"),
          h("random", {style: "position: absolute; top: 400px; margin-left: 20px;"}, [
            h("h2", {}, text('Random number: ')), 
            h("h1", {}, text(state)),
            h("button", { onclick: () => vwf_view.kernel.callMethod(vwf.application(), "getRandom") }, text("Generate"))
          ])
        )
    }
}

export {UserView as default}

4. Optional add Model/View drivers to the app config if needed (like editor driver etc)

{
  "info":{
    "title": "Minimal App"
  },
  "model": {},
  "view": {}
}

5. Optional add simple description for World catalog on it's Web page

{
    "info": {
        "en": {
            "title": "Minimal app",
            "imgUrl": "/defaults/assets/webimg.jpg",
            "text": "Minimal app example"
        }
    }
}

In the next post, we will look into details of Functional Reactive Streams for Croquet VWF & Luminary and "Collaborative Robots" application example.

The component allows easily, while staying in A-Frame scene definition (plain HTML file), to add a multi-user features onto A-Frame entities in scene. Create Croquet (aka Croquet V) simulations on A-Frame entities.
A-Frame multi-user component works by synchronizing / replicating entities and their components to connected peers using Croquet application architecture. It relies on public Croquet reflectors, which are avaliable online on the Internet.

Source code on GitHub

Live basic project at Glitch: https://glitch.com/~aframe-croquet-component

Demo video

Getting Started

How to share an entity in an A-Frame scene with other users:

Add links to this component and croquet lib in the html header

<script src="https://croquet.studio/sdk/croquet-latest.min.js"></script>
<script src="https://unpkg.com/aframe-croquet-component/public/lib/aframe-croquet-component.js"></script>

Add croquet component to the root element and give a name to the Croquet session

<a-scene croquet="sessionName: demo-scene">

Give an id to the entity (if not exist) and finally add multiuser component

 <a-box id="box1" position="-1.5 1 -3" rotation="0 45 0" color="#4CC3D9" multiuser></a-box>

Open the same scene in several Web Browsers windows. The entity should be synced!

How to try out the synchronization:

Open Web Browser Developer Tools and select an entity with multiuser component

let box = document.querySelector('a-scene').querySelector('#box1')

Change entity attributes like, position, rotation, geometry or material etc., by replicating the entity properties

box.setAttribute('position', {x:0, y: 1, z: -4});
box.setAttribute('rotation', {x:0, y: 45, z: 0});
box.setAttribute('material', {color: '#4BAC41'});
box.setAttribute('geometry', {width: 3});

Start a Croquet application attached to an entity, by replicating a computation (animation example)

box.setAttribute('multiuser', {anim: true});

Also you could try to attach to scene the A-Frame scene Inspector by pressing <ctrl> + <alt> + i. Modify entity properties within it's GUI and observe how some of the properties replicates on other peers.

Basic Scene Example

source code

<html>
<head>
  <title>A-Frame & Croquet</title>
  <script src="https://croquet.studio/sdk/croquet-latest.min.js"></script>
  <script src="https://aframe.io/releases/1.0.3/aframe.min.js"></script>
  <script src="https://unpkg.com/aframe-croquet-component/public/lib/aframe-croquet-component.js"></script>
</head>
<body>
  <a-scene croquet="sessionName: demo-scene">
    <a-box id="box1" position="-1.5 1 -3" rotation="0 45 0" color="#4CC3D9" multiuser="anim: true"></a-box>
    <a-sphere id="sphere1" position="0 1.25 -5" radius="1.25" color="#EF2D5E" multiuser></a-sphere>
    <a-cylinder id="cylinder1" position="1 0.75 -3" radius="0.5" height="1.5" color="#FFC65D"></a-cylinder>
    <a-plane id="plane1" position="0 0 -4" rotation="-90 0 0" width="4" height="4" color="#7BC8A4" multiuser></a-plane>
    <a-sky color="#ECECEC"></a-sky>
  </a-scene>
</body>
</html>

[UPDATED 10.2019]

Krestianstvo Luminary functional prototype is avaliable to try out at https://livecoding.space and it's source code at LiveCoding.space GitHub repository master branch

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 LiveCoding.space project by Krestianstvo.org 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.

Reflector

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 LiveCoding.space project by Krestianstvo.org

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 );

Luminary

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;
              gun.put({
                  'start_time': 'start_time',
                  'rate': 1
              }).once(function (res) {
                  // function to start the timer
                  setInterval(function () {
                      let message = {
                          parameters: [],
                          time: 'tick'
                      };
                      gun.get('tick').put(JSON.stringify(message));
                  }, 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 it’s 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 = Gun.state.is(source, 'tick');
            message.start_time = start_time; //Gun.state.is(source, '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:

Gun.state.is ( node, property )

for message:

message.state = Gun.state.is(source, ‘tick’); // time of updating tick
message.start_time = Gun.state.is(source, ‘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 )

instance.get('heartbeat').get('tick').put(JSON.stringify(newMsg));

Actually that’s it!

Conclusions

• 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 deplyed anywhere, anytime available on AXE blockchain.

Issues

[UPDATED 10.2019]

Krestianstvo Luminary functional prototype is avaliable to try out at https://livecoding.space

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

[UPDATED 10.2019]
The source code of the latest functional prototype is avaliable under master branch at LiveCoding.space GitHub repository

The raw code is available at LiveCoding.space 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

UPDATED 03/2020: Please use the latest code and instructions for that Open Croquet integration from GitHub project https://github.com/NikolaySuslov/croquet-squeak. There is also a fix for using it with recent Squeak 5.3 image.

UPDATED 10/2018: That Open Croquet integration also applies for the current Squeak 5.2 release

Restoring the original Open Croquet onto Squeak 6.x. (experimental).
For a long time, the community avaliable Open Croquet images exist only in bootstrap images for Squeak 3.8 and for Squeak 4.2. Actually, there is no any open solution to use the latest Squeak VM and Smalltalk language with Open Croquet architecure. So, that starting from the original version to OpenQwaq, anyone could load it from scratch onto the new Squeak.
Below you could find install instructions, links and first steps in achiving this.

Demo-video: https://vimeo.com/257578323

Copmaring to the original Open Croquet for Squeak 3.8/4.2:

• No Embeded Morphic apps (bugs)
• No Tweak (yet)
• Original TContactPoint (find master on network) broadcaster/listener is replaced with WebSocket broadcaster/listener using WebClient (switching from UDP)
• Island snapshoting/serializing/restoring needs deep review

Instructions and Links:

UPDATED: 10/2018 Instructions For Squeak 5.2

1. Download an official 32bit Squeak 5.2 VM & Image
2. Do It in Workspace: (Installer fromUrl: 'http://sdk.krestianstvo.org/sdk/croquet/croquet-sn.3.mcm') install
3. Download and place an additional content from https://www.krestianstvo.org/sdk/croquet/Content.zip to the /Contents/Resources folder
4. In Objects will be the category Croquet to experiment with.

Preloaded Squeak image (version as of October 2018):

• All-In-One Squeak VM and image with preloaded Croquet and content: https://www.krestianstvo.org/sdk/croquet/Squeak5.2-18225-32bit-All-in-One-Croquet.zip

• Only Squeak image with preloaded Croquet: https://www.krestianstvo.org/sdk/croquet/Squeak5.2-18225-32bit-Croquet-Image.zip

Preloaded Squeak image (version as of February 2018):

• Squeak VM and image with preloaded Croquet and content: https://www.krestianstvo.org/sdk/croquet/CroquetForSqueak6-App-MacWin-32bit.zip

• Only Squeak image with preloaded Croquet and content: https://www.krestianstvo.org/sdk/croquet/CroquetForSqueak6-Image-resources.zip

• Only content (Textures, Models, etc.): https://www.krestianstvo.org/sdk/croquet/Content.zip

How to install manually:

1. Get the latest Squeak VM with included B3DAcceleratorPlugin(!)
   The preloaded app uses VM cog.spur 32 bit for Mac/Windows:

• Win: https://bintray.com/opensmalltalk/vm/download_file?file_path=squeak.cog.spur_win32x86_201802232356.zip
• Mac: https://bintray.com/opensmalltalk/vm/download_file?file_path=squeak.cog.spur_macos32x86_201802232356.dmg

2. Get the latest Squeak 6.x image from http://files.squeak.org/6.0alpha/
   The preloaded app uses http://files.squeak.org/6.0alpha/Squeak6.0alpha-17606-32bit/

3. Run Squeak.

4. In Workspace DoIt:
   (Installer fromUrl: 'http://sdk.krestianstvo.org/sdk/croquet/croquet-sn.2.mcm') install

This will load FFI, OpenGL and Croquet packages from the project's repository "Croquet for Squeak 6.x".

MCHttpRepository
location: 'http://sdk.krestianstvo.org/sdk/croquet'
user: ''
password: ''

Or you could manually load FFI at first:

(Installer repository: 'http://source.squeak.org/FFI')
install: 'FFI-Pools';
install: 'FFI-Kernel';
install: 'FFI-Tests'.

and then only OpenGL and Croquet packages:
(Installer fromUrl: 'http://sdk.krestianstvo.org/sdk/croquet/croquet-sn.1.mcm') install

5. Open 'Objects' in Squeak and choose 'Croquet' category.
   Drag Croquet(Master) or Demo(Master) onto the empty space.

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 library 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.

LiveCoding.space

Source code at GitHub

Code for using in original VWF

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: https://livecoding.space

Simple scenario for collaboration:

• Open in Web-browser the given URL (http://demo.krestianstvo.org)
• Copy the generated URL and open it in another browser window
  or direct Web-browser to http://demo.krestianstvo.org/app,
  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:

extends: http://vwf.example.com/aframe/ascene.vwf
properties:
children:
  spaceText:
    extends: http://vwf.example.com/aframe/atext.vwf
    properties:
      value: "Virtual World Framework & A-Frame"
      textColor: "#b74217"
      position: [-2, 2.5, -2]
  sphere:
    extends: http://vwf.example.com/aframe/asphere.vwf
    properties:
      position: [1, 1.25, -4]
      color: "#e0e014"
      radius: 1
      wireframe: true
    children:
      box2:
        extends: http://vwf.example.com/aframe/abox.vwf
        properties:
          position: [2, -1.25, 0]
          color: "#2167a5"
          depth: 1
  sky:
    extends: http://vwf.example.com/aframe/asky.vwf
    properties:
      color: "#ECECEC"
  camentity:
    extends: http://vwf.example.com/aframe/aentity.vwf
    properties:
      position: [0, 0, 0]
    children:
      camera:
        extends: http://vwf.example.com/aframe/acamera.vwf
        properties:
          look-controls-enabled: true
          forAvatar: true
        children:
          cursor:
            extends: http://vwf.example.com/aframe/acursor.vwf 

A year has passed as the first prototype of integration of Virtual World Framework & Ometa was presented at SPLASH'14 Future Programming Workshop. In 2015 the new version or "subling" of an Object-Oriented Language for Pattern Matching Ometa was publicly introduced with the name Ohm. As OMeta, it supports the same object-oriented grammar extension and allows pattern matching on structured data as well as strings, but now it also features a complete separation of grammars from semantic actions and a lot more.

In this post I want to present an updated prototype, which now uses the new language Ohm!

To try out, just open this link in the web browser and enter the virtual world containing a simple L-System generator. To modify the world, you could clone it or create your own and use the "Content Library" from the left side GUI for dragging L-System's entities.

You could modify any parameters of a selected L-System's entity in realtime, like: angle, iteration, axioms. Even more, you could redefine a grammar using the Script Editor, while not disrupting other entities.

First steps tutorial

Here is a simple tutorial on how to attach your own grammar with corresponding semantics actions to an entity inside virtual world using ADL Sandbox and Ohm language integration prototype. As an example we will use the Arithmetic calculator grammar from the Ohm language tutorial.
So, in this tutorial we'll define the grammar for parsing simple arithmetic expressions from string; add an operation to it's semantics that can be used to evaluate the provided arithmetic expressions; attach it to the virtual worlds's entity and show the result of evaluation in itself.
The working tutorial for cloning is here: http://live.net.ru/adl/sandbox/world/WRpbHEuHfYGmUm54

At first, please register at http://live.net.ru the project of http://www.krestianstvo.org.
Being registered you could create your own virtual worlds or clone an existed ones to experiment with.

1. Create a world using web interface and enter it:

2. Inside a virtual world create a 3D Text entity for matching grammar and showing our calculator's result:

3. Open Script Editor for the selected object (3D text) and create a new property for it with the name: ohmCalc. The name of the grammar should be necessarily starts with the 'ohm' prefix! As it points the Virtual World Framework model driver to provide ohm language stuff for the selected entity (actually Ohm language driver is loaded at world startup and makes an access to Ohm trough _ohm global variable). In this tutorial the grammar object is automatically generated and stored in Calc property.
Copy the provided Arithmetic grammar's source code into the property ohmCalc:

Arithmetic grammar's source code:

Arithmetic {
  Exp
    = AddExp
    
  AddExp
    = AddExp "+" MulExp  -- plus
    | AddExp "-" MulExp  -- minus
    | MulExp

  MulExp
    = MulExp "*" ExpExp  -- times
    | MulExp "/" ExpExp  -- divide
    | ExpExp

  ExpExp
    = PriExp "^" ExpExp  -- power
    | PriExp

  PriExp
    = "(" Exp ")"  -- paren
    | "+" PriExp   -- pos
    | "-" PriExp   -- neg
    | ident
    | number
    
  ident  (an identifier)
    = letter alnum*

  number  (a number)
    = digit* "." digit+  -- fract
    | digit+             -- whole
}

4. Create new method, in which we will define an operation for our calculator semantics. The semantics is accessible trough automatic generated entity's property at Engine.getProperty(this.id, 'semanticsCalc'). Copy the provided code of 'interpret' operation into the new method with the name addOperationCalc

addOperationCalc source code:

function addOperationCalc()
{   
 
    var constants = {pi: Math.PI, e: Math.E};
    var s = _LangManager.ohmLangs[this.id]["Calc"]["semantics"];

s.addOperation('interpret', {
      Exp: function(e) {
        return e.interpret();  
      },
      AddExp: function(e) {
        return e.interpret();
      },
      AddExp_plus: function(x, _, y) {
        return x.interpret() + y.interpret();
      },
      AddExp_minus: function(x, _, y) {
        return x.interpret() - y.interpret();
      },
      MulExp:        function(e)       { return e.interpret(); },
      MulExp_times:  function(x, _, y) { return x.interpret() * y.interpret(); },
      MulExp_divide: function(x, _, y) { return x.interpret() / y.interpret(); },
      ExpExp:        function(e)       { return e.interpret(); },
      ExpExp_power:  function(x, _, y) { return Math.pow(x.interpret(), y.interpret()); },
      PriExp:        function(e)       { return e.interpret(); },
      PriExp_paren:  function(_, e, _) { return e.interpret(); },
      PriExp_pos:    function(_, e)    { return e.interpret(); },
      PriExp_neg:    function(_, e)    { return -e.interpret(); },
      ident: function(_, _) {
        return constants[this.interval.contents] || 0;
      },
      number: function(_) {
        return parseFloat(this.interval.contents);
      }
    });
}

5. Next, we need to add the function call to addOperationCalc() from initGrammarCalc() and call it. After adding, press Call Method button.

function initGrammarCalc()
{
    //console.log('Init grammar: Calc');
    this.addOperationCalc();
}

6. Now, we are ready to test our grammar and it semantic's operation 'interpret()'. Create the new method with following source code and press Call Method button.

function test()
{
    var str = '(5+7)*4';
    var gram = _LangManager.ohmLangs[this.id]["Calc"]["grammar"];
    var sem = _LangManager.ohmLangs[this.id]["Calc"]["semantics"];
    var r = gram.match(str);
    var n = sem(r);
    this.text = n.interpret();
}

If everything is ok, you should see the string expression evaluation in 3d Text entity.

If something is not working in provided steps, please look at working tutorial here

Thanks for reading!