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

Visual structural editing for Guix (and Schemes in general)

2024-09-21T10:38:00Z

I've been noodling on structural editing for a while now. I'm fully bought into Lisps myself, but most of my friends and coworkers are skeptical, and I think a lot of their skepticism has to do (as usual) with all the parens. One of the points I make frequently is that with Lisp code being written as a nested data structure, the textual representation is just one of many possible representations. But it can be hard to get across what that means without concrete examples.

A few years back, I ran across Fructure for Racket. To this day, it's still the structural editor with the most appealing visual display to me. But Fructure itself has a few drawbacks for my purposes:

It's specifically targeting Racket. Racket is a wonderful Scheme, but I'm a Guix and Goblins user as well, and I would ideally like whichever editor I use to work with any Scheme, not just one.
It was a prototype, and its creator has mostly moved onto other projects.

In addition to these, I've been wanting a way to make Guix configuration as easy and painless as possible for new users. Having a sort of "command palette" available seems like it might be a good way to accomplish this.

So recently, I did a quick initial sketch of what such a system might look like:

I have a few initial use cases in mind:

Guix configuration, as particularly mentioned. Guix data structures (like operating-system or file-system) are written as Guix-specific record types, so there may be some metadata about expected values in each embedded in them that you can tap into somehow.
Content-addressed interfaces from the Spritely folks. This can make it more clear which methods are available to use on a remote Goblins object, and tying that into a visual command palette seems like it could be very nice.

Obviously given the fact that there are two styles of very different interfaces here, this has to involve some sort of runtime checking. And we probably can't entirely infer which to use based solely on the source code, so there's probably some per-project editor configuration needed for this to work. But... I think this might be doable.

I need to look into this some more, but a good starting point might be the nREPL protocol. It seems pretty extensible, and already has support for symbol lookups and such. But need to look into this all some more!

Terracrypt

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

Visual structural editing for Guix (and Schemes in general)