Terracrypt

Horton persistence progress

2025-12-27T12:03:00Z

I've gotten some work done towards supporting persistence in guile-horton over the last week or so, but I've hit a bit of a roadblock. Writing this up in part to explain what I've been working on and in part to think through it some more.

To support persistence, I need to switch all the actors in the system over to use the define-actor macro. The admin actor was previously using selfish-spawn, but define-actor has a #:self parameter that should serve the same purpose. And the old code was using an internal cell for the mutable name functionality, which needs to be changed.

However... running into one particular problem that I'm still having trouble figuring out. When I spawn an admin, that new object also spawns a profile with a reference to that admin. In order to support that, the admin needs to have a reference to itself; as mentioned above, I think I should be able to use a parameter on define-actor for that. But for some reason, the self parameter gets set to #<unspecified> when I try that. It's not clear to me why this might be happening from the docs, so I think I might need to do some source spelunking to figure it out.

Once I work that out, it looks like I'll run into this issue. It sounds like I should be able to work around that with a second object constructor, though it might be a bit messy.

This is part of my December Adventure 2025 series, which I haven't been as consistent with as I had hoped but has nudged me to work on this some at least! My adventure log for this year is here.

Adding persistence to gobs-of-machines

2025-02-14T13:16:00Z

A couple updates on the gobs-of-machines work from a while back!

The smaller update of the two: I've renamed what I was calling "provisioners" to "providers". This is a bit of an attempt to align my terminology with that of other tools like Terraform. Ultimately when deploying real instances I'll need something to install/configure the hob-server component on the new machine, and it might make sense for that to be called a "provisioner". So I'm calling the part that interacts with cloud providers a "provider". So much of this terminology is overloaded in devops tooling, but so it goes. :)

But the bigger change: the program now supports persistence! In practice, this means that you can shut down and restart the program (primarily the boss), and when it comes back online it will remember the other instances that it's created.

This took a bit of troubleshooting (the errors you get when you forget something currently aren't as clear as they could be) but ultimately I was pleasantly surprised at how few changes I had to do to add persistence support!

The Goblins docs on persistence explain this in more detail than I can here, but the changes mostly boiled down to:

Defining persistence environments for each custom object (and their dependencies)
Using define-actor instead of define for each of my objects
Pulling some of the variable definitions within each object into the object's constructor as optional parameters
Spawning my objects in persistent vats

Walking through these:

Defining persistence environments

Each module that defines new objects needs to define a "persistence environment". For hob.scm, that looks like this:

(define hob-env
  (make-persistence-env
   `((((gobs-of-machines hob) ^hob-server-presence) ,^hob-server-presence)
     (((gobs-of-machines hob) ^hob-client-presence) ,^hob-client-presence))
   #:extends common-env))

This gives Goblins some information it needs to snapshot and rehydrate objects: the module that the object is found in, the name of that object's constructor within that module, and the "object rehydrator" - which seems to be a direct reference to the object's constructor.

We extend another persistence env, common-env, because the hob-client uses a ghash to store bindings. So we need to tell Goblins how to persist ghashes too, and (goblins actor-lib common) provides a persistence env for the objects defined there that we can inherit from.

Using `define-actor` and pulling more into object constructors

Goblins provides a macro called define-actor that handles a lot of the persistence machinery for us. Using it in practice for e.g. the hob-client-presence meant changing from this:

(define (^hob-client-presence bcom)
  (define bindings (spawn ^ghash))

...to this:

(define-actor (^hob-client-presence bcom #:optional (bindings (spawn ^ghash)))

Instead of using an inner definition, I'm defining the bindings hash table as an optional parameter to the object constructor, with its default value set to a newly spawned ghash. To quote the Goblins manual:

In most cases, and usually when using ‘define-actor’, we need to think the behavior and state being determined by the constructor, not relying on internal state.

When the program starts, Goblins will recreate each object by spawning a new object with the same parameters, so moving state like this into the constructor allows it to recreate the previous state of the object.

Using persistent vats

This was the hardest part to work out.

To make use of Goblins's persistence features, you need to spawn your objects inside special vats that are persisted. The storage mechanism is pluggable, but for the time being the only one that actually saves to disk is the syrup-store, so for now I'm using that. Spawning a syrup-store looks like this:

(define dummy-vat-store (make-syrup-store "/tmp/gobs-dummy-state"))

If I only had one vat to deal with, this (along with the persistence environment stuff mentioned in an earlier section) would be all that I would need to spawn a persistent vat. However, I had previously designed the application such that the dummy-machine and hob-client objects lived in a separate vat, to roughly simulate the fact that in reality these would be running on the newly provisioned machine.

Goblins persists one vat at a time, so what do you do when you have objects in two different vats holding references to each other? Well, there is a mechanism for that too - you can make use of something called a persistence-registry:

(define persistence-vat (spawn-vat))
(define persistence-registry
  (with-vat persistence-vat
            (spawn ^persistence-registry)))

And then each time you spawn a new persistent vat, you pass a reference to the persistence registry into the spawn-persistent-vat call:

(define-values (dummy-vat dummy-provider)
  (spawn-persistent-vat
   dummy-env
   (lambda ()
     (spawn ^dummy-provider))
   dummy-vat-store
   #:persistence-registry persistence-registry))

One noteworthy thing about spawn-persistent-vat is that when using it, you spawn the first object in the vat at the same time as the vat itself. This first object acts as the "root" of the persistence graph, and for other objects in this vat to be persisted, this first object needs to hold a reference to them. (This will be important later.)

Also, If you're paying close attention, you may notice that this isn't where the dummy-provider was previously spawned, and there's a reason for that.

Previously, I was creating a new vat for each new machine, and this became a problem, because vats aren't in the list of data types that can appear in a persistence graph! (Even persistent vats, it seems - though I wonder if that could be supported at some point or if there are hurdles to implementing that.)

So I had to refactor a bit. Now, the boss takes an extra providers parameter, which is a ghash whose keys are each the provider name and the values are references to a provider object:

(define-actor (^boss bcom #:key [providers (spawn ^ghash)] [machines (spawn ^ghash)])

Essentially I'm sidestepping the above limitation by spawning the dummy-provider in a new persistent vat first, and then passing it into the boss as an argument (with the dummy-provider modified to spawn each new dummy-machine in the same vat rather than spawning a new one each time).

And then, having done that, we can spawn the persistent vat our boss will live in:

(define syrup-store (make-syrup-store "/tmp/gobs-state"))
(define-values (my-vat my-boss)
  (spawn-persistent-vat
   boss-env
   (lambda ()
     (let* ((ht (spawn ^ghash)))
       ($ ht 'set 'dummy dummy-provider)
       (spawn ^boss #:providers ht)))
   syrup-store
   #:persistence-registry persistence-registry))

Now, the thing that had me scratching my head for a while had to do with a little quirk of that vat independence I mentioned earlier, as well as with the requirement that the root retain a reference to objects in that vat that will be persisted. Previously, when creating a new machine, the hob-server for the new machine would ultimately get a reference to the new hob-client. But the provider wasn't keeping a reference to that newly created hob-client anywhere, and so when rehydrating the object graph it didn't come back.

Fixing this just involved making the dummy-machine object persist its hob-client and making the dummy-provider persist each of the dummy-machines, but it took a little bit of puzzling to figure out.

Persistence in action

Phew! Having made those changes, persistence now works:

scheme@(gobs-of-machines main)> (define-values (vat boss) (start-daemon))
scheme@(gobs-of-machines main)> ,enter-vat vat
Entering vat '2'.  Type ',q' to exit.  Type ',help goblins' for help.
goblins/2@(gobs-of-machines main) [1]> ($ boss 'create-machine "test")
dummy-provider: In a real implementation, this would talk to a cloud provider
goblins/2@(gobs-of-machines main) [1]> dummy-machine: Creating new machine
dummy: Registered new client machine

goblins/2@(gobs-of-machines main) [1]> ($ boss 'list-machines)
$6 = ("test")

<...then after killing and restarting the repl...>

scheme@(gobs-of-machines main)> (define-values (vat boss) (start-daemon))
scheme@(gobs-of-machines main)> ,enter-vat vat
Entering vat '2'.  Type ',q' to exit.  Type ',help goblins' for help.
goblins/2@(gobs-of-machines main) [1]> ($ boss 'list-machines)
$6 = ("test")

Success!

Obviously, there are still a couple tweaks that need to be made before this is really useful as a standalone application. There are some hardcoded /tmp filenames lying around for the two persistent vats; the location for those needs to be configurable. It still needs a command-line entrypoint and a config file, so you can start and configure it from outside a REPL. And it still needs at least one real provider implementation! But it's a start. :)

Smalltalk and capabilities: a vision of a road not taken for desktop computing (and beyond?)

2024-10-27T23:13:00Z

This is my submission for the Malleable Systems Collective's "Fearless extensibility" challenge problem.

I've had a brainworm for the last few years that's been bugging me. Way back in this blog post, I linked a video that demoed an early Smalltalk system. The most mind-blowing thing about that demo for me was that, on those early systems, you could make connections between and thus compose different graphical widgets.

I recommend watching the video to really see it in action, but it looked like this:

At this point in the demo, Alan Kay is using a picture editor widget to edit a specific frame of a bouncing ball animation. These aren't applications in the sense that we'd think of them today; they're separate pieces of software that are nonetheless working together.

This really underscored to me that the conventional UI wisdom I was familiar with (that command lines are composable and GUIs are not) wasn't the whole story. It would be more accurate to say that today's GUIs are not composable, but GUIs in general certainly can be - it's just a different point in the design space!

Of course, this Smalltalk system was designed in the 70s for a very different computing landscape than the one we have today. Notably, at the time, you wouldn't have been running much software that wasn't written by either you or the computer vendor. The commercial software industry wasn't really a thing yet! Contrast that with the computers of today, where there's a very good chance that most of the software you're running isn't from Microsoft, or Apple, or whoever made your computer. And similarly, computers back then weren't used for nearly as many sensitive tasks as they are today; you wouldn't have been doing online banking from your Alto. In today's world, you might not want just any software you download to be able to modify anything else on your system in such a deep way.

There's a philosophy aiming to address this that I've been interested in for the last few years called the object-capability security model. If you're unfamiliar with the concept, I recommend reading What Are Capabilities by Chip Morningstar for a solid introduction. Something that comes up repeatedly in capability discussions is that ideally, capability transfer should happen via unambiguous user intent. The above blog post provides an example:

Imagine that when Word starts running it has no access at all to anything that’s access controlled – no files, peripheral devices, networks, nothing. When you double click the file icon or pick from the open file dialog, instead of giving Word a pathname string, the operating system itself opens the file and gives Word a handle to it (that is, it gives Word basically the same thing it would have given Word in response to the Open File API call when doing things the old way). Now Word has access to your document, but that’s all. It can’t send your file to Macedonia, because it doesn’t have access to the network – you didn’t give it that, you just gave it the document. It can’t delete or encrypt any of your other files, because it wasn’t given access to any of them either. It can mess up the one file you told it to edit, but it’s just the one file, and if it did that you’d stop using Word and not suffer any further damage. And notice that the user experience – your experience – is exactly the same as it was before. You didn’t have to answer any “mother may I?” security questions or put up with any of the other annoying stuff that people normally associate with security. In this world, that handle to the open file is an example of what we call a “capability”.

It strikes me that the inter-object Alto demo could be done in a capability-secure way! During the demo, we see a painter object and an animation object, and Alan Kay "draws a line" between the two objects. He inspects each object's properties to see what's available on each, and in the box in between the two objects, he establishes a link between the painter's picture and the animation's currentFrame. This feels compatible with a capability system!

One way that I can think of that this might work: the interface outside of each object is part of a more trusted system UI, which has references to each object it manages. By default, each visible object in this system need not have references to any other object, but the system UI (having references to both) can pass references between them. When you draw a line between objects and pass the currentFrame to the painter's picture (which happens outside the context of any particular object), the system UI would send the painter a reference to a part of the animation object.

By building a system like this, we might gain a few things:

Objects could be instantiated from untrusted authors with minimal authority by default. Until the user connects the new object to another, it need not be able to communicate with other objects in the system.
We'd regain the ability to deeply compose graphical software, even though the user may not fully trust the developer of the software they're using.

But, a few open questions that I have:

Could you model things like network access as just more objects in the system while making the UX reasonably straightforward? Maybe drawing a line to a network icon lets you do this?
- You may want the UI to be able to "minimize" connections between objects to avoid clutter.
Would some sort of structural editor in the "in-between" box be helpful for users? A blank text box is intimidating, but if the UI shows you what can go where with a menu (maybe Fructure-style?) it might help ease people into this.

There's a lot I don't know about how Smalltalk is implemented, and I'm sure there are a lot of details that would need to be worked out to implement something like this. But I think it's a path that could work, and it's something I'd like to see. :)