The Heart of Spritely: Distributed Objects and Capability Security

This is an extremely brief taste of what programming in Goblins is like. The following code is adapted from the Guile version of Goblins.⁹

To work with Goblins objects, a vat is required. Vats will be explained more later, but for now, think of a vat as a context for Goblins objects. Here's how to make and enter one interactively:

;; define with next argument *not* in parentheses
;; defines an ordinary variable
REPL> (define a-vat (spawn-vat))
REPL> ,enter-vat a-vat
REPL [1]>

;; define with next argument *not* in parentheses
;; defines an ordinary variable
REPL> define a-vat
_____   spawn-vat
REPL> ,enter-vat a-vat
REPL [1]>

Entering a vat introduces a new layer of abstraction to the REPL and creates a sub-REPL, indicated by [1]. Errors may result in the user entering a new debugger sub-REPL, also indicated by [1]. The number in brackets is incremented for each new sub-REPL. Any code examples in this document which use [1] should be run inside a vat - that is, after an ,enter-vat command like the one above - even if this command is not written out. You can exit a vat (or any sub-REPL) with ,q:

REPL [1]> ,q
REPL>

REPL [1]> ,q
REPL>

Note that this only works in an interactive context at a REPL. For how to work with vats statically - inside a file - see Appendix: Using vats in files.

Now, implement a friend who will greet you:

;; define with next argument wrapped in parentheses
;; defines a named function
(define (^greeter bcom our-name)    ; constructor (outer procedure)
  (lambda (your-name)               ; behavior    (inner procedure)
    (format #f "Hello ~a, my name is ~a!"     ; returned implicitly
            your-name our-name)))

;; define with next argument wrapped in parentheses
;; defines a named function
define (^greeter bcom our-name)    ; constructor (outer procedure)
  lambda (your-name)               ; behavior    (inner procedure)
    format #f "Hello ~a, my name is ~a!"     ; returned implicitly
           . your-name our-name

The outer procedure, defined by define, is named ^greeter, which is its constructor.¹⁰ The inner procedure, defined by the lambda (an "anonymous function"), is its behavior procedure, which implicitly returns a formatted string. Both of these are most easily understood by usage, so try instantiating one:¹¹

;; define with next argument *not* in parentheses
;; defines an ordinary variable
REPL [1]> (define gary (spawn ^greeter "Gary"))

;; define with next argument *not* in parentheses
;; defines an ordinary variable
REPL [1]> define gary
_________   spawn ^greeter "Gary"

As you can see, spawn's first argument is the constructor for the Goblins object which will be spawned. For now, ignore the bcom, which is not used in this first example. The rest of the arguments to spawn are passed in as the rest of the arguments to the constructor.¹² So in this case, "Gary" is passed as the value of our-name.

The constructor returns the procedure representing its current behavior. In this case, that behavior is a simple anonymous lambda. You can now invoke your gary friend using the synchronous call-return $ operator (not to be confused for a Unix command prompt):

REPL [1]> ($ gary "Alice")
;; => "Hello Alice, my name is Gary!"

REPL [1]> $ gary "Alice"
;; => "Hello Alice, my name is Gary!"

As you can see, "Alice" is passed as the value for your-name to the inner lambda behavior-procedure. Since our-name was already bound through the outer constructor procedure, the inner behavior is able to pass both of these names to format to give a friendly greeting.

Here is a simple cell which stores a value. This cell will have two methods: 'get retrieves the current value, and 'set replaces the current value with a new value.

(define (^cell bcom val)
  (methods            ; syntax for first-argument-symbol-based dispatch
    ((get)            ; takes no arguments
     val)             ; returns current value
    ((set new-val)    ; takes one argument, new-val
     (bcom (^cell bcom new-val)))))  ; become a cell with the new value

define (^cell bcom val)
  methods            ; syntax for first-argument-symbol-based dispatch
    (get)            ; takes no arguments
      . val          ; returns current value
    (set new-val)    ; takes one argument, new-val
      bcom : ^cell bcom new-val  ; become a cell with the new value

Try it. Cells hold values, and so do treasure chests, so make a treasure chest flavored cell. Taking things out and putting them back in is easy.

REPL [1]> (define chest (spawn ^cell "sword"))
REPL [1]> ($ chest 'get)
;; => "sword"
REPL [1]> ($ chest 'set "gold")
REPL [1]> ($ chest 'get)
;; => "gold"

REPL [1]> define chest
_________   spawn ^cell "sword"
REPL [1]> $ chest 'get
;; => "sword"
REPL [1]> $ chest 'set "gold"
REPL [1]> $ chest 'get
;; => "gold"

Now you can see what bcom is: a capability specific to this object instance which allows it to change its behavior! (For this reason, bcom is pronounced "become"!)¹³

methods was also new to this version. It turns out that methods is simply syntax sugar. There is nothing special about methods; you could easily write your own version or use it outside of Goblins objects to build general symbol-based-method-dispatch.¹⁴

Objects can also contain and define other object references, including in their outer constructor procedure.

Here is the definition of a "counting greeter" called ^cgreeter:

(define (^cgreeter bcom our-name)
  (define times-called   ; keeps track of how many times 'greet is called
    (spawn ^cell 0))     ; starts count at 0
  (methods
   ((get-times-called)
    ($ times-called 'get))
   ((greet your-name)
    (define current-times-called
      ($ times-called 'get))
    ;; increase the number of times called
    ($ times-called 'set
       (+ 1 current-times-called))
    (format #f "[~a] Hello ~a, my name is ~a!"
            ($ times-called 'get)
            your-name our-name))))

define (^cgreeter bcom our-name)
  define times-called   ; keeps track of how many times 'greet is called
    spawn ^cell 0       ; starts count at 0
  methods
    (get-times-called)
      $ times-called 'get
    (greet your-name)
      define current-times-called
        $ times-called 'get
      ;; increase the number of times called
      $ times-called 'set
        + 1 current-times-called
      format #f "[~a] Hello ~a, my name is ~a!"
             $ times-called 'get
             . your-name our-name

As you can see near the top, times-called is instantiated as an ^cell like the one defined earlier. The current value of this cell is returned by get-times-called and is updated every time the greet method is called:

REPL [1]> (define julius (spawn ^cgreeter "Julius"))
REPL [1]> ($ julius 'get-times-called)
;; => 0
REPL [1]> ($ julius 'greet "Gaius")
;; => "[1] Hello Gaius, my name is Julius!"
REPL [1]> ($ julius 'greet "Brutus")
;; => "[2] Hello Brutus, my name is Julius!"
REPL [1]> ($ julius 'get-times-called)
;; => 2

REPL [1]> define julius
_________   spawn ^cgreeter "Julius"
REPL [1]> $ julius 'get-times-called
;; => 0
REPL [1]> $ julius 'greet "Gaius"
;; => "[1] Hello Gaius, my name is Julius!"
REPL [1]> $ julius 'greet "Brutus"
;; => "[2] Hello Brutus, my name is Julius!"
REPL [1]> $ julius 'get-times-called
;; => 2

You have seen that the behavior of objects may be invoked synchronously with $. However, this only works if two objects are both defined on the same machine on the network and the same event loop within that machine. Since Goblins is designed to allow for object invocation across a distributed network, how is that done?

You can simulate a distributed context by creating and entering a new vat:

REPL [1]> ,q
REPL> (define b-vat (spawn-vat))
REPL> ,enter-vat b-vat

REPL [1]> ,q
REPL> define b-vat
_____   spawn-vat
REPL> ,enter-vat b-vat

This is where <- comes in. In contrast to $, <- can be used against objects which live anywhere, even on remote machines. However, unlike invocation with $, you do not get back an immediate result; you get a promise:

REPL [1]> (<- julius 'greet "Lear")
;; => #<local-promise>

REPL [1]> <- julius 'greet "Lear"
;; => #<local-promise>

This promise must be listened to. The procedure to listen to promises in Goblins is called on:

REPL [1]> (on (<- julius 'greet "Lear")
              (lambda (got-back)
                (format #t "Heard back: ~a\n" got-back)))
; prints (eventually):
;   Heard back: [4] Hello Lear, my name is Julius!

REPL [1]> on (<- julius 'greet "Lear")
_________   lambda (got-back)
_________     format #t "Heard back: ~a\n"
_________            . got-back
; prints (eventually):
;   Heard back: [4] Hello Lear, my name is Julius!

Not all communication goes as planned, especially in a distributed system. on also supports the keyword arguments of #:catch and #:finally, which both accept a procedure defining handling errors in the former case and code which will run regardless of successful resolution or failure in the latter case:

REPL> (define (^broken-bob bcom)
        (lambda ()
          (error "Yikes, I broke!")))
REPL> ,enter-vat a-vat
REPL [1]> (define broken-bob (spawn ^broken-bob))
REPL [1]> ,q
REPL> ,enter-vat b-vat
REPL [1]> (on (<- broken-bob)
              (lambda (what-did-bob-say)
                (format #t "Bob says: ~a\n" what-did-bob-say))
              #:catch (lambda (err)
                        (format #t "Got an error: ~a\n" err))
              #:finally (lambda ()
                          (display "Whew, it's over!\n")))
; prints (eventually):
;   Got an error: <error ...>
;   Whew, it's over!

REPL> define (^broken-bob bcom)
_____   lambda ()
_____     error "Yikes, I broke!"
REPL> ,enter-vat a-vat
REPL [1]> define broken-bob
_________   spawn ^broken-bob
REPL [1]> ,q
REPL> ,enter-vat b-vat
REPL [1]> on (<- broken-bob)
_________    lambda (what-did-bob-say)
_________      format #t "Bob says: ~a\n" what-did-bob-say
_________    . #:catch
_________    lambda (err)
_________      format #t "Got an error: ~a\n" err
_________    . #:finally
_________    lambda ()
_________      display "Whew, it's over!\n"
; prints (eventually):
;   Got an error: <error ...>
;   Whew, it's over!

Mistakes happen, and when they do, the damage should be minimal. But with many moving parts, accomplishing this can be difficult.

However, Goblins makes life easier. To see how, intentionally insert a couple of print debugging lines (with pk, which is pronounced and means "peek") and then an error:

(define (^borked-cgreeter bcom our-name)
  (define times-called (spawn ^cell 0))
  (methods
   ((get-times-called)
    ($ times-called 'get))
   ((greet your-name)
    (pk 'before-incr ($ times-called 'get))
    ;; increase the number of times called
    ($ times-called 'set
       (+ 1 ($ times-called 'get)))
    (pk 'after-incr ($ times-called 'get))
    (error "Yikes")
    (format #f "[~a] Hello ~a, my name is ~a!"
            ($ times-called 'get)
            your-name our-name))))

define (^borked-cgreeter bcom our-name)
  define times-called
    spawn ^cell 0
  methods
    (get-times-called)
      $ times-called 'get
    (greet your-name)
      pk 'before-incr : $ times-called 'get
      ;; increase the number of times called
      $ times-called 'set
        + 1 ($ times-called 'get)
      pk 'after-incr : $ times-called 'get
      error "Yikes"
      format #f "[~a] Hello ~a, my name is ~a!"
             $ times-called 'get
             . your-name our-name

Now spawn this friend and invoke it:

REPL> ,enter-vat a-vat
REPL [1]> (define horatio
            (spawn ^borked-cgreeter "Horatio"))
REPL [1]> ($ horatio 'get-times-called)
;; => 0
REPL [1]> ($ horatio 'greet "Hamlet")
;; pk debug: (before-incr 0)
;; pk debug: (after-incr 1)
;; ice-9/boot-9.scm:1685:16: In procedure raise-exception:
;;   Yikes
;; Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.

REPL> ,enter-vat a-vat
REPL [1]> define horatio
_____       spawn ^borked-cgreeter "Horatio"
REPL [1]> $ horatio 'get-times-called
;; => 0
REPL [1]> $ horatio 'greet "Hamlet"
;; pk debug: (before-incr 0)
;; pk debug: (after-incr 1)
;; ice-9/boot-9.scm:1685:16: In procedure raise-exception:
;;   Yikes
;; Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.

Whoops! Looks like something went wrong! You can see from the pk debugging that the times-called cell should be incremented to 1. And yet…

REPL [1]> ($ horatio 'get-times-called)
;; => 0

REPL [1]> $ horatio 'get-times-called
;; => 0

This is covered in greater detail later, but the core idea here is that synchronous operations run with $ are all done together as one transaction. If an unhandled error occurs, any state changes resulting from synchronous operations within that transaction will simply not be committed. This is useful, because it means most otherwise difficult cleanup steps are handled automatically.

This also sits at the foundation of Spritely Goblins' time travel debugging features. All of this will be discussed in greater detail in sections later in this document: The vat model of computation, Turns are cheap transactions, and Time-travel distributed debugging.

"Machines grow faster and memories grow larger. But the speed of light is constant and New York is not getting any closer to Tokyo."

— Mark S. Miller, Robust Composition: Towards a Unified Approach to Access Control and Concurrency Control

Promise pipelining¹⁵ provides two different features at once:

• A convenient developer interface for describing a series of asynchronous actions, allowing for invoking the objects which promises will point to before they are even resolved (sometimes before the objects even exist!)
• A network abstraction that eliminates many round trips¹⁶

Consider the following car factory, which makes cars carrying the company name of the factory:

;; Create a "car factory", which makes cars branded with
;; company-name.
(define (^car-factory bcom company-name)
  ;; The constructor for cars to create.
  (define (^car bcom model color)
    (methods                      ; methods for the ^car
     ((drive)                    ; drive the car
      (format #f "*Vroom vroom!*  You drive your ~a ~a ~a!"
              color company-name model))))
    ;; methods for the ^car-factory instance
  (methods                        ; methods for the ^car-factory
    ((make-car model color)       ; create a car
     (spawn ^car model color))))

;; Create a "car factory", which makes cars branded with
;; company-name.
define (^car-factory bcom company-name)
  ;; The constructor for cars to create.
  define (^car bcom model color)
    methods                      ; methods for the ^car
      (drive)                    ; drive the car
        format #f "*Vroom vroom!*  You drive your ~a ~a ~a!"
               . color company-name model
  ;; methods for the ^car-factory instance
  methods                        ; methods for the ^car-factory
    (make-car model color)       ; create a car
      spawn ^car model color

Here is an instance of this car factor called fork-motors. If you type this in, you'll see an error:

;; Interaction on machine A
REPL> ,enter-vat a-vat
REPL [1]> (define fork-motors (spawn ^car-factory "Fork"))

;; Interaction on machine A
REPL> ,enter-vat a-vat
REPL [1]> define fork-motors
_________   spawn ^car-factory "Fork"

Since asynchronous message passing with <- works across machines, it does not matter whether interactions with fork-motors are local or via objects communicating over the network. Treat fork-motors as living on a remote machine A, and so the following interactions will happen with invocations originating from the local machine B.

Send a message to fork-motors invoking the 'make-car method, receiving back a promise for the car which will be made, which we shall name car-vow (-vow being the conventional suffix given for promises in Goblins):

;; Interaction on machine B, communicating with fork-motors on A
REPL> ,enter-vat b-vat
REPL [1]> (define car-vow (<- fork-motors 'make-car "Explorist" "blue"))

;; Interaction on machine B, communicating with fork-motors on A
REPL> ,enter-vat b-vat
REPL [1]> define car-vow
_________   <- fork-motors 'make-car "Explorist" "blue"

So you have a promise to a future car reference, but not the reference itself. You would like to drive the car as soon as it rolls off the lot of the factory, which of course involves sending a message to the car.

Without promise pipelining, making use of the tools already shown (and following the pattern most other distributed programming systems use), you would end up with something like:

;; Interaction on machine B, communicating with A
REPL [1]> (on car-vow                    ; B->A: first resolve the car-vow
              (lambda (our-car)          ; A->B: car-vow resolved as our-car
                (on (<- our-car 'drive)  ; B->A: now you can message our-car
                    (lambda (val)        ; A->B: result of that message
                      (format #t "Heard: ~a\n" val)))))
; prints (eventually):
;   Heard: *Vroom vroom!*  You drive your blue Fork Explorist!

;; Interaction on machine B, communicating with A
REPL [1]> on car-vow                  ; B->A: first resolve the car-vow
_________   lambda (our-car)          ; A->B: car-vow resolved as our-car
_________     on (<- our-car 'drive)  ; B->A: now you can message our-car
_________       lambda (val)          ; A->B: result of that message
_________         format #t "Heard: ~a\n" val
; prints (eventually):
;   Heard: *Vroom vroom!*  You drive your blue Fork Explorist!

With promise pipelining, you can simply message the promise of the car directly. The first benefit can be observed from code compactness, in that you do not need to do an on of car-vow to later message our-car, you can simply message car-vow directly:

;; Interaction on machine B, communicating with A
REPL [1]> (on (<- car-vow 'drive)     ; B->A: send message to future car
              (lambda (val)             ; A->B: result of that message
                (format #t "Heard: ~a\n" val)))
; prints (eventually):
;   Heard: *Vroom vroom!*  You drive your blue Fork Explorist!

;; Interaction on machine B, communicating with A
REPL [1]> on (<- car-vow 'drive)     ; B->A: send message to future car
_________   lambda (val)             ; A->B: result of that message
_________     format #t "Heard: ~a\n" val
; prints (eventually):
;   Heard: *Vroom vroom!*  You drive your blue Fork Explorist!

While clearly a considerable programming convenience, the other advantage of promise pipelining is a reduction of round-trips, whether between event-loop vats or across machines on the network.

This can be understood by looking at the comments to the right of the two above code interactions. The message flow in the first case looks like:

B => A => B => A => B

The message flow in the second case looks like:

B => A => B

In other words, machine B can say to machine A: "Make me a car, and as soon as that car is ready, I want to drive it!"

With this in mind, the promise behind Mark Miller's quote at the beginning of this section is clear. If two objects are on opposite ends of the planet, round trips are unavoidably expensive. Promise pipelining both allows us to make plans as programmers and allows for Goblins to optimize carrying out those steps as bulk operations over the network.

Thy wee bit heap o' leaves an' stibble,
Has cost thee mony a weary nibble!
Now thou's turn'd out, for a' thy trouble,
But house or hald,
To thole the winter's sleety dribble,
An' cranreuch cauld!

But, Mousie, thou art no thy-lane,
In proving foresight may be vain;
The best-laid schemes o' mice an' men
Gang aft agley,
An' lea'e us nought but grief an' pain,
For promis'd joy!

Still thou art blest, compar'd wi' me
The present only toucheth thee:
But, Och! I backward cast my e'e.
On prospects drear!
An' forward, tho' I canna see,
I guess an' fear!

— From "To a Mouse, on Turning Her Up in Her Nest With the Plough" by Robert Burns, 1785

Unexpected behavior can cause a cascade of failures. In a synchronous call-return system with exceptions, raising an exception causes not only the current procedure invocation to fail, but further invocations up the chain until the exception is caught (and if uncaught, possibly by allowing the program as a whole to fail). While potentially frustrating to encounter as a programmer or user, the alternative of proceeding without mitigating unhandled behavior could be equally disastrous. Still, if you interpret each procedure as voluntarily "sending a message to its caller" that something has gone awry, you can see the great service that each callee performs for its caller (such a pattern is common when a language does not provide implicit exception support), allowing the caller to make new plans, or at least not move forward under assumptions that no longer hold. Even unhandled exceptions, observed by the programmer, can be an opportunity to study and make new plans so that things may work better next time.

In a highly asynchronous networked environment, the likelihood of unanticipated failures grows substantially. Even with the most well implemented, bug-free locally implemented code (itself usually less likely a possibility than its authors may think), network connections are fickle, and remote objects may misbehave. As such, if a promise is broken, a pipelined message to that promise will have nowhere to go. This too should be interpreted as a failure and handled correctly.

As an example of this, consider this broken implementation of a car factory:

(define (^borked-car-factory bcom company-name)
  (define (^car bcom model color)
    (methods                      ; methods for the ^car
     ((drive)                    ; drive the car
      (format #f "*Vroom vroom!*  You drive your ~a ~a ~a!"
              color company-name model))))
  ;; methods for the ^car-factory instance
  (methods                        ; methods for the ^car-factory
   ((make-car model color)       ; create a car
    (error "Your car exploded on the factory floor!  Ooops!")
    (spawn ^car model color))))

define (^borked-car-factory bcom company-name)
  define (^car bcom model color)
    methods                      ; methods for the ^car
      (drive)                    ; drive the car
        format #f "*Vroom vroom!*  You drive your ~a ~a ~a!"
               . color company-name model
  ;; methods for the ^car-factory instance
  methods                        ; methods for the ^car-factory
    (make-car model color)       ; create a car
      error "Your car exploded on the factory floor!  Ooops!"
      spawn ^car model color

What would happen if you tried making a car using this factory and then pipeline a message to drive it?

REPL [1]> (define forked-motors (spawn ^borked-car-factory "Forked"))
REPL [1]> (define car-vow (<- forked-motors 'make-car "Exploder" "red"))
REPL [1]> (define drive-noise-vow (<- car-vow 'drive))
REPL [1]> (on drive-noise-vow
                (lambda (val)
                  (format #t "Heard: ~a\n" val))
              #:catch (lambda (err)
                        (format #t "Caught: ~a\n" err)))
; prints (eventually):
;   Caught: <error...>

REPL [1]> define forked-motors
_________   spawn ^borked-car-factory "Forked"
REPL [1]> define car-vow
_________   <- forked-motors 'make-car "Exploder" "red"
REPL [1]> define drive-noise-vow
_________   <- car-vow 'drive
REPL [1]> on drive-noise-vow
_________    lambda (val)
_________      format #t "Heard: ~a\n" val
_________    . #:catch
_________    lambda (err)
_________      format #t "Caught: ~a\n" err
; prints (eventually):
;   Caught: <error...>

Even though it is car-vow which is initially broken, its exception propagates to drive-noise-vow. Since there would be no useful way to drive a broken promise of a car anyhow, this is the correct design, and the situation can be detected and dealt with.

Lauren Ipsdale has decided to run a newspaper for her local community. The first thing Lauren will need is a way to construct individual posts which can be widely read, but edited only by trusted editors.

Lauren creates a new post:

REPL [1]> (define-values (day-in-park-post day-in-park-editor)
            (spawn-post-and-editor
             #:title "A Day in the Park"
             #:author "Lauren Ipsdale"
             #:body "It was a good day to take a walk..."))

REPL [1]> define-values (day-in-park-post day-in-park-editor)
_________   spawn-post-and-editor
_________     . #:title "A Day in the Park"
_________     . #:author "Lauren Ipsdale"
_________     . #:body "It was a good day to take a walk..."

(Implementation details of these blogposts will follow, but first this tutorial will focus on narrative and use.)

spawn-post-and-editor returned two capabilities:

• day-in-park-post, which grants the authority to read Lauren's blogpost, but not to make changes to it.
• day-in-park-editor, which grants the authority to modify the blogpost.

Lauren wants the feedback of her friend Robert, but wants to decide whether or not to make or accept any changes herself. She shares day-in-park-post with Robert. Robert is able to view the post by running:

REPL [1]> (display-post day-in-park-post)

REPL [1]> display-post day-in-park-post

Which prints out:

A Day in the Park
=================
  By: Lauren Ipsdale

It was a good day to take a walk...

Robert tells Lauren that he likes the blogpost, but that "a fine day" might sound more pleasant than "a good day" for the article's opening, and that maybe the name of the post should be "A Morning in the Park". Robert, not having access to day-in-park-editor, cannot make the changes himself.

Lauren deliberates on this feedback and decides that she agrees with the suggestion to change "good" to "fine" but that she thinks her title is good as-is. Lauren makes the change:

REPL [1]> ($ day-in-park-editor 'update
             #:body "It was a fine day to take a walk...")

REPL [1]> $ day-in-park-editor 'update
_____       . #:body "It was a fine day to take a walk..."

Of course, a blogpost on its own is not itself a blog or newspaper. Lauren wants a collection of updated posts, not just a singular entry. Time to make the blog!

Lauren invokes spawn-blog-and-admin:

REPL [1]> (define-values (maple-valley-blog maple-valley-admin)
            (spawn-blog-and-admin "Maple Valley News"))

REPL [1]> define-values (maple-valley-blog maple-valley-admin)
_____       spawn-blog-and-admin "Maple Valley News"

spawn-blog-and-admin returns two capabilities. The first is for the blog itself, which Lauren has locally bound to the variable maple-valley-blog, and which only grants read access to the current set of posts. maple-valley-admin provides the ability to curate the set of posts itself. Lauren has a certain vision and standard of post quality she'd like to see held for Maple Valley News but would like it to be widely read, and thus she will share and encourage wide dissemination of the former capability but will more carefully guard the latter capability.

Since maple-valley-blog has just been initialized, it unsurprisingly reports having no posts:

REPL [1]> ($ maple-valley-blog 'get-posts)
; => ()

REPL [1]> $ maple-valley-blog 'get-posts
; => ()

Since Lauren is now happy with day-in-park-post, she can add it via maple-valley-admin, and maple-valley-blog will now report the new post's addition:

REPL [1]> ($ maple-valley-admin 'add-post day-in-park-post)
REPL [1]> ($ maple-valley-blog 'get-posts)
; => (#<local-object ^post>)

REPL [1]> $ maple-valley-admin 'add-post day-in-park-post
REPL [1]> $ maple-valley-blog 'get-posts
; => (#<local-object ^post>)

The blog can now also be read with display-blog:

REPL [1]> (display-blog maple-valley-blog)

REPL [1]> display-blog maple-valley-blog

Which prints the following:

***********************
** Maple Valley News **
***********************

A Day in the Park
=================
  By: Lauren Ipsdale

It was a fine day to take a walk...

Robert tells Lauren he'd love to make an article of his own, and Lauren says she'd love to read it and see about including it. Robert pens a new post:

;; Run by Robert:
REPL [1]> (define-values (spelling-bee-post spelling-bee-editor)
             (spawn-post-and-editor
              #:title "Spelling Bee a Success"
              #:author "Robert Busyfellow"
              #:body "Maple Valley School held its annual spelling bee..."))

;; Run by Robert:
REPL [1]> define-values (spelling-bee-post spelling-bee-editor)
_________  spawn-post-and-editor
_________    . #:title "Spelling Bee a Success"
_________    . #:author "Robert Busyfellow"
_________    . #:body "Maple Valley School held its annual spelling bee..."

Robert sends this to Lauren for review. Lauren says that it's good, but could use a catchier title. Robert's years of community newspaper reporting leaves him with exactly the right idea for a change:

;; Run by Robert:
REPL [1]> ($ spelling-bee-editor 'update
             #:title "Town Buzzing About Spelling Bee")

;; Run by Robert:
REPL [1]> $ spelling-bee-editor 'update
_________   . #:title "Town Buzzing About Spelling Bee"

Lauren checks the post and decides it's ready to go. She adds it to the blog:

REPL [1]> ($ maple-valley-admin 'add-post spelling-bee-post)

REPL [1]> $ maple-valley-admin 'add-post spelling-bee-post

Now maple-valley-blog is starting to look like it's got some real content going!

REPL [1]> (display-blog maple-valley-blog)

REPL [1]> display-blog maple-valley-blog

***********************
** Maple Valley News **
***********************

Town Buzzing About Spelling Bee
===============================
  By: Robert Busyfellow

Maple Valley School held its annual spelling bee...


A Day in the Park
=================
  By: Lauren Ipsdale

It was a fine day to take a walk...

One implication from the way this code is currently written is that the blog is mostly a kind of aggregator of posts. While Lauren added Robert's post to Maple Valley News's collection of blogposts, since Robert did not share the edit capability with Lauren, Lauren cannot edit the post if she discovers a problem.

This can be an acceptable design, but Lauren has decided that she would like to ensure that any posts that are on the blog are editable by her or any other admins she gives access to. She also does not want to have to keep track of which edit capability is associated with which post: if she is looking at a post and catches an error, she wants to be able to jump straight into correcting it. Lauren wants to make sure her blogging administration software helps her ensure she is only adding objects which uphold these properties.

Under this rearchitecture, the admin interface is directly involved in constructing new posts and editors:

REPL [1]> (define-values (bumpy-ride-post bumpy-ride-editor)
            (spawn-adminable-post-and-editor
             (maple-valley-admin
              #:title "Main Street's Bumpy Ride"
              #:author "Lauren Ipsdale")))

REPL [1]> define-values (bumpy-ride-post bumpy-ride-editor)
_________   spawn-adminable-post-and-editor
_________     . maple-valley-admin
_________     . #:title "Main Street's Bumpy Ride"
_________     . #:author "Lauren Ipsdale"

Using this approach, Lauren could edit bumpy-ride-post using bumpy-ride-editor, but she does not need to since she can also use maple-valley-admin to edit:

REPL [1]> ($ maple-valley-admin 'edit-post
             bumpy-ride-post
             #:body "Anyone who's driven on main street recently...")

REPL [1]> $ maple-valley-admin 'edit-post
_________   . bumpy-ride-post
_________   . #:body "Anyone who's driven on main street recently..."

This new code also provides an assurance that any blogposts which are added are created through the internals of the code which runs "Maple Valley News". It will not be possible for any other object to spoof being a post which will not grant a user of maple-valley-admin the ability to edit the post and still be added to the blog.

As a contrived example, pretend that a malicious actor wants to ruin Lauren's reputation and has somehow gotten access to a few pieces of the blog infrastructure, but only has access to the add-post method of maple-valley-admin. This is the best they can do:

REPL [1]> (define-values (mallet-seal mallet-unseal mallet-sealed?)
            (make-sealer-triplet))
REPL [1]> (define-values (shmaple-shmalley-post shmaple-smalley-editor)
            (spawn-post-and-editor-internal
             mallet-seal
             #:title "Maple Valley More Like Shmaple Shmalley"
             #:author "Lauren Ipsdale"
             #:body "I hate Maple Valley..."))
REPL [1]> (<- spoofed-maple-valley-admin
              'add-post shmaple-shmalley-post)
; => error: Self-proof not for this post ...

REPL [1]> define-values (mallet-seal mallet-unseal mallet-sealed?)
_________   make-sealer-triplet
REPL [1]> define-values (shmaple-shmalley-post shmaple-smalley-editor)
_________   spawn-post-and-editor-internal
_________     . mallet-seal
_________     . #:title "Maple Valley More Like Shmaple Shmalley"
_________     . #:author "Lauren Ipsdale"
_________     . #:body "I hate Maple Valley..."
REPL [1]> <- spoofed-maple-valley-admin 'add-post shmaple-shmalley-post
;;     => error: Self-proof not for this post ...

As you can see, while Mallet is able to make their own sealers and unsealers, these do not correspond to the admin object's sealer and unsealer. Because of this, they cannot be used for anything dangerous. In other words: Mallet does not have it, so they cannot use it!

Lauren decides that it may be time for her to not be the only person running things, but she wants to make sure that she can hold anyone she gives access to accountable for the decisions they make and, if something inappropriate happens, revoke that access.

Lauren realizes she can extend her system to accommodate this plan without rewriting any of the existing code. Instead she will define some new abstractions that compositionally extend the system that exists.

The first thing she will need is a logger.

REPL [1]> (define admin-log (spawn ^logger))

REPL [1]> define admin-log
_________   spawn ^logger

Robert has been a great collaborator and has expressed interest in helping run things. Lauren decides it's time to take him up on it.

Lauren uses a new utility, spawn-logged-revocable-proxy-pair, which can proxy any object and log actions associated with a username meaningful to Lauren:

REPL [1]> (define-values (admin-for-robert roberts-admin-revoked?)
            (spawn-logged-revocable-proxy-pair
             "Robert"            ; username Lauren holds responsible
             maple-valley-admin  ; object to proxy
             admin-log))         ; log to write to

REPL [1]> define-values (admin-for-robert roberts-admin-revoked?)
_________   spawn-logged-revocable-proxy-pair
_________     . "Robert"            ; username Lauren holds responsible
_________     . maple-valley-admin  ; object to proxy
_________     . admin-log           ; log to write to

The first of the two returned capabilities, admin-for-robert, is the one she sends Robert. The second, roberts-admin-revoked?, is the cell which defaults to false, but Lauren can set to be true at any time, at which point messages from Robert will no longer pass through.

Robert thanks Lauren for the capability and soon decides that Lauren's post would be better with a different title:

REPL [1]> (<- admin-for-robert 'edit-post bumpy-ride-post
              #:title "Main Street Takes Some Bumps")

REPL [1]> <- admin-for-robert 'edit-post bumpy-ride-post
_________    . #:title "Main Street Takes Some Bumps"

Later, Lauren suddenly notices with irritation that her blogpost isn't named what she remembered it being. She checks the log:

REPL [1]> ($ admin-log 'get-log)
; => ((*entry*
;      user "Robert"
;      object #<local-object ^admin>
;      args (edit-post #<local-object ^post>
;            #:title "Main Street Takes Some Bumps")))

REPL [1]> $ admin-log 'get-log
; => ((*entry*
;      user "Robert"
;      object #<local-object ^admin>
;      args (edit-post #<local-object ^post>
;            #:title "Main Street Takes Some Bumps")))

Lauren decides that Robert shouldn't be editing her or anyone else's posts on the blog until they've had a serious conversation.

REPL [1]> ($ roberts-admin-revoked? 'set #t)

REPL [1]> $ roberts-admin-revoked? 'set #t

Robert tries to make another edit to the blogpost and notices that it didn't go through. He sees a frustrated message in his inbox from Lauren and apologizes. The two of them agree on what the proper etiquette for editing someone else's post should be in the future and Lauren feels satisfied enough to renew Robert's access.

REPL [1]> ($ roberts-admin-revoked? 'set #f)

REPL [1]> $ roberts-admin-revoked? 'set #f

Some time has passed and Maple Valley News is doing well. Robert and Lauren have been knocking out a lot of well celebrated articles covering their community. Lauren is busy figuring out next steps for the newspaper, but Robert is exhausted and needs to go on the vacation he has long promised his family they would take. But Robert has an idea for a guest post article that could be published in his absence without having to interrupt Lauren.

Robert has a friend who works at the local school, Maple Valley Elementary, and has told Robert about how a young student named Matilda Sample won a distinguished prize in the regional science fair, assisted with the mentorship of her science teacher Mx. Beaker. Robert thinks this would be a great idea for a story. Robert asks if Matilda would be willing to write a story about her experience and whether Mx. Beaker would be willing to review and determine if and when the article would be good enough to publish.

Everyone agrees, so Robert sets everything up. Robert runs the following:

;; Robert's interactions
REPL [1]> (define-values (science-fair-post science-fair-editor
                                            science-fair-reviewer)
            (spawn-post-guest-editor-and-reviewer
             "Matilda Sample" admin-for-robert))

;; Robert's interactions
REPL [1]> define-values (science-fair-post science-fair-editor
_________                science-fair-reviewer)
_________   spawn-post-guest-editor-and-reviewer "Matilda Sample" admin-for-robert

Robert now sends out a message to Matilda and another to Mx. Beaker with the capabilities they will need:

• science-fair-post is given to both Matilda and Mx. Beaker and allows either of them to read the current state of the post.
• science-fair-editor is given to Matilda only; this allows Matilda to edit and author the post. This capability only allows Matilda to change the title and body, but not the author (which Robert has already set to "Matilda Sample"). However, this capability does not give Matilda the authority to publish the post.
• science-fair-reviewer is given to Mx. Beaker; this allows Mx. Beaker to approve and publish the post (but also will prevent future edits in the process). However, this capability does not give Mx. Beaker the authority to modify the post.

Matilda begins writing the post:

;; Matilda's interactions
REPL [1]> (<- science-fair-editor 'set-body
              "My name is Matilda and I am twelve. I won the science fair...")

;; Matilda's interactions
REPL [1]> <- science-fair-editor 'set-body
_________    . "My name is Matilda and I am twelve. I won the science fair..."

Matilda asks Mx. Beaker if it's good enough to publish. Mx. Beaker tells Matilda, not yet! The post needs a title, and Matilda's teacher explains how to make the post tell a more engaging and personal narrative.

Matilda updates the title and rewrites the body:

;; Matilda's interactions
REPL [1]> (<- science-fair-editor 'set-title
              "Winning the Middle School Science Fair: A Personal Account")
REPL [1]> (<- science-fair-editor 'set-body
              "At twelve years old, winning the local science fair has been...")

;; Matilda's interactions
REPL [1]> <- science-fair-editor 'set-title
_________    . "Winning the Middle School Science Fair: A Personal Account"
REPL [1]> <- science-fair-editor 'set-body
_________    . "At twelve years old, winning the local science fair has been..."

After another prompt for review, Mx. Beaker decides that the post now looks great and will be a great representation of both Matilda and the school. Feeling proud of their student, Mx. Beaker presses approve:

;; Teacher's interactions
REPL [1]> (<- science-fair-reviewer 'approve)

;; Teacher's interactions
REPL [1]> <- science-fair-reviewer 'approve

And the post goes live!

Readers of the blog will see the new post, and will be able to share it widely:

;; Widely runnable (by blog readers and those they share it with)
REPL [1]> (display-blog maple-valley-bloge)

;; Widely runnable (by blog readers and those they share it with)
REPL [1]> display-blog maple-valley-blog

Robert, still on vacation, receives a message from Lauren. "Hey, I just saw that blogpost go live! It looks great! But I see in the log that you posted it… didn't you promise you weren't going to work while you left on vacation?"

Robert smiles and types up a response. "Funny thing that… nice things can happen that serve multiple peoples' interests, and if you think far ahead enough, sometimes when you aren't even around…"

This tutorial has skipped over some important steps intentionally: there is no demonstration of setting up the network connections between parties, no demonstration of how to produce capability references which can be passed along offline, and no demonstration of how these posts might be persisted to long-term storage or upgraded.

Nonetheless, it is has shown some powerful things:

• Distributed objects defined by behavior and bound together through capabilities are sufficient to represent sophisticated and useful social interactions between multiple parties.
• The authorization mechanism relies on capability references and follows the "if you don't have it, you can't use it" philosophy. Sharing access remains as simple as reference passing. Everything is understandable as ordinary code.
• Despite the fact that the authorization mechanism itself is ambivalent about the identity of its participants, attribution of actions can be encoded into the system. Combined with a revocation mechanism, this permits accountability. This example also added broader group-style access to administer certain objects. All this without needing an access control list mechanism or the inherent ambient authority and confused deputy risks associated with such an approach.
• Goblins is able to encode rich, multi-stakeholder arrangements that benefit everyone. The guest post with a review example demonstrated that special use cases like this can occur layered on top of an existing system rather than requiring a messy rewrite of existing behavior.

If you're using a Unix-like operating system, you probably have a package manager with Guile available in its repositories - homebrew, apt, dnf, etc. The recommended way to obtain Guile is through such a package manager. Failing that, you may also download Guile source and then compile it according to the instructions in its manual. Note that while Goblins may work with Guile 2, it only supports Guile 3. You'll probably need a few unmentioned dependencies to compile it:

• a C compiler toolchain, such as GCC
• GNU Autotools

With those, inside the directory for the Guile source directory, you'll run the following commands:

> ./configure
> make
> make install

After that's done you can move on to…

Once again, the best route to obtaining Wisp is to use your system package manager where it likely has a name such as guile-wisp. However, you can also download its source code and compile it. This presupposes an extant Guile installation. Inside its source directory, you should be able to run:

> ./configure
> make
> make install

And finally you get to…

At the moment, Goblins is only packaged for Guix and Homebrew. The only alternative is to build it manually. Following the instructions in the Guile Goblins source repository, you'll need to obtain a few dependencies:

• Guile 3.0 (handled above)
• guile-gcrypt
• guile-fibers
• Tor (runtime; optional, for networking)
• git (implicitly)

Then it should be as straightforward as running the following commands:

> git clone https://gitlab.com/spritely/guile-goblins
> cd guile-goblins
> ./configure
> make
> make install

With all of that completed, you get a REPL to run the examples in this document as follows:

> guile --language=wisp

• Abstract Syntax Tree: The abstracted programming language structure which the programming language operates at. See also surface syntax.
• Actor: A computational entity that operates only via asynchronous message passing. See also actor model, defined below. An object which only communicates via asynchronous message passing is usually considered an actor.
• Actor model: A programming paradigm where computation occurs between fully asynchronous message passing between computational entities named actors. An actor operating under the classic actor model processes one incoming message at a time defined by its current behavior, and in response may create new actors (obtaining their addresses in the process), send messages to other actors (including introducing them to actors this actor knows about in the process), or specify a change of behavior in regard to its next message. (To distinguish this core, original, and general subset of possible variants, the term classic actor model is sometimes used.)
• Actormap: A transactional heap mapping object references to a set of behaviors.
• Access Control List (ACL): In contrast to object capability security, an Access Control List system relies on identity checks against approved operations. ACL systems tend to exhibit ambient authority and confused deputy vulnerabilities. See the paper ACLs Don't for an explanation of the many problems inherent to access control lists.
• Ambient authority: A source of vulnerabilities in many programs, particularly those operating under an ACL model of execution; ambient authority refers to authority that is implicitly available. Programs with ambient authority designs tend to be vulnerable to confused deputy attacks and usually fail to adhere to the principle of least authority, increasing the attack surface of a program dramatically. Since an object capability environment involves explicit use of references one holds and has access to, ambient authority risks are significantly smaller.
• Behavior: In Goblins, the behavior of the object is a procedure defining how it will currently react in response to an incoming message.
• Behavior-oriented: In contrast to a data-oriented system, a behavior-oriented system is primarily defined in terms of the behaviors of its participants and their relationships (which may both change over time). The mapping of references to behavior in Goblins is handled at a low level through the actormap (though this is a detail mostly hidden from users of Goblins). Behavior-oriented and data-oriented systems are duals, but the primary paradigm taken dramatically shapes the structure of the underlying architecture.
• Capability: See object capability.
• CapTP: Originally implemented in E, and now (as one layer of OCapN) implemented in Goblins, CapTP provides abstractions for distributed object programming which allow for programming against any object on the network to have the same ease and semantics as against locally hosted objects. Also provides some neat features such as distributed garbage collection and promise pipelining.
• Causeway: A distributed debugger implemented in E and a source of inspiration to Goblins' distributed debugger.
• Classic actor model: See actor model.
• Client-to-server: A network architecture where certain participants on the network have elevated, structurally central status, named servers, and clients connect to these as lighter, structurally less significant (and generally less addressable) status. Typically eventually results in a centralized topology. Contrast with peer-to-peer architectures.
• Confused deputy: A confused deputy is a kind of vulnerability which arises when one entity wishes to exploit the authority another entity has but which the former entity does not. Since the general object capability paradigm results in "if you can't have it, you can't use it", capability systems are (generally) free from such attacks. (Careless introduction of identity or rights amplification into an object capability system can re-introduce the possibility of such vulnerabilities, a topic of a future paper.) Originally described in The Confused Deputy (or why capabilities might have been invented) by Norm Hardy.
• Constructor: Within Goblins, a constructor is the procedure which, upon being invoked via spawn, returns the initial behavior of the newly constructed object. spawn passes the constructor both a bcom capability (for changing behavior) and all the remaining arguments passed to spawn, allowing for initial behavior to be tuned to the purpose of this particular object and with other capabilities as references which allow the object to correctly operate.
• Data-oriented: In contrast to behavior-oriented, data-oriented systems involve heavy analysis of data describing the system. Data-oriented systems tend to involve significant amounts of judgements upon data and narrative, and thus tend to encourage ACL type designs (and thus also their problems), but this is not universally the case. Many CRUD web applications reading and writing from an SQL database with separate logic for interpreting or modifying that data are often data-oriented, and so are many systems which focus on passed messages as descriptive information of updates rather than actions to execute.
• Dialect: A language variant, particularly a variant of Lisp.
• Distributed object programming: A programming style where asynchronous programming may occur against a network of interconnected object relationships, reducing the conceptual overhead of building secure, highly peer-to-peer networked programs.
• Distributed garbage collection: The cooperation of multiple machines to free resources which are no longer needed. Implemented by CapTP. More specifically, cyclic distributed garbage collection if cycles crossing machine boundaries are collected, and acyclic distributed garbage collection if not.
• E: A major influence on the design of Goblins, direct successor to Joule, innovator of many object capability security patterns, first implementer of the vat model of computation, and the source of the first iteration of CapTP (and VatTP, as part of Pluribus).
• Eval/Apply: The heart of most programming languages: eval gathers up the values of arguments to an expression and apply performs the execution of the expression's behavior against the evaluated arguments. Each calls the other until achieving a "fixed point" of computation (the result of the total program evaluation). Popular topic of conversation amongst Scheme programmers.
• Functional programming: Programming without side effects; freedom from time.
• Goblins: The very distributed object system described by this paper, and the heart of Spritely's programming environment.
• Guile: A particular dialect of Scheme, on which Goblins has been implemented, and the implementation of focus in this paper.
• Homoiconic, Homoiconicity: The property, most notably in Lisp, of surface syntax being the same as the abstract syntax tree, under a datastructure which can be manipulated and used by the programmer. This permits easy language extensions in the language and makes the language much more general.
• Identity: An abstract signifier for some individual, resource, or concept. More mysterious a topic than it appears at surface level, and comparison of identity equality and equivalence particularly complicated. When identity is checked as the primary form of access control, becomes an Access Control List.
• Joule: A fully asynchronous programming language, and a direct predecessor to E.
• Lambda: Procedure abstraction, associated heavily with the Lambda Calculus, and generally considered the heart of Scheme. Composes Goblins objects both as the constructor and as the behavior of the object. Generally considered "The Ultimate".
• Lisp: A programming language family known for being highly extensible, easy to implement, and with many dialects. (The particular dialect of Lisp used in this paper is Scheme.) Lisp has a highly flexible abstract syntax which makes it easy to "write Lisp in Lisp", even "writing code that writes code", making language extensions or variants trivial compared to most other languages. Its surface syntax is typically parenthetical but is not necessarily so; see Wisp for the indentation-oriented surface syntax used in this paper.
• Machine: Within CapTP, a computer or process available on the network which contains objects which may be communicated with.
• Monad: Something Goblins tres hard to not expose you to. Arguably, an implicit one exists in Goblins. The meaning of this entry is left as an exercise for the reader.
• Near/Far: Near objects are co-located in the same vat, otherwise they are far.
• Netlayer: Within OCapN, an individual netlayer implements the abstract netlayer interface, which is a way to implement a secure channel of communication between two machines. Different transport layers can be used as a netlayer, ranging from peer-to-peer networks to more contemporary client-server architectures. Originally called VatTP in E's implementation of Pluribus.
• Network: An interconnected system of machines. See OCapN.
• OCapN (the Object Capability Network): The combined layered abstractions of CapTP, Netlayers, and OCapN specific URIs. Combined, these allow for the implementation of a fully peer-to-peer distributed object programming environment with most networked protocol concerns abstracted away from the developer.
• Object: A term with a lot of variant meaning, but which in the case of Goblins means a reference to an abstract resource whose behavior is fully encapsulated by the runtime or network. (Goblins does not mean anything about class hierarchies by the word object, should you be suffering from a Java PTSD induced aversion to the term).
• Object capability (ocap): An object capability based architecture (sometimes known simply as a capability architecture, though this term has prominent naming conflicts) is one where one's authority is based on references which one can invoke to perform computation and cause effects. Without a reference, one can't perform an action, leading to the slogan "if you don't have it, you can't use it." Used as an abstraction of security and favorable to the principle of least authority, though maintaining that pattern requires discipline.
• Object capability programming language: A programming language upholding object capability security properties. Generally has the following properties: no ambient authority, no global mutable state, lexical scoping with reference passing being the primary mechanism for capability transfer, and importing a library should not provide access to interesting authority.
• Object graph: The set of relationships between objects. In an object capability programming language, this is typically the set of other object references within the behavior of an object's scope.
• Peer-to-peer: A network architecture where a participant in the network has the same abstracted priority across the network routing fabric as any other participant on the network. Contrast with client-to-server architectures.
• Pluribus: The equivalent of OCapN in E. Made for a good pun: E, Pluribus, Unum.
• Principle of least authority: Design systems such that entities hold no more authority than they need in order to reduce the attack surface of an application and its subcomponents. Generally easy to pull off in object capability architectures, and hard to pull off in access control list architectures.
• Promise: A special type of object abstraction representing a computation yet to be completed, either fulfilled or broken.
• Promise pipelining: From a programming perspective, the ability to send messages to the objects promises will eventually designate before they are fulfilled. From a network perspective, provides an optimization allowing delivery of messages to the host machine queuing eventual delivery of messages once dependent promises are fulfilled, eliminating unnecessary round trips. In other words, simplifies dependency-based asynchronous plan construction. Propagates errors.
• Quasi-functional: Goblins' tricky "looks imperative from the perspective of invoking another actor and functional from the perspective of an object updating its own behavior" twist on kinda-sorta functional programming. Allows for powerful transactional programming with time-traveling features without having to expose monad plumbing directly to the user.
• Racket: Another Scheme which Spritely Goblins is also implemented on, but which is not the focus of this paper.
• REPL: Read Eval Print Loop, an interactive programming language shell.
• Rights amplification: To (mis-)quote Alan Karp, "combine two things to get access to another thing". Frequently used to provide group-like features in ocap systems. Frequently implemented using sealers and unsealers. Used carelessly, can accidentally re-introduce confused deputy vulnerabilities, but the patterns shown in this paper are free of such problems. Analysis of this phenomena is hopefully the subject of a future paper.
• Safe serialization: Allowing objects to describe how they should be serialized, while still following the object capability motto of "if you don't have it, you can't use it". Implemented by Goblins, but originally in Safe Serialization Under Mutual Suspicion, which was inspired by Uneval/Unapply.
• Sealers and unsealers: The equivalent of public-key cryptography, but implemented in programming language abstractions instead. Frequently used to implement rights amplification.
• Scheme: A lambda heavy dialect of Lisp. The examples in this paper use a particular Scheme, Guile. Has some interesting history regarding the exploration of the actor model, but probably too long to cover in an already overly-verbose glossary appendix.
• Surface syntax: The representation of the programming language that programmers (usually humans) operate at. In Lisp derived languages, the surface syntax and abstract syntax tree are generally not very far apart, which is partly what makes Lisp languages so extensible.
• Swingset: Another interesting contemporary object capability programming language environment, this one layered on Javascript and produced by Agoric.
• Sneakernet: A network architecture where messages are delivered physically from participant to participant (perhaps even on foot, be that foot in wearing a sneaker or not).
• Spritely: An umbrella project to advance networked communities and decentralized networked programming abstractions.
• Spritely Goblins: See Goblins.
• The Spritely Institute: The nonprofit which is the fiscal steward and primary developer of Spritely Goblins amongst other things (and which produced this paper).
• Syntactic sugar: Syntax abstractions which make programming more convenient and (ideally) pleasant to read and write.
• Transaction, transactionality: A set of operations which are replied in a conceptually atomic manner: either all occur or none occur. Within Goblins, a turn is a transaction representing a delta of behavior changes to the actormap (including the introduction of new near objects), as well as a queue of messages to be sent. In the event of an error, the changes will not be committed and the messages will not be sent.
• Turn: A top-level event handled by a Vat, generally a message sent to a particular object. One unique feature of Goblins is that turns happen within transactions.
• Unum/Presence: The unum is an abstracted, conceptually and programmatically unified object, implemented by individual object presences.
• Uneval/Unapply: The abstract concept behind safe serialization and the inverse of eval/apply. Produces a program representing a graph of objects (using only the capabilities the objects' behavior had in scope) which can be later re-instantiated using a complimentary kind of eval/apply. Originally a remark from Jonathan A. Rees to Mark S. Miller leading to the Safe Serialization Under Mutual Suspicion paper. See also Rees's blogpost: Pickling, uneval, unapply.
• URI (Universal Resource Identifier): A type of digital identifier indicating a networked resource. OCapN defines several of these to designate machines and distributed objects.
• Vat, Vat model: An event loop which contains a set of objects, designed to be able to communicate with objects in other event loops. Objects within the vat are considered near to each other may perform both synchronous and asynchronous programming against each other, whereas objects far from each other may only provide asynchronous programming against each other.
• W7: The subset of Scheme implemented (on top of Scheme48) for Jonathan A. Rees's PhD dissertation, A Security Kernel Based on the Lambda Calculus. Highly influential to Spritely Goblins in demonstrating clearly that a pure lexically scoped language (such as a strict subset of scheme) with no mutable toplevel scope or other sources of ambient authority is already a viable object capability programming language.
• Wisp: An indentation-sensitive surface-level Lisp syntax, and the one used in this paper. Wisp determines its expression boundaries based on whitespace. Compatible with most Lisp implementations. Defined under the SRFI-119 specification.

• spawn: The spawn operator in Goblins.
• $: The synchronous call-return operator in Goblins.
• <-: The asynchronous message passing operator in Goblins. Returns a promise.
• on: Set up a callback to be handled with the resolution of a promise (possibly returning its own promise related to said resolution).
• bcom: Pronounced "become", in Goblins bcom is the conventional name given to a capability relevant to a particular object which permits, and is used to, indicate the next behavior of the particular object. Passed by spawn (through Goblins' abstract kernel) to the object's constructor. Technically implemented as a sealer, allowing for a functional substrate for updating behavior.

• Portable encrypted storage: A document storage system where files are not tied to any particular machine location (via content addressed storage) and are encrypted in such a way that hosting content does not provide the ability to read or modify the underlying contents of hosted files.
• Content addressed (storage): A document storage system where documents are named and verifiably retrieved by their content rather than by a particular network location.
• Immutable/mutable: Immutable objects and files do not change or update, mutable objects and files do.
• Size-of-file attack: Statistically determining likeliness that a file contains particular content based on its file size.
• Chunked: Split into consistently sized pieces to be latter reassembled, so as to avoid size-of-file attacks or for storage and retrieval optimizations.
• Location agnostic: Not tied to a particular location on the network.
• Network agnostic: Not tied to a particular network configuration or transport.

Switched Wisp pre-processing of keywords hack to use normal Wisp approach (dots at the start of line).

• Incorporated feedback from Jakob L. Kreuze:
  • Add a detailed footnote explaining a bit more about why promise pipelining makes things cleaner and the risks of re-entrancy attack when coroutines provide splitchronous operations which appear synchronous
  • Various grammar nits
  • Finish explanation of Alisha and Bob bob having their own Carol representations (was a confusing intro to that section without)
  • Rework homoiconic/homoiconicity footnote, glossary entry

• Incorporated feedback from Leilani Gilpin:
  • Added definitions in glossary for peer-to-peer, client-to-server, sneakernet, and italicize usage of those
  • Italicize usage of transaction and friends
  • Clarify: it's not a requirement to read the other (as of this moment: to-be-written) Spritely whitepapers to read this one
• Incorporated feedback from Robin Templeton:
  • Clarify that Unix isn't the origin of ACLs, it popularized them
  • Have a consistent comment syntax in first examples (and make it clear which ones are the SHELL> vs REPL>)
  • Capitalized Lisp/Smalltalk/Scheme
  • Explain more clearly that it's not that Goblins itself is the essential toolkit to build something like Spritely, it's that Goblins provides the essential features to be a worthy toolkit
  • Various garammar nitpicking
  • Give the motivation for Portable encrypted storage sooner in its section
  • Don't say "social network" in introduction, too captured a term
  • Consistency around "New: comments
  • Clearer introduction of what we mean by Unum in its first introduction
  • Call "Lisp types" -> "Lisp dialects"
  • Clarify which machine is local vs remote in fork-motors example

• Many duplicate words removed

• Add PDF export
• Explain which parts of the syntax are keywords
• Fix missing equals sign on the fork-motors section (a whole bunch of reviewers caught this, thanks to everyone else for being so careful ;))

• Incorporated many grammar fixes suggested by Alan Karp

• Guix manifest updated: we're now at the point where anyone with access to the repo can easily build and verify all documents with the following:

  SHELL> guix shell        # sets up dependencies
  GUIX-SHELL> make         # builds papers, extracts all code
  GUIX-SHELL> make check   # runs unit tests on examples
  

• Add tests for blog examples
• Simplify proxy code / explanation by using $ instead of <-
• Switch Matilda / the Teachers' invocations to use <- instead of $ to show off these do work fully async
• Add explanation of define-values, let-values

• Add tests for sealers/unsealers
• Fix some examples in sealers/unsealers section

• Export ^cell in spritely-core.w for tests
• Various bugfixes to interactive examples found while writing tests
• More information in predicate / conditional section
• Add unit tests for Taste of Goblins section
• Add makefile rule to run unit tests

• Both Wisp and Scheme files are now automatically extracted when the user runs make
• Fix format, was using Racket's version
• Provide and use method-cell.scm for importing methods

• Incorporating suggestions from Jessica Tallon
  • Fixed some renames of eval-expr (old name for metacirculator evaluator) to evaluate (thanks for the catch, Jessica Tallon!)
  • Rename some comments before lambda / procedure and procedure invocation / application examples
  • Make it clear that the methods macro does get complicated to figure out what's happening to the ellipses… it's not just you, dear reader!
• Rename for-list macro to for, keep it simpler

• Add a bit more about the Y Combinator (no, not the company) to a footnote in Scheme in Scheme.
• Many tyops caught by spelcheckr
• Couple of small grammar suggestions from Baldur

• Refactor introduction to language stuff, add On language and syntax choice with a mini "how to convert wisp to parenthetical syntax in your head" explainer
• Security as relationships between objects written in full!
  • Guest post with review written!
  • Lessons learned written!

• Adding to Appendix: A small-ish scheme and wisp primer
  • Add explanations of letrec and named lets to Iteration and recursion
  • Show symbols earlier when showing "some more types".
  • Finish metacircular footnote.
  • Explain that 'foo is just shorthand for (quote foo), etc
  • Add On the extensibility of Scheme (and Lisps in general)
  • Preview that we'll show how to write our own when in the first footnote which mentions
  • Fully explain how the evaluator works in Scheme in Scheme
  • Use format sooner

• Adding to Appendix: A small-ish scheme and wisp primer
  • Added Closures
  • Add a footnote to Conditionals and predicates explaining that both cond and if can be written in terms of each other. Also distinguish between <THEN-BODY> and <ELSE-BODY> in the syntactic explanation of cond.
  • Eliminate newline from examples… one less procedure to explain!
  • Explain variable arguments, define*, values
  • Added Mutation, assignment, and other kinds of side effects
  • Added Scheme in Scheme and hoo boy, it's awesome.
  • Add alist and quasiquote examples to Lists and "cons"

• Most of Appendix: A small-ish scheme and wisp primer written.
• Correct footnote… we do explore rights amplification in this paper :)

• Add Makefile, README, instructions for building HTML and extracting output

• Finished incomplete sandboxing footnote
• Include explanations of how to build module files explicitly
• Rename section: Application safety, library safety, and beyond (formerly "Application and library safety (and beyond)")
• Some updates to Appendix: Implementing sealers and unsealers
  • Show example of pos? predicate in use
  • Explain necessity of language runtime participating
  • Move coat check pattern footnote to this section (which is where it was supposed to be once the appendix was added, whoops)
• Reorder some of the appendices
• Started writing Appendix: A small scheme and wisp primer

• Added Application safety, library safety, and beyond
• Added glossary definition for on
• Add Portable encrypted storage section and relevant glossary terms
• Made changelog and glossary subsections into actual reified, linkable-by-fragment subsections
• Added Conclusions

• Added Spritely Goblins as a society of networked objects
• Remove ^revoker from revocation pair example since it isn't used (the cell is though)
• Added When schemes go awry: failure propagation through pipelines
• Fleshed out the Glossary in no small amount of detail.

• Added OCapN section
• .w wisp files now extracted from spritely-core.html (source of this document) via org-babel. You can view them at:
  • taste-of-goblins.w
  • goblins-blog.w
  • simple-sealers.w
• Cleaned up several code examples.
• Switched to new Wisp syntax adjustment (after discussion with Wisp upstream): lines starting with keywords no longer require dot to continue previous line. Change likely to be incorporated in future wisps.

• Promise pipelining examples added to A Taste of Goblins. This section was already planned but raised much interest in pre-review.
• Make tagging list with cons in ^post a bit easier to understand
• First batch of the smaller of the changes suggested by Alan Karp (a whole bunch, should iterate…)
• Incorporated feedback from Jessica Tallon
  • Explained how Solitaire gets access to keyboard and mouse
  • Switched reference from ^mcell to ^cell… oops, that's what I get from copy-pasting code from another document
  • Renamed our-cgreeter to julius in example
  • Fixed expected displayed message in "heard back" part
  • No longer use named let but the ^editor constructor, reflect that in surrounding text
  • Mention cons prepends to a list where appropriate
  • Fixed "Run by Robert" which had mistakenly said it was run by Lauren
  • Make it clearer that Lauren will hold Robert responsible for anyone who uses admin-for-robert (including someone Robert delegates authority to).
  • Moved sealers and unsealers implementation details to Appendix: Implementing sealers and unsealers