A Sketch of Running Folk on Synit
My programming life at the moment has been split between the worlds of Syndicate and Folk. They are both reactive programming systems that have a ton of conceptual overlap, so I have been trying to figure out a way to combine the two in a nice way so that I can eventually utilize the Ambient Networking, Graphics, and Audio work I’ve been iterating on in Syndicate world, from Folk, and use the physical interface Folk provides to interact with Syndicate actors.
The main barrier to a clean Syndicate <-> Folk integration is that both have their own unique way of managing assertions. Syndicate has a special actor called a “dataspace” which is a process that distributes Preserves messages across actors that are observing patterns. Folk manages assertions in it’s own internal database, and it’s observation system is based on pattern matching against strings. Folk also has no idea of “Capabilities” and messages, everything is an assertion implicitly sent to the database, which makes it significantly less verbose, but adds additional barriers towards Syndicate <-> Folk integration.
To bring these two systems together, I want to propose a way to use smoke and mirrors to make it seem like the Folk process is actually asserting to a connected Syndicate dataspace, while in most cases not impacting the performance of Folk’s internal db. We could do this by creating an internal Folk process that creates a bridge to a Syndicate dataspace using sycl. The implementation will likely be similar to the Folk <-> MQTT bridge, written by Jacob Haip: https://folk.computer/notes/mqtt
We will also need a way to translate Folk strings into Preserves types and vice versa. A good starting point for a Folk Preserves translation could be a Record
that is type Folk
and contains one or more strings. Here’s a quick example:
Folk syntax:
Claim $this is outlined blue
Preserves Text Syntax translation, this is what will be sent to/from a Syndicate dataspace actor:
<Folk "1241234" "is" "outlined" "blue">
A Syndicate Pattern that matches that Folk claim would look like this:
<Folk @id #:any "is" "outlined" "blue">
In true Folk fashion, I crafted two paper demos of how the Syndicate <-> Folk dance might go:
First, observing a Folk Claim
from syndicate-py
:
And the reverse, making a Claim
from sycl
, to Folk, note that the example tcl program uses a claim
function that doesn’t yet exist. This will be implemented on top of sycl
’s existing during
entity.
At a high level, I believe the new Synit-NixOS project will be an ideal host environment for hosting a Folk VM, it will provide a reactive db to interact with Linux utilities in a much more Folk-y way than it currently has to. The reproducible environment NixOS provides will also hopefully remove a lot of the pure “linux issues” that fresh installs of Folk on hardware often bring.
Eventually I will need to come up with a syntax for sending and receiving Syndicate messages from inside Folk (what would the Folk equivalent of a message be?), and also a syntax for doing capabilities (we’ll need the ability to assert to arbitrary dataspace actors eventually). But the abilities listed above (e.g. hardcoded dataspace and no message support) will be a good start.