#+TITLE: The Heart of Spritely: Distributed Objects and Capability Security #+AUTHOR: Christine Lemmer-Webber, Randy Farmer, Juliana Sims #+OPTIONS: H:5 *NOTE:* This is an early draft, still under technical review. This paper is the second in a three-part series outlining Spritely's thinking and design. The first paper, [[file:spritely-framing.org][Spritely: New Foundations for Networked Communities]], explains the problems which face contemporary social network design. This paper details the core technical toolbox provided by Spritely Goblins and how it supplies the necessary features to feasibly build out Spritely's broader vision. The third paper in the series, [[file:spritely-for-users.org][Spritely for Secure Applications and Communities]], ties the first two papers together by showing how the architecture for user-facing software fulfills the vision of the first paper and can be built on top of ideas from this paper. Spritely's core tooling is generally useful and this paper may be independently of interest to people with a wide variety of programming backgrounds. The architecture of this paper is also designed with a purpose: to give us the firm footing to be able to achieve the ambitious journey of fulfilling the Spritely's user-facing vision. If your goal is to understand Spritely's full vision, it is our recommendation that you read each paper in order, however this is not a requirement. This paper, like all of the Spritely Institute's work, is based on and is a contribution to open source and open standards. * Introduction :PROPERTIES: :CUSTOM_ID: intro :END: Building /peer-to-peer/ applications on contemporary programming architecture is a complicated endeavor which requires careful planning, development, and maintenance. Building the kind of fully-decentralized design for healthy social community networks that Spritely aspires for would be too hard on systems that assume traditional client-server architecture and authority models. If each of our needs runs contrary to the grain of expected paradigms, we will have a hard time achieving our goals. Still, we must provide a development model which is comfortable in ways which match programmer intuitions. Spritely's core layers of abstractions achieve each of these seemingly contradictory requirements by drawing together decades of research from the object capability security and programming language design communities. Spritely's core layers of abstraction make building secure /peer-to-peer/ applications as natural as any other programming model. Spritely provides an integrated system for distributed asynchronous programming, /transactional/ error handling, time-travel debugging, and safe serialization. All this under a security model resembling ordinary reference passing, reducing most considerations to a simple slogan: "If you don't have it, you can't use it." * Capability security as ordinary programming :PROPERTIES: :CUSTOM_ID: caps-as-programming :END: #+BEGIN_QUOTE The Principle of Least Authority (POLA) says that code should be granted only the authority it needs to perform its task and no more. Code has a lot of power. Code can read your files, encrypt your files, delete your files, send your files (and all of the information within them) to someone else, record your keystrokes, use your laptop camera, steal your identity, hold your computer for ransom, steal your cryptocurrency, drain your bank account, and more. But most of the code that we write doesn't need to do any of those things -- so why do we give it the authority to do so? POLA is ultimately about eliminating both ambient and excess authority. It's not a motto that is meant to be inspirational; POLA can actually be achieved. But how? -- Kate Sills, [[https://medium.com/agoric/pola-would-have-prevented-the-event-stream-incident-45653ecbda99][POLA Would Have Prevented the Event-Stream Incident]] #+END_QUOTE The power of this model is best understood by contrast to Access Control Lists (ACL), the prevailing authority model, common to (and popularized by) Unix and nearly everything which has come before and followed since. If Alisha is logged in to her computer and wants to play Solitaire, she can run it like so: #+BEGIN_SRC sh # Applications run as Alisha! # Can do anything Alisha can do! SHELL> solitaire #+END_SRC In an ACL permission system Solitaire, the most innocuous-seeming of programs, can wreak the maximum amount of havoc possible to Alisha's computing life. Solitaire could snoop through Alisha's love letters, upload her banking information to a shady website, and delete or cryptolock her files (possibly demanding a tidy sum on behalf of some shady group somewhere to release access). What makes seemingly-innocent Solitaire so dangerous is the /ambient authority/ of Access Control List operating systems. In such a computing environment, when Alisha types "solitaire" in a terminal window or double clicks on its icon, her computer runs Solitaire /as Alisha/. Solitaire can do everything Alisha can do, including many dangerous things Alisha would not like.[fn:confused-deputies] #+NAME: diagram:solitaire-ambient-authority [[./imgs/solitaire-ambient-authority.svg]] The contrast with an object capability environment is strong. Following the /principle of least authority/, programs, objects, and procedures are defined in an environment with no dangerous authority. In an object capability computing environment, Solitaire would only be able to run with the authority it has been handed. # [fn:pola-polp] Imagine =solitaire= as being a procedure within an object capability secure language. (To make it obvious that these ideas can extend to a variety of language environments,[fn:ocap-language-requirements] examples will use a syntax which resembles something like Javascript or Python.) Solitaire, being run, cannot do anything particularly dangerous... but it can't do anything particularly useful either. #+BEGIN_SRC python # Runs in an environment with no special authority... # not even the ability to display to the screen! REPL> solitaire() #+END_SRC #+NAME: diagram:solitaire-no-authority [[./imgs/solitaire-no-authority.svg]] As-is, all solitaire can do is return a value... but Solitaire as a game requires interactivity: it should display to the screen, and it should be able to read input through the keyboard and mouse. Consider a capability which has been granted more power by the underlying system, =makeWinCanvas(windowTitle)=. Say that =solitaire= can take a first argument which takes a window + canvas representing an object which is able to read keyboard and mouse input, but only while the window is active. A user will be able to use the former to produce a value to pass to the latter, with exactly that authority and no more: #+BEGIN_SRC javascript # Constructs a new window REPL> solitaireWin = makeWinCanvas("Safe Solitaire") # Pass it to solitaire REPL> solitaire(solitaireWin) #+END_SRC #+NAME: diagram:solitaire-solitaireWin [[./imgs/solitaire-solitaireWin.svg]] If you want to allow Solitaire to be able to access a high score file, you could imagine that the =solitaire= procedure could accept a third procedure for exactly that purpose: #+BEGIN_SRC javascript REPL> scoreFile = openFile("~/.solitaire-hs.txt", "rw") REPL> solitaire(solitaireWin, scoreFile) #+END_SRC #+NAME: diagram:solitaire-solitaireWin-scoreFile [[./imgs/solitaire-solitaireWin-scoreFile.svg]] Consider the power of this: solitaire now has access to display to the =solitaireWin= window, it can read from the keyboard and mouse when the window is active, it can only write to the specific file it has been given access to, but it cannot do anything else dangerous.[fn:file-handles-usually-are-ocaps] It cannot access the network. It cannot read or write files from the filesystem arbitrarily (it can only access the high score file it was given). It cannot act as a keylogger (it can only read keyboard and mouse events while the window is being actively used by the user).[fn:making-launching-solitaire-convenient] This object capability security model is built on completely ordinary reference passing, familiar to the kind of programming developers do every day. What can and cannot be done is clear: if you don't have it, you can't use it. [fn:confused-deputies] A malicious version of Solitaire is an example of the confused deputy problem. This is an issue which exists in Access Control List security where one program or a user can trick a program or user with greater privileges into doing something malicious. By delegating to or deputizing Solitaire with her privileges, Alisha opens the door to Solitaire abusing them. # [fn:pola-polp] *TODO:* Incorporate a paragraph from Alan Karp here # explaining POLA, POLP, the links between, etc. And put in the # glossary too :) [fn:ocap-language-requirements] The requirements for a programming language to be considered object capability safe are reasonably minimal (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). See [[http://mumble.net/~jar/pubs/secureos/secureos.html][A Security Kernel Based on the Lambda Calculus]] for more information. [fn:file-handles-usually-are-ocaps] Those experienced with Unix-like operating systems may be familiar with [[https://en.wikipedia.org/wiki/File_descriptor][POSIX file handles]]. These are integer references to (open) files created by the kernel unique to the process requesting them which can be passed between processes and which give access to the underlying file. There is no need to search for the underlying file when given a file handle; the handle has all the information needed to access it. These handles can be thought of as capabilities. [fn:making-launching-solitaire-convenient] Creating all of these various capabilities by hand each time a program is launched would be extremely tedious. Instead, in an object capability context, creating and handing off references would be handled automatically by existing capabilities so that users would not have to think about it. In this example, the executing enviroment may implicitly pass in =scoreFile= and =solitaireWin= to an invocation of =solitaire()=. * Spritely Goblins: Distributed, transactional object programming :PROPERTIES: :CUSTOM_ID: goblins :END: At the heart of Spritely is Goblins, its /distributed object programming/ environment.[fn:on-objects] Goblins provides an intuitive security model, automatic local /transactions/ for locally synchronous operations, and easy to use and efficient asynchronous communication with /encapsulated objects/ which can live anywhere on the network. Its networking model abstracts away these details so the programmer can focus on object programming rather than network protocol design. Goblins also integrates powerful distributed debugging tools, and a process persistence and upgrade model which respects its security fundamentals.[fn:goblins-ancestry] Within Goblins, discussion of a /distributed object/ is referring to a model where many independent objects communicate with other objects on many different machines. In other words, /distributed object programming/ means "a distributed network of independent objects".[fn:distributed-object-not-to-be-confused-with] Objects are built out of /encapsulated behavior/: an object is /encapsulated/ in the sense that its inner workings are opaque to other objects, and (contrary to the focus of many systems today) objects are /behavior-oriented/ rather than /data-oriented/. Goblins enables intentional collaboration between objects even though the network is assumed hostile as a whole. Goblins utilizes techniques common to functional programming environments which enable cheap /transactionality/ (and by extension, /time travel/). The otherwise tedious plumbing associated with these kinds of techniques is abstracted away so the developer can focus on object behavior and interactions. [fn:on-objects] In recent years there has been enormous pushback against the term "object", stemming mostly from functional programming spaces and PTSD developed from navigating complicated Java-esque class hierarchies. However, the term "object" means many different things; Jonathan Rees identified [[http://www.mumble.net/~jar/articles/oo.html][nine possible properties]] associated with programming uses of the word "object". For Goblins, /objects/ most importantly means addressable entities with encapsulated behavior. Goblins supports /distributed objects/ in that it does not particularly matter where an object lives for asynchronous message passing; more on this and its relationship with /actors/ later. [fn:goblins-ancestry] Goblins draws inspiration largely from two sources. The first is Scheme (on which its current implementations are built), and particularly the "W7" Scheme variant found in [[http://mumble.net/~jar/pubs/secureos/secureos.html][A Security Kernel Based on the Lambda Calculus]], and the [[http://www.erights.org/][E programming language]]. (Both of these have rich histories of their own, particularly E's predecessor [[http://erights.org/history/joule/][Joule]], so of course Goblins inherits those too.) W7's primary contribution is the observation that a purely lexically scoped language, with Scheme in particular, is already an excellent candidate for an object capability security environment. E's primary contribution is the /distributed object/ approach that Goblins largely adopts, including the first version of the /CapTP/ protocol used by Goblins as the object communication layer abstraction of [[*OCapN: A Protocol for Secure, Distributed Systems][OCapN]]. Goblins can thus be seen as a combination of Scheme/W7 and E, with Goblins' primary innovative contribution being its /transactional/ design. [fn:distributed-object-not-to-be-confused-with] This is not to be confused with "the abstract conceptual objects themselves are distributed/replicated across different machines", addressed as the /Unum Pattern/ in the [[*Distributed behavior and why we need it][ Distributed behavior and why we need it]] section. Similarly this does not mean distributed /convergent machines/ (such as /blockchains/ or /quorums/), where a single abstract /machine/, with all of its contained objects, can be deterministically replicated by multiple independent machines on the network. While such designs can be composable with Spritely Goblins (or even easily built on top of its /transactional/ architecture), they are not the essential infrastructure to achieve Spritely's goals. Further discussion of /convergent machines/ is reserved for a future paper. [fn:on-implementations] At present, Goblins has two implementations, one on [[https://racket-lang.org/][Racket]] (the initial implementation), and one on [[https://www.gnu.org/software/guile/][Guile]] (which is newer). While both will be maintained and interoperable with each other in terms of distributed communication, the Guile implementation is becoming the "main" implementation on top of which the rest of Spritely is being built. Goblins' ideas are fairly general though and Goblins is implemented simply as a library on top of a host programming language, and Goblins' key ideas could be ported to any language with sensible lexical scoping (but it might not look as nice or be as pleasant to use or elegant). [fn:wisp-syntax] Wisp's rules are defined in [[https://srfi.schemers.org/srfi-119/srfi-119.html][SRFI 119]]. Wisp's key feature is that it has all the same structural properties as a parenthetical representation and can be translated back and forth between the parenthetical form and the whitespace-based form bidirectionally with few key rules. ** On language and syntax choice :PROPERTIES: :CUSTOM_ID: on-language-and-syntax :END: The following examples will illustrate Goblins using its implementation in /Guile/ (which is a /dialect/ of /Scheme/, which is itself a /dialect/ of /Lisp/).[fn:on-implementations] While the ideas here could be ported across many kinds of programming languages, Scheme's minimalism and flexibility allow for cleanly expressing the core ideas of Goblins. Prior knowledge of Scheme is not necessary, but some familiarity with programming in general is expected. See [[https://spritely.institute/static/papers/scheme-primer.html][A Scheme Primer]] if you'd like an introduction to Scheme. This document uses an unusual representation of Lisp syntax which is whitespace-based instead of parenthetical, named Wisp.[fn:wisp-syntax] Experience has shown that while parenthetical representations of Lisp tend to feel alien to newcomers with prior programming experience, Wisp tends to look fairly pleasantly like pseudocode. These examples aim to be as simple as possible to understand just by reading them. If you'd like a more thorough explanation of how Lisp and Wisp relate, see [[#appendix-lisp-wisp][Appendix: Lisp and Wisp]]. Lisp and Scheme programming (not only, but especially) tends to involve a cycle between experimenting at the interactive /REPL/ and code you keep around in a file. This paper follows the same convention. Code examples that have lines preceding with =REPL>= are meant to demonstrate examples of interactive use. Lines which follow and are preceded by underscores represent continued entries for the same expression: #+BEGIN_SRC wisp REPL> define name "Doris" REPL> string-append "Hello " name "!" ; => "Hello Doris!" REPL> display "Hello screen output!\n" ; prints: Hello screen output! #+END_SRC To get your /REPL/ set up properly for live programming, you will need to [[#appendix-using-goblins-wisp][setup Guile, Goblins, and Wisp]]. ** A taste of Goblins :PROPERTIES: :CUSTOM_ID: taste-of-goblins :END: The following section gives a high-level demonstration of Goblins through practical use. If you do choose to follow along by entering the code from this section, you can define this as a full-fledged module, say perhaps =taste-of-goblins.w=, like so: #+BEGIN_SRC wisp :tangle taste-of-goblins.w define-module : taste-of-goblins . #:use-module : goblins . #:use-module : goblins actor-lib methods . #:export (^cell ^greeter ^cgreeter ^borked-cgreeter ^car-factory ^borked-car-factory) #+END_SRC Code examples that are /not/ interactive can/should be entered into this file. Now you're ready to go. Read on! *** A simple greeter :PROPERTIES: :CUSTOM_ID: simple-greeter :END: This is an extremely brief taste of what programming in Goblins is like. The following code is adapted from the Guile version of Goblins.[fn:wisp-syntax] 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: #+BEGIN_SRC wisp ;; define with next argument *not* in parentheses ;; defines an ordinary variable REPL> define a-vat _____ spawn-vat REPL> ,enter-vat a-vat REPL [1]> #+END_SRC 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=: #+BEGIN_SRC wisp REPL [1]> ,q REPL> #+END_SRC 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][Appendix: Using vats in files]]. Now, implement a friend who will greet you: #+BEGIN_SRC wisp :tangle taste-of-goblins.w ;; 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 #+END_SRC The outer procedure, defined by =define=, is named =^greeter=, which is its constructor.[fn:hard-hats] 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:[fn:repl-prompt] #+BEGIN_SRC wisp ;; define with next argument *not* in parentheses ;; defines an ordinary variable REPL [1]> define gary _________ spawn ^greeter "Gary" #+END_SRC #+NAME: diagram:greeter-construct [[./imgs/greeter-construct.svg]] 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.[fn:spawn-and-construction] 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): #+BEGIN_SRC wisp REPL [1]> $ gary "Alice" ;; => "Hello Alice, my name is Gary!" #+END_SRC #+NAME: diagram:greeter-invoke [[./imgs/greeter-invoke.svg]] 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. [fn:hard-hats] The =^= character is conventionally prefixed on Goblins constructors and is called a /hard hat/, referring to the kind used by construction workers. [fn:repl-prompt] Any code line preceded by =REPL>= represents the prompt for interactively entered code at a developer's REPL (Read Eval Print Loop). Lines following represent expected returned values or behavior, and those prefixed with ==>= represent an expected return value. [fn:spawn-and-construction] =spawn= invokes a constructor for an object and returns a reference to that object, which may lead one to think of it in terms of =new= or =make= from object-oriented languages. However, unlike those keywords, =spawn= does not exist primarily to indicate new heap values; rather, it wraps the construction of an object in an object capability secure manner. =spawn= creates and manages the =bcom= capability (unique to each object), as well as places the object into the actor map of the vat where it is created. These topics will be discussed more later. *** State as updating behavior :PROPERTIES: :CUSTOM_ID: state-as-updating-behavior :END: 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. #+BEGIN_SRC wisp :tangle taste-of-goblins.w 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 #+END_SRC 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. #+BEGIN_SRC wisp REPL [1]> define chest _________ spawn ^cell "sword" REPL [1]> $ chest 'get ;; => "sword" REPL [1]> $ chest 'set "gold" REPL [1]> $ chest 'get ;; => "gold" #+END_SRC #+NAME: diagram:chest-cell [[./imgs/chest-cell.svg]] 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"!)[fn:more-on-bcom] =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.[fn:methods-and-macros] [fn:more-on-bcom] Objects in Goblins derive their functionality from "behaviors", which are simply procedures. =bcom= allows an object to specify what functionality it would like to have - what behavior it would like to /become/ - the next time it is invoked. Together, these features allow Goblins to be quasi-functional, and enable [[#turns-are-cheap-transactions][transactionality]] and [[#time-travel-distributed-debugging][time travel]] capabilities. [fn:methods-and-macros] =methods= is a macro which returns a procedure which supports symbol dispatch on its first argument. Macros are one of the key features of Scheme that make it such a powerful and expressive language. You can read more about them in the Scheme Primer section [[https://spritely.institute/static/papers/scheme-primer.html#scheme-extensibility]["On the extensibility of Scheme (and Lisps in general)"]], which even includes an implementation of =methods= itself! *** Objects which contain objects :PROPERTIES: :CUSTOM_ID: objects-which-contain-objects :END: 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=: #+BEGIN_SRC wisp :tangle taste-of-goblins.w define (^cgreeter bcom our-name) define times-called ; keeps track of how many times 'greet 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 #+END_SRC 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: #+BEGIN_SRC wisp 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 #+END_SRC #+NAME: diagram:cgreeter [[./imgs/cgreeter.svg]] *** Asynchronous message passing :PROPERTIES: :CUSTOM_ID: asynchronous-message-passing :END: 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: #+BEGIN_SRC wisp REPL [1]> ,q REPL> define b-vat _____ spawn-vat REPL> ,enter-vat b-vat #+END_SRC 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: #+BEGIN_SRC wisp REPL [1]> <- julius 'greet "Lear" ;; => # #+END_SRC This promise must be listened to. The procedure to listen to promises in Goblins is called =on=: #+BEGIN_SRC wisp 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! #+END_SRC #+NAME: diagram:asynchronous-invocation [[./imgs/asynchronous-invocation.svg]] 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: #+BEGIN_SRC wisp 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: ; Whew, it's over! #+END_SRC *** Transactions make errors survivable :PROPERTIES: :CUSTOM_ID: transactions-make-errors-survivable :END: 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: #+BEGIN_SRC wisp :tangle taste-of-goblins.w 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 #+END_SRC Now spawn this friend and invoke it: #+BEGIN_SRC wisp REPL> define horatio _____ spawn ^borked-cgreeter "Horatio" REPL> ,enter-vat a-vat 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. #+END_SRC 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... #+BEGIN_SRC wisp REPL [1]> $ horatio 'get-times-called ;; => 0 #+END_SRC 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][The vat model of computation]], [[*Turns are cheap transactions][Turns are cheap transactions]], and [[*Time-travel distributed debugging][Time-travel distributed debugging]]. *** Promise pipelining :PROPERTIES: :CUSTOM_ID: promise-pipelining :END: #+BEGIN_QUOTE "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, [[http://www.erights.org/talks/thesis/][Robust Composition: Towards a Unified Approach to Access Control and Concurrency Control]] #+END_QUOTE Promise pipelining[fn:thanks-to-e] 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[fn:coroutines] Consider the following car factory, which makes cars carrying the company name of the factory: #+BEGIN_SRC wisp :tangle taste-of-goblins.w ;; 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 #+END_SRC Here is an instance of this car factor called =fork-motors=. If you type this in, you'll see an error: #+BEGIN_SRC wisp ;; Interaction on machine A REPL> ,enter-vat a-vat REPL [1]> define fork-motors _________ spawn ^car-factory "Fork" #+END_SRC 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): #+BEGIN_SRC wisp ;; 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" #+END_SRC #+NAME: diagram:promise-pipelining-begin [[./imgs/promise-pipelining-begin.svg]] 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: #+BEGIN_SRC wisp ;; 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! #+END_SRC #+NAME: diagram:promise-pipelining-no-pipeline [[./imgs/promise-pipelining-no-pipeline.svg]] 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: #+BEGIN_SRC wisp ;; 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! #+END_SRC #+NAME: diagram:promise-pipelining-pipeline [[./imgs/promise-pipelining-pipeline.svg]] 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. [fn:thanks-to-e] Like so many examples in this document, the designs of promise pipelining and the explanation of its value come from the E programming language, the many contributors to its design, and Mark S. Miller's extraordinary work documenting that work and its history. If you find this section interesting, both the [[http://www.erights.org/elib/distrib/pipeline.html][Promise Pipelining]] page from [[http://erights.org][erights.org]] and sections 2.5 and 16.2 of [[http://www.erights.org/talks/thesis/markm-thesis.pdf][Mark Miller's dissertation]]. Note that if you are familiar with promises in Javascript, those are also inspired by E (and its predecessor Joule)'s promises. However, the full version of promises, including promise pipelining (or its most powerful use combined with network programming) were never included in Javascript proper. E's full vision of promises are present in Spritely Goblins, as outlined here. [fn:coroutines] Promises without promise pipelining are already an improvement over raw callbacks but are still insufficiently ergonomic for convenient programming. "Callback hell" and the annoyance of "=.then()= chaining" have lead many developers to prefer coroutines via =async= and =await= type operators. Goblins does have support for coroutines, but their use is somewhat cautioned against, and they are not prioritized. Coroutines give the illusion of straightahead call-return style programming by flattening callback structures. Unfortunately, while call-return programming is synchronous, coroutines are really "splitchronous"... each invocation of =await= splits time. =await= makes it very easy to accidentally mistake splitchronous code as being synchronous code, but the difference is severe: the world can change around the user during the time between a coroutine's suspension and resumption, opening up a class of vulnerabilities known as "re-entrancy attacks". This risk was [[https://web.archive.org/web/20050223050622/http://www.eros-os.org/pipermail/e-lang/2001-July/005418.html][observed during E's development]] and lead E to not include coroutines at all. A couple of decades later, re-entrancy attacks became the number one way [[https://hackernoon.com/hack-solidity-reentrancy-attack][money has been stolen in Ethereum]] due to bugs in smart contracts. But there is another reason to prefer promise pipelining over coroutines: the reduction of round-trips! A coroutine requires waiting for a response to come back before deciding upon the next action, which is not a requirement for a promise pipelining based system. *** When schemes go awry: failure propagation through pipelines :PROPERTIES: :CUSTOM_ID: failure-propagation :END: #+begin_verse 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 #+end_verse 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: #+BEGIN_SRC wisp :tangle taste-of-goblins.w 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 #+END_SRC What would happen if you tried making a car using this factory and then pipeline a message to drive it? #+BEGIN_SRC wisp 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: #+END_SRC 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. ** Security as relationships between objects :PROPERTIES: :CUSTOM_ID: security-as-object-relationships :END: #+BEGIN_QUOTE Cooperation between independent agents depends upon establishing a degree of security. Each of the cooperating agents needs assurance that the cooperation will not endanger resources of value to that agent. In a computer system, a computational mechanism can assure safe cooperation among the system's users by mediating resource access according to desired security policy. Such a mechanism, which is called a security kernel, lies at the heart of many operating systems and programming environments. -- Jonathan A. Rees, [[http://mumble.net/~jar/pubs/secureos/secureos.html][A Security Kernel Based on the Lambda Calculus]] #+END_QUOTE [[*Capability security as ordinary programming][Capability security as ordinary programming]] demonstrated how a programming language which uses lexical scoping and is strict about removing ambient authority is already likely an excellent foundation for a capability secure architecture. [[*A taste of Goblins][A taste of Goblins]] showed Goblins' powerful /transactional/ distributed object programming system. This section shows the union of the two: that the relationships between Goblins objects is a powerful, expressive, and robust security model for networked programs. What follows is a common tutorial to make this clear: a blogging style system[fn:keep-it-simple] (in this case, used by a community newspaper of an imagined town) with different users cooperating and performing different roles. Unlike most such tutorials, this is accomplished without an access control list: resources are protected from misuse without relying on checking the identity of the performing agent. Despite this, it will manage to introduce accountability and revocation features, the protection of misuse from unauthorized parties, and even the demonstration of a multiple-stakeholder cooperation pattern which has no direct parallel in an access control system. [fn:keep-it-simple] This is not meant to be a "production-ready system", but an illustrative one. As one example limitation, the blog is runtime-only and does not persist between processes to disk. However, the general ideas described are the foundation from which a more serious system could be built, and even persistence could be accomplished through the mechanisms described in [[*Safe serialization and upgrade][Safe serialization and upgrade]]. *** Making and editing a blogpost :PROPERTIES: :CUSTOM_ID: making-blogpost :END: 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: #+BEGIN_SRC wisp 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..." #+END_SRC (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: #+NAME: diagram:capability-transfer [[./imgs/capability-transfer.svg]] #+BEGIN_SRC wisp REPL [1]> display-post day-in-park-post #+END_SRC Which prints out: #+BEGIN_SRC text A Day in the Park ================= By: Lauren Ipsdale It was a good day to take a walk... #+END_SRC 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: #+BEGIN_SRC wisp REPL [1]> $ day-in-park-editor 'update _____ . #:body "It was a fine day to take a walk..." #+END_SRC **** Implementation :PROPERTIES: :CUSTOM_ID: making-blogpost-implementation :END: Since the "blog rendering" code is not essential to the demonstration of these security properties, that code is not shown in this section. However, it is available in [[*Appendix: Utilities for rendering blog examples][Appendix: Utilities for rendering blog examples]]. The final header for this module will look like so: #+BEGIN_SRC wisp :tangle goblins-blog.w define-module : goblins-blog . #:use-module : goblins . #:use-module : goblins actor-lib methods . #:use-module : ice-9 match . #:use-module : srfi srfi-9 . #:use-module : srfi srfi-9 gnu . #:use-module : simple-sealers . #:use-module : method-cell . #:export (spawn-post-and-editor spawn-blog-and-admin new-spawn-blog-and-admin spawn-adminable-post-and-editor ^logger spawn-logged-revocable-proxy-pair spawn-post-guest-editor-and-reviewer display-post-content display-blog-header display-post display-blog) #+END_SRC The implementation of the post and editor pairs is fairly simple: #+BEGIN_SRC wisp :tangle goblins-blog.w define* (spawn-post-and-editor #:key title author body) ;; The public blogpost define (^post bcom) methods ;; fetches title, author, and body, tags with '*post* symbol (get-content) define data-triple ; assign data-triple to $ editor 'get-data ; the current data cons '*post* data-triple ; return tagged with '*post* ;; The editing interface define (^editor bcom title author body) methods ;; update method can take keyword arguments for ;; title, author, and body, but defaults to their current ;; definitions (update #:key (title title) (author author) (body body)) bcom : ^editor bcom title author body ;; get the current values for title, author, body as a list (get-data) list title author body ;; spawn and return the post and editor define post : spawn ^post define editor : spawn ^editor title author body values post editor ; multi-value return of post, editor #+END_SRC This procedure takes three optional keyword arguments, the initial title, author, and body of the post.[fn:define-star] (If not supplied, they will default to =#f=, meaning "false".) It returns two values, the =post= (which is the object which represents the readable blogpost), and the =editor=, which allows for editing what viewers of the =post= see. In this system, the =editor= is the more powerful object. It contains two methods: - =update=: Allows for changing the data associated with the post. The =bcom= operation calls =^editor= again, producing new behavior with the same =bcom= capability but updated (or not) versions of the =title=, =author=, and =body=. - =get-data=: Retrieves the current title, author, and body associated with this post. The =post= is considerably less powerful, and only has one method, =get-content=. Curiously, =get-content= is a thin wrapper around the =editor='s =get-data=, merely tagging the returned data with the symbol ='*post*=. [fn:define-star] Guile's =define= does not support keyword arguments, but =define*= does. Keyword arguments are simply those introduced with the =#:key= syntax. They can be supplied much as they are defined, using =#:name value=. For example: #+BEGIN_SRC wisp REPL> define* (hello #:key [who "world"]) _____ display : string-append "Hello, " who "\n" REPL> hello ;; => Hello, world REPL> hello #:who "Todd" ;; => Hello, Todd #+END_SRC Although this is a common feature of Schemes, it is not actually standard. However, the =cons= syntax, also introduced here, is; for more on that, see the [[https://spritely.institute/static/papers/scheme-primer.html#scheme-lists-and-cons][Scheme Primer section "Lists and cons"]]. **** Analysis :PROPERTIES: :CUSTOM_ID: making-blogpost-analysis :END: #+NAME: diagram:post-and-editor [[./imgs/post-and-editor.svg]] With ordinary Goblins programming and a safe language environment, Lauren is able to construct separate post and editor capabilities which refer to the same blogpost. Lauren is able to choose who she hands these out to. Since Lauren shares the =post= capability with Robert but not the =editor= capability, Robert is able to read the blogpost, but there is no way for him to change its contents. All of this is accomplished without any attention by the underlying system to the identities of Lauren and Robert who are using the software, using ordinary reference passing behaviors. This is important, because [[*Capability security as ordinary programming][Capability security as ordinary programming]] demonstrated that an identity-centric authority model is unsafe due to ambient authority and confused deputy problems. The solution there of a capability security as ordinary argument passing extends into Goblins in a natural way. Since Goblins' object model is entirely built around behavior constructed from enclosed procedures, an object can only make use of the references to other objects it possesses in its scope. This example makes =post= a comparatively thin object to =editor=, mostly proxying information which =editor= is in charge of, with a small type-tagging symbol added. This demonstrates how one less powerful object can achieve most of its functionality by attenuating a more powerful object. *** A blog to collect posts :PROPERTIES: :CUSTOM_ID: blog-to-collect-posts :END: 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=: #+BEGIN_SRC wisp REPL [1]> define-values (maple-valley-blog maple-valley-admin) _____ spawn-blog-and-admin "Maple Valley News" #+END_SRC =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: #+BEGIN_SRC wisp REPL [1]> $ maple-valley-blog 'get-posts ; => () #+END_SRC 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: #+BEGIN_SRC wisp REPL [1]> $ maple-valley-admin 'add-post day-in-park-post REPL [1]> $ maple-valley-blog 'get-posts ; => (#) #+END_SRC The blog can now also be read with =display-blog=: #+BEGIN_SRC wisp REPL [1]> display-blog maple-valley-blog #+END_SRC Which prints the following: #+BEGIN_SRC text *********************** ** Maple Valley News ** *********************** A Day in the Park ================= By: Lauren Ipsdale It was a fine day to take a walk... #+END_SRC 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: #+BEGIN_SRC wisp ;; 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..." #+END_SRC 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: #+BEGIN_SRC wisp ;; Run by Robert: REPL [1]> $ spelling-bee-editor 'update _________ . #:title "Town Buzzing About Spelling Bee" #+END_SRC Lauren checks the post and decides it's ready to go. She adds it to the blog: #+BEGIN_SRC wisp REPL [1]> $ maple-valley-admin 'add-post spelling-bee-post #+END_SRC Now =maple-valley-blog= is starting to look like it's got some real content going! #+BEGIN_SRC wisp REPL [1]> display-blog maple-valley-blog #+END_SRC #+BEGIN_SRC text *********************** ** 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... #+END_SRC **** Implementation :PROPERTIES: :CUSTOM_ID: blog-to-collect-posts-implementation :END: Here is the core implementation of spawn-blog-and-admin: #+BEGIN_SRC wisp :tangle goblins-blog.w ;; Blog main code ;; ============== define (spawn-blog-and-admin title) define posts spawn ^cell '() define (^blog bcom) methods (get-title) . title ; return the title, as a value (get-posts) $ posts 'get ; fetch and return the value of posts define (^admin bcom) methods (add-post post) define current-posts $ posts 'get define new-posts cons post current-posts ; prepend post to current-posts $ posts 'set new-posts define blog : spawn ^blog define admin : spawn ^admin values blog admin #+END_SRC #+NAME: diagram:blog-and-admin [[./imgs/blog-and-admin.svg]] Here you see how lexical scope becomes a powerful feature for capability systems. =posts=, a cell which stores the current state of which articles are valid posts for this blog, is within the scope of the code for both =blog= and =admin=, which both utilize it within the scopes of their constructors =^blog= and =^admin= internally. However, while =blog= and =admin= are returned directly from =spawn-blog-and-admin=, =posts= never directly leaves the closure. Thus =posts= becomes a fully encapsulated coordination point between =blog= and =admin=. **** Analysis :PROPERTIES: :CUSTOM_ID: blog-to-collect-posts-analysis :END: #+NAME: diagram:compare-blog-admin-post-editor [[./imgs/compare-blog-admin-post-editor.svg]] The similarity between the patterns of =spawn-post-and-editor= and =spawn-blog-and-admin= is mostly clear, but what is interesting is in where they differ. While both return two capabilities, one effectively for reading and one effectively for writing, =spawn-post-and-editor= accomplished its job by having posts mostly proxy a subset of behavior of editors. In =spawn-blog-and-admin=, the roles are completely separated, and instead the encapsulated object of =posts= serves as the intermediary data structure that the two other objects both use to coordinate reading current information (with =blog=) and writing current information (with =admin=). *** Group-style editing :PROPERTIES: :CUSTOM_ID: group-style-editing :END: 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: #+BEGIN_SRC wisp 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" #+END_SRC 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: #+BEGIN_SRC wisp REPL [1]> $ maple-valley-admin 'edit-post _________ . bumpy-ride-post _________ . #:body "Anyone who's driven on main street recently..." #+END_SRC 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: #+BEGIN_SRC wisp 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 ... #+END_SRC 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! **** Pre-Implementation: Sealers and unsealers :PROPERTIES: :CUSTOM_ID: group-style-editing-sealers-unsealers :END: This example relies on a concept called "sealers and unsealers". /Sealers/ and /unsealers/ have an analogy with public key cryptography, where sealing resembles encryption, and unsealing resembles decryption. A third component, a /brand check predicate/, can check whether or not a sealed object was sealed by its corresponding sealer, and with a bit of work, the example will show it can operate as the equivalent of signature verification. What is astounding is that all three of these operations can work without any cryptography at all, implemented purely in programming language abstractions. (The details of implementing sealers and unsealers can be seen in [[*Appendix: Implementing sealers and unsealers][Appendix: Implementing sealers and unsealers]].) To make this clearer, imagine a scenario where you are sealing lunchtime meals using sealers and unsealers. Your rival, who wishes to sabotage you, does the same: #+BEGIN_SRC wisp REPL [1]> define-values (our-lunch-seal our-lunch-unseal our-can?) _________ make-sealer-triplet REPL [1]> define-values (rival-lunch-seal rival-lunch-unseal rival-can?) _________ make-sealer-triplet #+END_SRC You give your customer the unsealer, the delivery driver the brand predicate, and keep the sealer privately to yourself. The contents of sealed cans are private: #+BEGIN_SRC wisp REPL [1]> our-lunch-seal 'fried-rice ; => # #+END_SRC Your customer wants some chickpea salad, so seal some for them: #+BEGIN_SRC wisp REPL [1]> define chickpea-lunch _________ our-lunch-seal 'chickpea-salad #+END_SRC Thankfully your truck driver is able to check that the food they are to deliver really is from you. (You have a reputation to uphold!) #+BEGIN_SRC wisp REPL [1]> our-can? chickpea-lunch ; => #t (true) REPL [1]> our-can? _________ rival-lunch-seal 'melted-ice-cream ; => #f #+END_SRC And the customer is able to open it just fine: #+BEGIN_SRC wisp REPL [1]> our-lunch-unseal chickpea-lunch ; => 'chickpea-salad #+END_SRC Whew! **** Implementation :PROPERTIES: :CUSTOM_ID: group-style-editing-implementation :END: #+NAME: diagram:group-style-editing [[./imgs/group-style-editing.svg]] This will require re-architecting the post/editor and blog/admin tooling to enable this new functionality, adding support for sealers and a few new methods. The new version of post/editor spawning will no longer be used directly by users, so also update its name, adding a =-internal= suffix. #+BEGIN_SRC wisp :tangle goblins-blog.w define* (spawn-post-and-editor-internal blog-sealer #:key title author body) ;; The public blogpost define (^post bcom) methods ;; fetches title, author, and body, tags with '*post* symbol (get-content) define data-triple ; assign data-triple to $ editor 'get-data ; the current data cons '*post* data-triple ; return tagged with '*post* ;; *New*: get a sealed version of the editor from anywhere (get-sealed-editor) blog-sealer : list '*editor* editor ;; *New*: get a sealed version of self for self-attestation (get-sealed-self) blog-sealer : list '*post-self-proof* post ;; The editing interface define (^editor bcom title author body) methods (update #:key (title title) (author author) (body body)) bcom : ^editor bcom title author body (get-data) list title author body ;; spawn and return the post and editor define post : spawn ^post define editor : spawn ^editor title author body values post editor #+END_SRC There are actually only three changes from the prior implementation, =spawn-post-and-editor=: - This version takes one required argument, =blog-sealer=, which will be passed in by the admin object which creates the post/editor pair. - It adds two new methods to =post=: - =get-sealed-editor=: Uses =blog-sealer= to seal the corresponding =editor= object, allowing a relevant =admin= object to be able to unseal any post straight from the post itself (analogous to encryption). The ='*editor*= symbol is stored within the seal as a type tag indicating the /purpose/ of the seal. - =get-sealed-self=: Uses =blog-sealer= to seal the post itself to attest to the =admin= that it was indeed created by the blog/admin code itself (analogous to a cryptographic signature). Like the previous method, it also stores a type tag within the seal indicating its purpose, here ='*post-self-proof*=. The blog/admin spawning code also needs to be updated so that it will be able to cooperate with the new post/editor code: #+BEGIN_SRC wisp :tangle goblins-blog.w define (new-spawn-blog-and-admin title) ;; *New:* sealers / unsealers relevant to this blog define-values (blog-seal blog-unseal blog-sealed?) make-sealer-triplet define posts spawn ^cell '() define (^blog bcom) methods (get-title) . title (get-posts) $ posts 'get define (^admin bcom) methods ;; *New:* A method to create posts specifically for this blog (new-post-and-editor #:key title author body) define-values (post editor) spawn-post-and-editor-internal . blog-seal . #:title title . #:author author . #:body body list post editor ;; *Updated:* check that a post was made (and is updateable) ;; by this blog (add-post post) ;; (This part is the same as in the last version) define current-posts $ posts 'get define new-posts cons post current-posts ; prepend post to current-posts ;; *New*: Ensure this is a post from this blog ;; This is accomplished by asking the post to provide the sealed ;; version "of itself". The `blog-unseal` method will throw an error ;; if it is sealed by anything other than `blog-seal define post-self-proof $ post 'get-sealed-self match : blog-unseal post-self-proof ('*post-self-proof* obj) ; match against tagged proof unless : eq? obj post ; equality check: same object? error "Self-proof not for this post" ;; Checks out, update the set of posts $ posts 'set new-posts ;; *New:* A method to edit any post associated with this blog (edit-post post #:rest args) define sealed-editor $ post 'get-sealed-editor define editor match : blog-unseal sealed-editor ('*editor* editor) ; match against tagged editor . editor apply $ editor 'update args values spawn ^blog spawn ^admin #+END_SRC There are several new additions: - The blog calls =make-sealer-triplet= to instantiate =blog-seal= (the sealer), =blog-unseal= (the unsealer), and =blog-sealed?= (the brand-check predicate). - =^admin= receives three key changes: - New method: =new-post-and-editor= is used to create post/editor pairs by running =spawn-post-and-editor-internal= (which was defined by the previous code block). - Updated method: =add-post= now checks that this is a post made by the blog itself. This is accomplished by asking the post for its supplied self-proof. This self-proof is returned sealed and must be unsealed by =blog-unseal=, which will throw an exception if not sealed by =blog-seal=, ensuring this is a post created by (and thus editable in the future by) the blog. The unsealed value should be a list tagged with the purpose of ='*post-self-proof*= and the object to check, the latter of which should have the same identity (compared via the identity-comparison procedure =eq?=) as =post=. - New method: =edit-post= allows for editing a post even without access to its corresponding editor object. This is accomplished by calling the ='get-sealed-editor= method on a post. The admin interface uses the =blog-unsealer= to extract the type-tagged editor. It uses =apply= to take the remaining arguments passed into edit-post and passes them along to the unsealed editor. Lauren would create a new =maple-valley-admin= and =maple-valley-blog= with this procedure as before: #+BEGIN_SRC wisp REPL [1]> define-values (maple-valley-blog maple-valley-admin) _________ new-spawn-blog-and-admin "Maple Valley News" #+END_SRC Finally, this last bit is some convenience for consistency in the examples, since actors cannot return multiple values from their behavior: #+BEGIN_SRC wisp :tangle goblins-blog.w define (spawn-adminable-post-and-editor admin . args) define post-and-editor apply $ admin 'new-post-and-editor args match post-and-editor (post editor) ; match against list of post and editor values post editor ; return as values for consistency in examples #+END_SRC # [fn:typing-seals-and-signatures] TODO **** Analysis :PROPERTIES: :CUSTOM_ID: group-style-editing-analysis :END: An administrator encountering a blogpost which is worth editing will want to edit it immediately. In an access control list style system, the way to accomplish this would be to assign users to an "editor" group, but this is a system which aims to avoid the security problems associated with traditional access control list and related identity-centric authority systems. Instead, there is an approach called /rights amplification/: a sealed capability is attached to the post, giving access to the more powerful editor object, but this object can only be used through the corresponding unsealer. The only object empowered to make use of the unsealer is the blog's admin object, and so only by going through the admin is editing from the post possible. *** Revocation and accountability :PROPERTIES: :CUSTOM_ID: revocation-accountability :END: 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. #+BEGIN_SRC wisp REPL [1]> define admin-log _________ spawn ^logger #+END_SRC 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: #+BEGIN_SRC wisp 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 #+END_SRC 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: #+BEGIN_SRC wisp REPL [1]> <- admin-for-robert 'edit-post bumpy-ride-post _________ . #:title "Main Street Takes Some Bumps" #+END_SRC Later, Lauren suddenly notices with irritation that her blogpost isn't named what she remembered it being. She checks the log: #+BEGIN_SRC wisp REPL [1]> $ admin-log 'get-log ; => ((*entry* ; user "Robert" ; object # ; args (edit-post # ; #:title "Main Street Takes Some Bumps"))) #+END_SRC Lauren decides that Robert shouldn't be editing her or anyone else's posts on the blog until they've had a serious conversation. #+BEGIN_SRC wisp REPL [1]> $ roberts-admin-revoked? 'set #t #+END_SRC 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. #+BEGIN_SRC wisp REPL [1]> $ roberts-admin-revoked? 'set #f #+END_SRC **** Implementation :PROPERTIES: :CUSTOM_ID: revocation-accountability-implementation :END: The logger should look fairly familiar by now: #+BEGIN_SRC wisp :tangle goblins-blog.w define (^logger bcom) define log spawn ^cell '() ; log starts out as the empty list methods ;; Add an entry to the log of: ;; - the username accessing the log ;; - the object they were accessing ;; - the arguments they passed in (append-to-log username object args) define new-log-entry list '*entry* 'user username 'object object 'args args define current-log $ log 'get define new-log cons new-log-entry current-log ; prepend new-log-entry $ log 'set new-log (get-log) $ log 'get #+END_SRC The revocable proxy pair takes the associated username, object to proxy, and log to write to: #+BEGIN_SRC wisp :tangle goblins-blog.w define (spawn-logged-revocable-proxy-pair username object log) ;; The cell which keeps track of whether or not the proxy user's ;; access is revoked. define revoked? spawn ^cell #f ;; The proxy which both logs and forwards arguments (if not revoked) define (^proxy bcom) lambda args ;; check if access has been revoked when ($ revoked? 'get) error "Access revoked!" ;; If not, first send a message to log the access $ log 'append-to-log username object args ;; Then proxy the invocation to the object asynchronously apply $ object args define proxy spawn ^proxy values proxy revoked? #+END_SRC It returns two cells, the proxy, and the cell which is used to control whether or not access is revoked. **** Analysis :PROPERTIES: :CUSTOM_ID: revocation-accountability-analysis :END: #+NAME: diagram:revocation-and-accountability-unrevoked [[./imgs/revocation-and-accountability-unrevoked.svg]] Since Robert is never given access to the admin object directly, he has to operate using the =admin-for-robert= object which Lauren gives him. This object reports Robert's actions to a log which Lauren controls and will only operate if Lauren decides not to flip the =revoked?= cell to be true. Lauren is able to resume access through the capability should she so choose by flipping the =revoked?= cell's value back to false. #+NAME: diagram:revocation-and-accountability-revoked [[./imgs/revocation-and-accountability-revoked.svg]] Nothing is preventing Robert from sharing =admin-for-robert= with anyone else (including programs or services Robert runs), but Lauren will hold Robert accountable for any actions taken with the =admin-for-robert= capability. This is a feature, and it is extended in the next section. *** Guest post with review :PROPERTIES: :CUSTOM_ID: guest-post-review :END: 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: #+BEGIN_SRC wisp ;; 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 #+END_SRC 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: #+BEGIN_SRC wisp ;; Matilda's interactions REPL [1]> <- science-fair-editor 'set-body _________ . "My name is Matilda and I am twelve. I won the science fair..." #+END_SRC 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: #+BEGIN_SRC wisp ;; 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..." #+END_SRC 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: #+BEGIN_SRC wisp ;; Teacher's interactions REPL [1]> <- science-fair-reviewer 'approve #+END_SRC And the post goes live! Readers of the blog will see the new post, and will be able to share it widely: #+BEGIN_SRC wisp ;; Widely runnable (by blog readers and those they share it with) REPL [1]> display-blog maple-valley-blog #+END_SRC 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..." **** Implementation :PROPERTIES: :CUSTOM_ID: guest-post-review-implementation :END: Robert's clever solution is custom code. He was able to write it without even having to change anything about how the core blogging code worked: #+BEGIN_SRC wisp :tangle goblins-blog.w ;;; Guest post with review ;;; ====================== ;; The restricted-editor user can only change the title and body, but ;; not their name. ;; They cannot conspire with their teacher to be someone else on the ;; newspaper. ;; ;; The teacher cannot do anything but approve the student's post to ;; go live. They cannot change the student's choice of language, ;; only ask them to change it before approval. define (spawn-post-guest-editor-and-reviewer author blog-admin) define-values (post editor) spawn-adminable-post-and-editor . blog-admin . #:author author define submitted-already? spawn ^cell #f define (ensure-not-submitted) when : $ submitted-already? 'get error "Already submitted!" define (^reviewer bcom) methods (approve) ensure-not-submitted $ blog-admin 'add-post post $ submitted-already? 'set #t define (^restricted-editor bcom) methods (set-title new-title) ensure-not-submitted $ editor 'update #:title new-title (set-body new-body) ensure-not-submitted $ editor 'update #:body new-body define reviewer : spawn ^reviewer define restricted-editor : spawn ^restricted-editor values post restricted-editor reviewer #+END_SRC This uses patterns already shown. The code above has an encapsulated =post= and =editor= but only exports =post= directly. The post is already configured at =spawn-post-and-editor= time with the relevant author. =restricted-editor= is configured to allow changing the title and the body, but not the author. Once =reviewer='s ='approve= method is called, the encapsulated =blog-admin= will be invoked to add the post to the blog. This also flips the encapsulated =submitted-already?= cell to true. At this point, =reviewer= and =restricted-editor= will be revoked, throwing an error if someone tries to use them. **** Analysis :PROPERTIES: :CUSTOM_ID: guest-post-review-analysis :END: #+NAME: diagram:guest-post-with-review [[./imgs/guest-post-with-review.svg]] While variants of all the techniques shown in this example have already been shown, the astounding thing is that the way they are arranged permits cooperation between multiple parties: - Lauren wishes to hold Robert responsible for any updates to the blog Robert makes. Since Robert uses his admin capability, he is still held accountable for whatever actions are taken. - Robert wishes to have interesting new content added to the blog while both he and Lauren are unavailable to actively participate. By bringing multiple stakeholders to the table, he feels confident that quality both he and Lauren would feel comfortable with will be maintained. - Matilda wants to be able to talk about her experiences, and wants to be able to tell them in her own words and not be misrepresented. She is willing to receive mentorship from her teacher and apply this feedback to produce an improved article, even though she wants to write the article herself. - Mx. Beaker wants a quality article that reflects well on their school, their student, and themselves. However, Mx. Beaker can only approve the post, meaning that they must convince Matilda of any changes they would like made. - Robert is assured that neither Mx. Beaker nor Lauren can post the article on the blog falsely claiming authorship from someone else. - When Lauren and Robert return from being busy, they will both still be able to use their admin capabilities to edit the post should they feel it appropriate (though Lauren will still hold Robert accountable for his changes). But the most astounding thing of all: this entire arrangement was possible without changing any of the pre-existing blog code. Robert was able to encode an arrangement that kept everyone's interests in play, without having to even be present! *** Lessons learned :PROPERTIES: :CUSTOM_ID: security-relationships-lessons-learned :END: 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. ** Spritely Goblins as a society of networked objects :PROPERTIES: :CUSTOM_ID: goblins-as-society :END: The relationship between Spritely Goblins' abstracted distributed object layers can be understood visually. Consider the following relationship graph representing communicating objects: #+BEGIN_SRC text .----------------------------------. .----------------------. | Machine 1 | | Machine 2 | | ========= | | ========= | | | | | | .--------------. .---------. ,-. ,-. | | | Vat A | | Vat B | _| \______| \_ .------------. | | | ,-----. | | ,---. | | | / | / | | Vat C | | | | ( Alice )-------->( Bob )---' `-' `-' | | ,-----. | | | | `-----' | | `---' | | | '--->( Carol ) | | | | \ | | ^ | | | | `-----' | | | | V | `----|----' | | | | | | | ,------. | | ,-. ,-. | | | | | ( Alfred ) | |_______/ |______/ |__ | ,------. | | | | `------' | \ | \ | '----( Carlos ) | | | | | `-' `-' | `------' | | | '--------------' | | | | | | | | '------------' | '----------------------------------' '----------------------' #+END_SRC In the above diagram: - Two machines (=Machine 1= and =Machine 2=) are running separately from each other, but connected to each other over the network via OCapN and CapTP. - =Vat A= and =Vat B= are event loops which live on =Machine 1=, and =Vat C= is an event loop which lives on =Machine 2=. - The individual objects (represented by circles) live in /vats/, aka event loops which contain objects. =Alice= and =Alfred= live in =Vat A=, =Bob= lives in =Vat B=, and =Carol= and =Carlos= live on =Vat C=. (While these objects have human-like names, they're just Goblins objects.) - The arrows between the objects represent references these objects have to each other. =Alice= has references to both =Alfred= and =Bob=. =Bob= has a reference to =Carol=. =Carlos= has a reference to =Bob=. - Two objects which are in the same vat are considered /near/ each other, and thus can invoke each other synchronously, whereas any objects not in the same vat are considered /far/ from each other. Any objects can invoke each other by asynchronous message passing as long as they have a reference to each other. - Not pictured: each vat has an /actormap/, an underlying /transactional/ heap used for object communication. This is what permits /transactionality/ and time travel. (/Actormaps/ can also be used independently of vats for certain categories of applications.) Another way to think about this is via the following abstraction nesting dolls: #+BEGIN_SRC scheme (machine (vat (actormap {refr: object-behavior}))) #+END_SRC - *Machines*, which are computers on the network, or more realistically, operating system processes, which contain... - *Vats*, which are communicating event loops, which contain... - *Actormaps*, transactional heaps, which contain... - A mapping of *References* to *Object Behavior*. ** The vat model of computation :PROPERTIES: :CUSTOM_ID: vat-model-of-computation :END: Goblins follows what is called the /vat model/ of computation. A /vat/ is an event loop that manages a set of objects which are /near/ to each other (and similarly, objects outside of a vat are /far/ from each other), as well as messages between them and from other /vats/. #+BEGIN_SRC text Internal Vat Schematics ========================= stack heap ( $ ) ( actormap ) .-------.----------------------. -. | | | | | | ,-. | | | | (obj) ,-. | | | | `-' (obj) | | | ___ | `-' | | | |___) | ,-. | |- actormap | ___ | (obj) | | territory | |___) | `-' | | | ___ | | | | |___) | | | +-------'----------------------+ -' queue | ___ ___ ___ | -. (<-) | |___) |___) |___) | |- event loop '------------------------------' -' territory #+END_SRC The above schematic of a vat models its constituent parts. The actormap (the heap) holds the objects (actors) local to that vat. Each object in a given vat's actormap are /near/ to each other. The stack holds synchronous messages, which are conventional calls; these are invocations of /near/ objects. The queue holds asynchronous messages, which can either be between /near/ objects, or from other vats and thus from /far/ objects. Objects which are /near/ can perform synchronous call-return invocations in a manner familiar to most sequential programming languages used by most programmers today. Aside from being a somewhat more convenient way to program, sequential invocation is desirable because of cheap /transactionality/, which is expounded more later. Goblins uses the =$= operator to perform synchronous operations. Both /near/ and /far/ objects are able to invoke each other asynchronously using asynchronous message passing (in the same style as the /classic actor model/)[fn:classic-actors]. It does not generally matter whether or not a /far/ object is running within the same OS process or machine or one somewhere else on the network for most programming tasks[fn:session-severance]; asynchronous message passing works the same either way. Goblins uses the =<-= operator to perform asynchronous operations. The sender of an asynchronous message is handed back a /promise/ to which it can supply callbacks, listening for the promise to be fulfilled with a value or broken (usually in case of an unexpected error). For both programmer convenience and for network efficiency, Goblins supports /promise pipelining/: messages can be sent to promises which have not yet been resolved, and will be forwarded to the target once the promise resolves.[fn:full-promise-vision] While the /vat model/ of computation is not new[fn:credit-where-due], Goblins brings some novel contributions to the table in terms of /transactionality/ and time-travel debugging, enhancing an already powerful distributed programming paradigm. [fn:classic-actors] In the actor model, objects called /actors/ pass fully asynchronous messages to perform computation. An /actor/ in the classic model processes one incoming message at a time as defined by its current /behavior/. It may respond in one of three ways: create and receive a reference to a new /actor/; send messages to other /actors/ including introducgin them to other actors it knows about; or specify a change in its behavior for the next message it receives. As there are other variants of the actor model, this core, general subset is sometimes called the /classic actor model/. Object capabilities generally and Spritely in particular build on this model. [fn:session-severance] One situation in which it does matter whether a far object is running on the same machine is in the case of network session failure. Whereas objects in the same process and, to a lesser extent, on the same machine will be able to rely on the ability to communicate, those connected across a network have no such guarantees should the connection between their host machines be broken. This problem can be mitigated with a variety of techniques including store-and-forward networks. [fn:full-promise-vision] Those familiar with JavaScript may already know the term from JavaScript. Indeed, JavaScript promises are descended from E and Joule. However, JavaScript does not implement the full version of promises from these languages; notably, they do not support promise pipelining. Goblins' promises, however, do. [fn:credit-where-due] The /vat model/ originates in the [[http://erights.org/][E]] programming language and can trace some of its ideas back to E's predecessor [[http://erights.org/history/joule/][Joule]], and has since reappeared in systems such as [[https://agoric.com/][Agoric's]] [[https://github.com/Agoric/agoric-sdk/tree/master/packages/SwingSet][SwingSet]] kernel. All of these projects are the brainchildren of Mark Miller. ** Turns are cheap transactions :PROPERTIES: :CUSTOM_ID: turns-are-cheap-transactions :END: As usual in the vat model of computation, individual message sends to a vat (event loop) are queued and then handled one /turn/ at a time, akin to the way board game players take turns around a table (which is indeed the basis for the term /turn/). The message, addressing a specific object, is passed to the recipient object's current behavior. This object may then invoke other /near/ objects (residing within the same vat), which may themselves invoke other near objects in synchronous and sequential call-return style familiar to most users of most contemporary programming languages. Any of these invoked objects may also change their state/behavior (behavior changes appear purely functional in Goblins; invocations of other actors do not), spawn new objects, invoke ordinary expressions from the host language, or send asynchronous messages to other objects (which are only sent if the /turn/ completes successfully). Special to Goblins is the transactional nature of /vat turns:/ unhandled errors result in a /turn/ being rolled back automatically (or more accurately, simply never being committed to the root transactional heap), preventing unintended data corruption. This cheap transactionality means that errors in Goblins are much less eventful and dangerous to deal with than in most asynchronous programming languages. Significantly less effort needs to be spent on cleanup when time is reverted to a point where a mess never occurred.[fn:quasi-functional-heres-why] [fn:quasi-functional-heres-why] It is well known that [[https://mitpress.mit.edu/sites/default/files/sicp/full-text/sicp/book/node51.html][the introduction of time and the introduction of local state are the same]], introducing both [[https://mitpress.mit.edu/sites/default/files/sicp/full-text/sicp/book/node53.html][benefits]] and [[https://mitpress.mit.edu/sites/default/files/sicp/full-text/sicp/book/node54.html][costs]]. /Purely functional/ systems model local state without introducing /side effects/ by using /monads/, which re-introduces the benefits of time without being locked into changes which have occured. In other words: functional programming with monads grants freedom from time. Monads are powerful and beautiful constructs but are notorious for being difficult to learn to use (though learning to use them sometimes becomes a programmer point of pride), introducing enormous amounts of explicit plumbing outward to the user, threaded manually through a user's code. Goblins' design can be perceived as having an /implicit monad/ which grants the user the benefits of time-travel without the explicit plumbing, allowing the user to focus on the core object behavior aspects of their program. The ability to be productively oblivious to the above is a goal: most users will never even know or consider the idea that Goblins contains an /implicit monad/ unless they enjoy reading footnotes of architectural papers. ** Time-travel distributed debugging :PROPERTIES: :CUSTOM_ID: time-travel-distributed-debugging :END: The same transactional-heap design of Goblins can be used for other purposes. A distributed debugger inspired by E's [[http://www.erights.org/elang/tools/causeway/index.html][Causeway]] is planned, complete with message-tracing mechanisms. This will be even more powerful when combined with already-demonstrated time travel features,[fn:terminal-phase-time-travel] allowing programmers to debug a program in the state of an error when it occured. [fn:terminal-phase-time-travel] One early demonstration of this idea was shown in the runs-in-your-terminal space shooter game [[https://gitlab.com/dustyweb/terminal-phase][Terminal Phase]], built as a demo to show off Spritely Goblins. The entire core game was built before even considering that time travel would be an easy feature to add, and a [[https://dustycloud.org/blog/goblins-time-travel-micropreview/][time travel demonstration was added]] within less than three hours changing no core game code but merely wrapping the toplevel of the program; its design fell out naturally from what Goblins already provided in the way it was used. ** Safe serialization and upgrade :PROPERTIES: :CUSTOM_ID: safe-serialization :END: # Thanks to http://erights.org/data/serial/jhu-paper/upgrade.html # which has become the only source of this quote #+BEGIN_VERSE Do you, Programmer, take this Object to be part of the persistent state of your application, to have and to hold, through maintenance and iterations, for past and future versions, as long as the application shall live? ---Arturo Bejar #+END_VERSE Processes crash or close and must be resumed. Behavior changes and representations must change to accommodate such change. Goblins has an integrated serialization mechanism which simplifies serialization and upgrade. The need for state persistence and upgrade is hardly unique to Goblins programs. Much of programming traditionally involves reading and writing the state of a program to a more persistent medium, generally files on a disk or some specialized database. Web applications in particular spend an enormous amount of effort moving between database representations and runtime behavior, but translating between runtime behavior and persistent state is typically disjoint and its solution space complicated. Since Goblins' security model is encoded within the underlying runtime graph, manually scribing and restoring this structure would be a Sisyphean task in terms of labor and, should it naively trust objects' own self-descriptions, an entry point for vulnerability. As an example, consider a multiplayer fantasy game might have to keep track of many rooms, the inhabitants of those rooms including various monsters and players, players' inventory, and many clever other objects and mechanisms which might even be defined while the game is running. Ad-hoc serialization of such a system would be too hard to keep track of cognitively, and so the system should serialize the process. Asking the objects to self-describe or manipulate the underlying database could also be dangerous, as objects could claim to have authority that they do not. For example, in the game, player-built objects should not be able to claim or dispense in-game currency or grant themselves powers which they did not originally have on restoration. Spritely Goblins' solution[fn:alternative-options] is a serialization mechanism which asks objects how they would like to be serialized, but only allows objects to provide self-portraits utilizing the permissions they already have.[fn:aurie-history][fn:aurie-part-of-goblins] Goblins' serializer starts with root objects and calls a special serializer method on each object, asking each object for its self-portrait. This serialization mechanism is /sealed/ off from normal usage; only the serializer can /unseal/ it, preventing objects from interrogating each other for information or capabilities they should not have access to.[fn:rights-amplification] Since walking the entire object graph is expensive, serialization can take advantage of reading turn-transaction-delta information to only serialize objects which have changed, making it performant. The system is restored by walking the graph in reverse and applying each self-portrait to its build recipe. Restoring an object ends up being a great time to run upgrade code and as Goblins is built out it will collect many upgrade patterns into a common library. The serialized graph can be used for another purpose: to create a running visualization of a stored ocap system, further helping programmers debug systems and understand the authority graph of a running system. [fn:alternative-options] An alternative would be to use an underlying language runtime serialization system (many Lisp and Smalltalk systems have supported this for decades). However, this is wasteful; most serialized systems can be restored from a recipe of their construction rather than their current state at a fraction of the storage cost. Furthermore, the structure of objects will be subject to change over time, and language-based process persistence misses out an opportunity to treat restoration as an opportunity for upgrade. [fn:aurie-history] The ideas for Spritely's serialization/upgrade mechanism stem from comments by Jonathan A. Rees about [[https://odontomachus.wordpress.com/2020/12/09/pickling-uneval-unapply/]["uneval" and "unapply"]] and the E programming language's [[http://erights.org/data/serial/jhu-paper/index.html][Safe Serialization Under Mutual Suspicion]] paper (along with discussions between Randy Farmer and Mark S. Miller while at Electric Communities which preceded this). [fn:aurie-part-of-goblins] This system was originally a separated mechanism called /Aurie/, symbolized by a character made out of fire which was continuously extinguished and re-awakened like a phoenix. However many programs, and even many of the standard library pieces which Goblins ships with, were in want of such a system, so Aurie's flame was folded into Goblins itself. [fn:rights-amplification] This is a common ocap pattern called /rights amplification/, explored in [[#group-style-editing][Group-style editing]]. ** Distributed behavior and why we need it :PROPERTIES: :CUSTOM_ID: distributed-behavior :END: In general so far when this paper has spoken of distributed objects, it has been referring to objects with one specific "location". But many systems are actually more complicated than this. For example, Alisha and Ben might both be in the same chatroom and there may be a distinct address for Alisha and Ben's personas; if asked whether or not Carol means the same Alisha as Ben, she should have no problem saying "yes, this is the same person", and this can be as simple as address comparison.[fn:eq-isnt-simple] Alisha and Ben may have their own local representations of Carol with their own local behavior and state, particular to the interests, needs, or knowledge of Carol as she is known locally to each networked participant. The [[http://habitatchronicles.com/2019/08/the-unum-pattern/][Unum Pattern]] is a conceptual framework that encompasses the idea of a distributed abstract object with many different presences. One difference between the framing provided by the /unum pattern/ and most other distributed pattern literature is that the /unum pattern/ is particularly interested in /distributed behavior/ rather than /distributed data/. Distributed data may be emergent from distributed behavior, but it is only one application. In the /unum pattern/, many different presences cooperate together performing different roles, sometimes even responding to messages in a manner semi-opaque to each other. Consider a teacup sitting on a table in a virtual world. Where does it live? On the server? What about its representation in your client? What about the representation on another player's client? What about in your mind? While there is one /unum/, or "conceptual object", of the teacup, there are likely many /presences/ representing it. Information and authority pertaining to the teacup may also be asymmetric;[fn:asymmetric-authority] you might know that the teacup has a secret note sealed inside it and someone else might not. While there may be one object which is the /canonical presence/, possibly serving as a source of shared identifier to refer to the object, the /canonical presence/ is still a /presence/.[fn:thanks-chip] #+NAME: diagram:unum-presences [[./imgs/unum-presences.png]] /Presences/ in Goblins typically correspond to Goblins objects.[fn:not-your-mind-version-though] The /unum pattern/ is typically implemented via several messaging patterns: the reply pattern, the point-to-point pattern, the neighbor pattern, and the broadcast pattern. Keen observers might notice that a subset of the /unum pattern/, applied to data, is a publish-subscribe (PubSub) system, which is common in social media architecture design (ActivityPub is more or less a glorified data-centric publish-subscribe classic actor model implementation designed for social media on the web). For large-scale distribution of messages, the [[http://www.erights.org/elib/distrib/unum/index.html][Amphitheater Pattern]] will be supported. #+NAME: diagram:unum-message-patterns [[./imgs/unum-message-patterns.png]] However, in recent times there have been advancements in convergent information architectures with research on [[https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type][conflict-free replicated data types]]. Goblins plans on implementing a standard library of CRDT patterns which can be thought of as a "unum construction kit". [fn:eq-isnt-simple] Actually, saying that this is "as simple as address comparison" is the greatest misleading statement in this entire paper. Object identity through address comparison, frequently referred to as =EQ= based on the operator borrowed from Lisp systems, is one of the most complicated talks debated in the object capability security community. See also the [[http://www.erights.org/][erights.org]] pages on [[http://www.erights.org/elib/equality/same-object.html][Object Sameness]] and the [[http://erights.org/elib/equality/grant-matcher/index.html][Grant Matcher Puzzle]]. These are just the tip of the iceberg of =EQ= discussion and debate in the ocap community, and it's no surprise why: when identity is handled /incorrectly/ it can accidentally behave as a /Access Control List/ (/ACL/) or inherit their problems of /ambient authority/ and /confused deputies/. This is part of the value of finding patterns, to help prevent users from falling into these traps. [fn:thanks-chip] The above explanation is modified directly from [[http://habitatchronicles.com/2019/08/the-unum-pattern/][Chip Morningstar's explanation of the Unum]]. Chip Morningstar co-founded both Lucasfilms Habitat and Electric Communities (with EC Habitat), both of which are enormous influences on Spritely's design. He also generously agreed to let us use the unum diagrams above. [fn:asymmetric-authority] Exploiting /asymmetric authority/ is the very definition of the /confused deputy problem/. Its cause is usually emergent from ambient authority. Phishing attacks are an example of confused deputy problems where the confused deputy is a human being. Most object capability programming does not have confused deputy issues because to have a reference to a capability, in the general case, means to have authority to it. However, =EQ= and rights amplification (which bottoms out in a kind of =EQ=) both can re-introduce asymmetry, permitting confused deputies in careless designs, even to ocap systems. One might suggest removing identity comparison altogether from such systems, and for many ocap programs this is possible. However a /social system/ is not very useful without identity, so Spritely must develop patterns that treat identity with care. [fn:not-your-mind-version-though] Outside of Goblins, presences still may exist; it is still acceptable to consider your conception of a teacup to be a presence. Barring significant advancements in biomechanical integration, presences in your mind of a teacup probably are not represented directly by a Goblins object. #+BEGIN_COMMENT - Language environment that supports capabilities as object references http://mumble.net/~jar/pubs/secureos/secureos.html - Argument passing is your capability transfer abstraction... the same way programmers already program - Automatic translation between remote objects and local references ... you use OCapN without even thinking about OCapN (including distributed gc and promise pipelining) - /Full/ vision of promises... you can program against objects that don't even exist yet! (rephrase, less smug) - Transactions: easy atomic sequential operations - /Convergent machines:/ (needs more attention) - Quorum consensus: OpenCroquet-style convergent vats - Global consensus: (aherm, then you can build "blockchains") - Unum: abstractly distributed object with mutliple presences (different ways to do this... pubsub, CRDTs, etc) Key difference: you might *NOT* have the same vision of a presence! (More thoughts to maybe expand: And whether or not synchrony matters: Light that's in your virtual room with a switch: someone switches it on or off... "relativity") - Ampitheater pattern - Time travel debugging: cheap ability to move backwards and forwards between previous system states - Debugging against the version of things that broke - Cooperative exception disclosure with trusted machines / across vats - Causeway-like debugging tool: have a "casuality tree" - Auto-granovetter diagram (related to persistence) #+END_COMMENT * OCapN: A Protocol for Secure, Distributed Systems :PROPERTIES: :CUSTOM_ID: ocapn :END: Here, in brief, is a discussion of /OCapN/ (the /Object Capability Network/), which Spritely Goblins implements. Spritely is leading the effort to define and produce a draft specification of /OCapN/ to kickoff a standardization process, the progress of which you can follow in [[https://github.com/ocapn/ocapn][its GitHub repository]]. What /OCapN/ provides is a set of layered abstractions so that very little code needs to be aware of "where" objects live for asynchronous programming, fully capable of functioning with no central authorities, even on /peer-to-peer/ networks with the default assumption of hostile participants. While /OCapN/ is already supported by Spritely Goblins, the protocol is general and could be broadly implemented across programming languages, providing interoperable networked cooperation. The layers of OCapN are: - **CapTP:** The /Capability Transport Protocol/ (also known as /CapTP/) provides a distributed, secure networked object programming abstraction. /CapTP/ provides familiar message passing patterns with no distinction between asynchronous programming against local vs remote objects and features: - **Distributed garbage collection:** Servers can cooperate to free resources which are no longer needed. - **Promise pipelining:** Massive parallelization and network optimization. Provides convenience of sequential programming without round trips. - **Netlayers:** CapTP sits on top of the /netlayers/ abstract interface, which allows for establishing secure connections between two parties. The /netlayers/ abstraction provides: - **Transport protocol agnosticism:** Multiple types of netlayers are supported. Fully /peer-to-peer/ networks such as Tor Onion Services, I2P, and libp2p can work alongside more contemporary networks such as DNS + TLS. Even encrypted /sneakernets/ are possible. - **Temporal connection abstraction:** Both live sessions for high-performance socketed connections and high-delay, intermittently offline/online store-and-forward systems are supported. - **URI structure and certificates:** Entrance to the network must be bootstrapped and object locations identified; a unification of URI schemes provides the information an OCapN-aware language/library can use to engage connectivity. Certificates provide similar functionality but with different tradeoffs: less simplicity in sharing, but also less vulnerability to leakage. * Application safety, library safety, and beyond :PROPERTIES: :CUSTOM_ID: application-library-safety :END: #+BEGIN_QUOTE Users have faced an impossible choice: between the full authority to get your work done and destroy your machine or authority so puny that you can't do anything useful with it. And if you grant full authority you are /toast!/ Object capabilities enable you at many different scales to create easy-to-understand secure cooperation. If your cooperation has no security you will quickly find that the number of people you dare to cooperate with is limited. Unless you have security, you can only cooperate with your closest friends. By making this cooperation secure, we enable you to cooperate with people whom you do not fully trust. So if you want to do cooperation, you do indeed care about security. -- Marc Stiegler, [[https://www.youtube.com/watch?v=vrbmMPlCp3U][From Desktop to Donuts: Object-Caps Across Scales]] #+END_QUOTE While all the examples in this paper follow object capability security discipline, this paper has hand-waved past one critical detail. Even if Goblins follows object capability security discipline, Goblins is implemented as a library. Goblins can provide capability security properties in the network through /OCapN/, but it needs more: - It must trust the security environment that Goblins itself runs on, so that Goblins-enabled programs will not be subverted in the security properties they are designed to provide. In other words, it needs a *trusted computing base*. - It must also be possible to preserve the safety of code which runs /on top of Goblins/ (both externally potentially malicious or buggy vulnerable code, but even preserving the safety of Goblins code, to help reduce bugs which manifest as vulnerabilities), which means it needs a *safe evaluation environment*. There are many layers of a /trusted computing base/, and Spritely would like to provide as many as possible: - *User experience level safety:* The end user experiences of everyday users should uphold the users' intuitions of security through the interfaces they use for their work, entertainment, social communication, and community interactions. (This is the topic of a forthcoming paper, [[file:spritely-for-users.org][Spritely for Secure Applications and Communities]].) - *Network cooperation level safety:* Spritely wishes to be able to cooperate with objects hosted across the network and preserve capability passing semantics at the network abstraction level. Objects should be able to cooperate with objects on another host, but another host should be able to hold no more dangerous authority over them than the capabilities which have been granted it (by the object, or by those who have delegated capabilities to it). Thankfully, Goblins is able to provide this layer through /OCapN/ already, so this constitutes part of the /trusted computing base/ (assuming, of course, lower components have not been subverted). - *Library level safety:* All modules are untrusted by default. Loading a module doesn't mean it can do dangerous things. Instead of libraries being able to "reach out" and grab access to whatever dangerous operations they would like (such as accessing the filesystem, the network, etc), libraries should have to be passed explicit capabilities to do these things, not unlike passing capabilities into the invocation of a function. - *Language level safety:* Related to the above, the language needs to uphold the security properties encode in programs, and the runtime itself should be well programmed and to have good object capability enabling semantics. Generally, for a language to be an /object capability programming language/, it should uphold 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. - *Application level safety:* All programs are untrusted by default. Loading a program doesn't mean it can do dangerous things. Individual applications should be sandboxed to begin with no interesting authority, and users should have the ability to launch new sandboxed applications. Access to the filesystem, network, system clocks, etc should also be capabilities passed in at this layer.[fn:sandboxing] - *Operating system level safety:* The operating system itself should be programmed with /object capability security/ in mind. It should have a secure and auditable kernel. Access to external devices should be contained and managed on a capability level. - *Hardware level safety:* The hardware itself should not be a path to violating the integrity of the system, as free of side-channel attacks as possible, tamper-resistant, auditable and controllable by the end user, and understandable with well published specifications. - *Supply chain level safety:* Users should be able to be sure that hardware produced matches the hardware security specifications laid out, that the production facilities are auditable, and that backdoors are not inserted. - *Cryptographic level safety:* There should be fundamental cryptographic operations which have understandable abstractions. - *Physics and mathematics level safety:* It should be certain that the physics and the mathematics of the universe actually function in the manner described so that all of these abstractions are possible.[fn:simulation] This is a tall order (especially that last one). Listing these out can make the process of building a fully secure system feel like an impossible task. Thankfully, things are better than they appear: while layers lower on the stack are able to subvert the integrity of layers higher on the stack, at any layer of operation users benefit from protection. For example, if a user is running a web browser in what is considered to be a generally insecure operating system, if the execution of untrusted code is contrained from accessing the user's file system, the user is still protected from some levels of vulnerability. Spritely, aiming to provide a /trusted computing base/ which users can rely on, is interested in secure implementations of every one of these layers. However, for the purpose of upholding Goblins' abstractions most especially, the most obvious layer of importance is on the /library level safety/ and /language level safety/ layers. To this end, the choice of [[https://www.gnu.org/software/guile/][Guile]] for this task is not a coincidence: while more work needs to be done, Guile has the right [[https://www.gnu.org/software/guile/manual/html_node/Sandboxed-Evaluation.html][fundamental operations of sandboxed evaluation]] which are needed to build a secure environment.[fn:guile-mentions-w7] The demonstration of such an /object capability programming language/ with Goblins running on top of it will be the focus of a future Spritely Institute paper. [fn:sandboxing] Sandboxing alone is insufficient. Running in an enclosed environment where all available capabilities are defined at launch time is insufficient; this will result in too narrowly available a range of capabilities, and users will drive a sledgehammer through the walls by handing too-large of a bundle of capabilities by default. Instead, operating systems must provide the ability to "pass in" capabilities as a system is run, not only at initialization time. [fn:guile-mentions-w7] It should be seen as a good sign that the previously linked [[https://www.gnu.org/software/guile/manual/html_node/Sandboxed-Evaluation.html][sandboxed evaluations in Guile]] page references [[http://mumble.net/~jar/pubs/secureos/secureos.html][A Security Kernel Based on the Lambda Calculus]], which has been mentioned several times throughout this paper. [fn:simulation] If we are living in a simulation, we ask that those running simulation politely not tamper with the abstraction barriers we have come to rely on unless we are to be given access to the parent environment in which our simulation runs. * Portable encrypted storage :PROPERTIES: :CUSTOM_ID: portable-encrypted-storage :END: #+begin_quote Every seller of cloud storage services will tell you that their service is “secure”. But what they mean by that is something fundamentally different from what we mean. What they mean by “secure” is that after you’ve given them the power to read and modify your data, they try really hard not to let this power be abused. This turns out to be difficult! Bugs, misconfigurations, or operator error can accidentally expose your data to another customer or to the public, or can corrupt your data. Criminals routinely gain illicit access to corporate servers. Even more insidious is the fact that the employees themselves sometimes violate customer privacy out of carelessness, avarice, or mere curiosity. The most conscientious of these service providers spend considerable effort and expense trying to mitigate these risks. What we mean by “security” is something different. /The service provider never has the ability to read or modify your/ /data in the first place: never./ --- The [[https://tahoe-lafs.org/][Tahoe-LAFS]] manual on [[https://tahoe-lafs.readthedocs.io/en/latest/about-tahoe.html#what-is-provider-independent-security]["provider-independent security"]] #+end_quote How does one keep information alive even when computers drop from the network? Is there a way to keep information alive and not beholden to the liveness of a particular hosting provider without sacrificing the privacy and security of users? Can robust and private data storage be achieved in a way that upholds the same level of capability security properties demonstrated in this paper so far? [[#security-as-object-relationships][Security as relationships between objects]] provided an example of implementing a blog purely in terms of behavior. It handwaved past several details, mostly notably how to construct [[#ocapn][OCaPN]] /URIs/ so that live connections to blogposts can be bootstrapped from out-of-band, how to persist the running object graph to long-term storage via [[#safe-serialization][safe serialization]], how to encode a more sophisticated markup language (eg HTML or Markdown) to allow for rich document formatting, or any example of embedding (potentially large) static media within said documents. Nonetheless, these blogposts resemble contemporary blogs served over HTTP in the following way: access to these documents requires a live reference to a particular entity on a particular machine and is retrieved via a live interaction over a live connection. While this was useful for demonstrating that a capability system with interesting interactions can be constructed out of a /behavior-oriented/ system rather than a /data-oriented/ system, the blogposts themselves are fundamentally /data-oriented/ and could be stored as useful portable documents. Unfortunately, this means that an interesting document is subject to the bandwidth (and to a smaller degree, processing) availability and uptime of a single machine on the network. Hosting costs for producing a useful resource can grow, and usually fall on the shoulders of that particular resource. Should this machine no longer be available on the network, pointers to documents hosted by it can disappear. This is the general state of the web today, and is a major drive towards centralization and general bitrot of useful and historical information. The solution to this problem is to support /portable encrypted storage/, which must fulfill the following properties: 1. Documents must be *content addressed* and *location agnostic*. In other words, the name of the particular resource is based on information stemming from the content itself rather than a particular network location. Generally this name is the hash of the corresponding document in the case of /immutable/ documents and a public key (or hash thereof) in the case of /mutable/ documents. 2. Both *immutable* and *mutable* documents must be supported, with the latter generally being built upon the former. 3. Documents must be *encrypted* such that the documents can be stored in locations that are oblivious to their actual contents. Only those possessing read capabilities should be able to access the documents' contents. 4. Documents should be *chunked* so that they are not vulnerable to /size-of-file attacks/. 5. Reading (and, in the case of mutable documents, writing) documents must be accessed through abstract *capabilities*. 6. Files must be /network agnostic/, meaning that they are not only /location agnostic/ but agnostic even to a specific network structure. /peer-to-peer/, /client-to-server/, and /sneakernet/ networks all should be supported with the same object /URIs/ between them. Many systems have been written which supply some of these properties. [[https://ipfs.io/][IPFS]] is the most popular but does not provide the privacy and encryption requirements listed above, although it can be used as a foundation on which those layers are based. Spritely has written its own toy examples that satisfy all of the above requirements with [[https://gitlab.com/dustyweb/magenc/blob/master/magenc/scribblings/intro.org][Magenc]] and [[https://gitlab.com/spritely/crystal/blob/master/crystal/scribblings/intro.org][Crystal]], as well as an example applied to a social network with [[https://gitlab.com/spritely/golem/blob/master/README.org][Golem]]. [[https://freenetproject.org/index.html][Freenet]] and [[https://tahoe-lafs.org/][Tahoe LAFS]] were the first systems coming close to fulfilling most (but not all) of the above requirements, and laid the foundations for understanding what these requirements are and how to fulfill them. Currently [[https://openengiadina.net/papers/eris.html][Encoding for Robust Immutable Storage (ERIS)]] and [[https://inqlab.net/projects/dmc/][Distributed Mutable Containers (DMC)]] appear to be the most promising directions for fulfilling these requirements. This paper is primarily designed to discuss /behavior-oriented/ systems rather than /data-oriented/ systems; Spritely Goblins does not itself implement a solution for /portable encrypted storage/ as described above, but can be a good backend for a transport by which they may be distributed, and can compose nicely with the /distributed object programming/ features that Goblins does provide. However, given that the purpose of this paper is to describe essential infrastructure, it was important to demonstrate why in the long run /portable encrypted storage/ will be provided. Live distributed object programming without /portable encrypted storage/ is capable in the short term of building full social network systems, but secure long-lived document storage is important to the preservation of the cultural artifacts humans build together and to provide scalability friendly towards /peer-to-peer/ networks without undue pressure towards centralization. Fuller expansion of this topic will be the subject of future papers. * Conclusions :PROPERTIES: :CUSTOM_ID: conclusions :END: Despite early ambitions of internet architecture, networked technologies of the last two decades have primarily been built by, and around the needs of, large and centralized institutions. Spritely's vision of re-architecting individual and community experiences on the internet requires a different approach where radically decentralized and participatory secure networked applications are the default result of programming. Spritely Goblins meets these goals by building on established distributed programming lessons from the object capability community. Goblins further integrates these designs with theoretical approaches from the Lisp/Scheme and functional programming world, building a system that hybridizes actors and the lambda calculus. Many complicated considerations, otherwise relegated to the fringes of an explosion of domain specific languages and protocols, unify under a single model. While implemented on Scheme (for being a strong and natural fit), these ideas are written as a library general enough to be ported to most language environments with first class functions and lexical scoping. The end result delivers great power to the user. Security analysis moves towards the intuitions of ordinary programming paradigms of reference passing. The vat model of computation synthesizes both synchronous programming against highly localized objects and asynchronous programming against objects which can live anywhere. Turn-based transactionality means that failures do not cause corruption of state in most circumstances. Time travel plus distributed debugging allows the user to more easily pin down problems and analyze them from the point of view of the system at the time where the errors occurred. An integrated safe serialization mechanism allows for objects to describe how they should be persisted using no more authority than that which they have been already granted and, upon being restored, also allows for the possibility of upgrade. And most importantly, Goblins' integration with OCapN (the Object Capability Network) and its implementation of CapTP (the Capability Transport Protocol) provides a unified distributed programming protocol with powerful features such as distributed debugging and efficient promise pipelining. With all these features combined, Goblins provides a foundation where not only is building a future as robust as Spritely's vision requires possible, it is also comfortable and comprehensible. * Appendix: On the choice of Scheme :PROPERTIES: :CUSTOM_ID: appendix-scheme-wisp-primer :END: This paper (and Goblins itself) was written in the [[https://www.gnu.org/software/guile/][Guile]] implementation of [[https://en.wikipedia.org/wiki/Scheme_(programming_language)][Scheme]], itself a /dialect/ of /Lisp/. (A Racket version also exists, but is not the subject of this paper. The two versions are very similar.) This choice was made for many reasons, most notably of which was the flexibility, fast iteration time, and extensibility of the underlying language. The usual /surface syntax/ for /Scheme/ and other languages like it in the /Lisp/ family is "parenthetical", like so: #+BEGIN_SRC scheme (define (greet name) (string-append "Hello " name "!")) #+END_SRC In a /parenthetical/ representation of /symbolic expressions/ (also known as /s-experessions/ or /sexps/), the parentheses show where the beginning and end of each "expression" are very clearly. The parenthetical syntax is also highly minimal, but is robust enough that any (really!) programming language can be represented using this kind of Lisp "parenthetical symbolic expression" syntax. In general, Scheme/Lisp programmers' editors do the work of managing parentheses for them, and most code is read by indentation rather than by the parenthetical grouping. In other words, Lisp programmers usually don't spend much time thinking about the parentheses at all. However, since most programming languages /don't/ use syntax like this, experienced programmers sometimes find parenthetical Lisp style syntax intimidating. (In general, students totally new to programming have an easier time learning traditional Lisp syntax than seasoned programmers unfamiliar with Lisp do.)[fn:lisp-but-beautiful] To keep /experienced programmers/ from feeling intimidated, this paper uses [[https://srfi.schemers.org/srfi-119/srfi-119.html][Wisp]], which looks like so: #+BEGIN_SRC wisp define (greet name) string-append "Hello " name "!" #+END_SRC Compare to the previous =greet= example: #+BEGIN_SRC scheme (define (greet name) (string-append "Hello " name "!")) #+END_SRC The structure of the language is the same in each of these, only the /surface syntax/ has changed. Wisp derives its expression structure from indentation, but the end result is still symbolic expressions, just not expressed parenthetically. Wisp can be converted to parenthetical s-expressions, and vice versa. [fn:lisp-but-beautiful] The first author has found that in running workshops introducing programming, students learning programming for the first time don't find Lisp syntax intimidating once they start programming, but experienced programmers do because Lisp's syntax looks alien at first sight if you know most other languages. The author has even found that in teaching both Scheme (through Racket) and Python in parallel, many students with no programming background whatsoever (the workshops were aimed at students with a humanities background) expressed a strong preference for parenthetical Lisp syntax because of its clarity and found it easier to write and debug given appropriate editor support (Racket makes this easy with its newcomer-friendly IDE, DrRacket). For more about this phenomenon, see the talk [[https://fosdem.org/2022/schedule/event/lispforeveryone/][Lisp, but Beautiful; Lisp for Everyone]]. * Appendix: Lisp and Wisp :PROPERTIES: :CUSTOM_ID: appendix-lisp-wisp :END: What follows is a short explanation of how Wisp relates to Lisp. The left-hand syntax is written in Wisp, whereas the right-hand code is written in standard parenthetical Scheme: #+BEGIN_SRC wisp define (add-drawing p f) | (define (add-drawing p f) define drawer | (define drawer make-pict-drawer p | (make-pict-drawer p)) new canvas% | (new canvas% parent f | (parent f) style '(border) | (style '(border)) paint-callback | (paint-callback lambda (self dc) | (lambda (self dc) drawer dc 0 0 | (drawer dc 0 0))))) #+END_SRC These are just different /surface syntax/ representations of the same program. The code can mostly be read by indentation, with deeper nested indentation levels representing nested sub-expressions. Sections of code wrapped in parentheses retain their parenthetical representation as-is. There are only a couple of tricky details to know. First, lines starting with a dot continue a previous expression: #+BEGIN_SRC wisp render-to-file | (render-to-file . "cool-cat.png" | "cool-cat.png" make-cat-drawing | (make-cat-drawing . #:happy? #t | #:happy? #t . #:size 100 | #:size 100)) #+END_SRC Second, a colon can be used to nest a sub-expression on the same line: #+BEGIN_SRC wisp define (get-and-save-username db) | (define (get-and-save-username db) define name : input "Name:" | (define name (input "Name:")) db-store db "username" name | (db-store db "username" name)) #+END_SRC That's all you need to know about Wisp. * Appendix: Setting up Guile, Wisp, and Goblins :PROPERTIES: :CUSTOM_ID: appendix-using-goblins-wisp :END: This appendix follows the broader document in using Guile and Guile Goblins as the example implementation. Although the process of setting up a Racket environment is different, it should be relatively similar. The easiest way to get started with Goblins and Wisp is to use [[https://guix.gnu.org][GNU Guix]]. Either on the Guix system or using it as a third-party package manager, the following command will get you into a Guile /REPL/ using Wisp with Goblins available: #+BEGIN_SRC shell > guix shell --pure guile guile-goblins guile-wisp -- guile --language=wisp #+END_SRC If you don't want to use Guix, you'll need to obtain Guile, Guile Wisp, and the Guile version of Goblins separately. ** Obtaining Guile 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 [[https://www.gnu.org/software/guile/download/][download Guile source]] and then compile it according to [[https://www.gnu.org/software/guile/manual/html_node/Obtaining-and-Installing-Guile.html][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 [[https://gcc.gnu.org/][GCC]] - [[https://www.gnu.org/software/automake/][GNU Autotools]] With those, inside the directory for the Guile source directory, you'll run the following commands: #+BEGIN_SRC shell > ./configure > make > make install #+END_SRC After that's done you can move on to... ** Obtaining Wisp 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 [[https://www.draketo.de/software/wisp#updates][download its source code and compile it]]. This presupposes an extant Guile installation. Inside its source directory, you should be able to run: #+BEGIN_SRC shell > ./configure > make > make install #+END_SRC And finally you get to... ** Obtaining Goblins At the moment, Goblins is only packaged for Guix and Homebrew. The only alternative is to build it manually. Following the instructions in the [[https://gitlab.com/spritely/guile-goblins][Guile Goblins source repository]], you'll need to obtain a few dependencies: - Guile 3.0 (handled above) - [[https://notabug.org/cwebber/guile-gcrypt][guile-gcrypt]] - [[https://github.com/wingo/fibers][guile-fibers]] - [[https://www.torproject.org/][Tor]] (runtime; optional, for networking) - [[https://git-scm.com/][git]] (implicitly) Then it should be as straightforward as running the following commands: #+BEGIN_SRC shell > git clone https://gitlab.com/spritely/guile-goblins > cd guile-goblins > ./configure > make > make install #+END_SRC With all of that completed, you get a /REPL/ to run the examples in this document as follows: #+BEGIN_SRC shell > guile --language=wisp #+END_SRC * Appendix: Using vats in files :PROPERTIES: :CUSTOM_ID: appendix-using-vats :END: In order to start programming with Goblins, you will need to boot up a vat somewhere. In general, Goblins uses [[https://github.com/wingo/fibers/][Fibers]] to implement vats. Running =spawn-vat= returns vat object. Code can be run within the context of a vat using the =,enter-vat= command at the REPL: #+BEGIN_SRC wisp REPL> define my-vat : spawn-vat REPL> . my-vat ;; => # REPL> ,enter-vat my-vat REPL [1]> #+END_SRC You can then leave the vat sub-REPL with =,q=: #+BEGIN_SRC wisp REPL [1]> ,q #+END_SRC Inside of a file - or at the REPL if you so choose - you can instead use the =call-with-vat= procedure: #+BEGIN_SRC wisp call-with-vat my-vat lambda () define alice spawn ^greeter "Alice" $ alice "Bob"" #+END_SRC For convenience, the =with-vat= macro can be used instead of =call-with-vat=. Here's the above example rewritten to use =with-vat=: #+BEGIN_SRC wisp with-vat my-vat define alice spawn ^greeter "Alice" $ alice "Bob" #+END_SRC You can use the =vat-halt!= procedure to stop the vat, and =vat-running?= to check its status: #+BEGIN_SRC wisp REPL> vat-halt! my-vat REPL> vat-running? my-vat ;; => #f #+END_SRC In the future, Guile vats will automatically halt when no more references exist and thus the vat can do no more work. The Racket version of vats already work this way. In the meantime, you'll need to call =halt-vat!= manually. * Appendix: Utilities for rendering blog examples :PROPERTIES: :CUSTOM_ID: appendix-utilities-rendering-blog-examples :END: #+BEGIN_SRC wisp :tangle goblins-blog.w ;; Blogpost rendering utilities ;; ============================ define (display-post-content post-content) match post-content ('*post* post-title post-author post-body) let* : title : or post-title "<>" title-underline : make-string (string-length title) #\= author : or post-author "<>" body : or post-body "<>" display format #f "~a\n~a\n By: ~a\n\n~a\n" . title title-underline author body define (display-blog-header blog-title) define header-len + 6 (string-length blog-title) define title-stars make-string header-len #\* display format #f "~a\n** ~a **\n~a\n" . title-stars blog-title title-stars define (display-post post) display-post-content $ post 'get-content define (display-blog blog) display-blog-header $ blog 'get-title for-each lambda (post) display "\n" display-post post display "\n" $ blog 'get-posts #+END_SRC * Appendix: Implementing sealers and unsealers :PROPERTIES: :CUSTOM_ID: appendix-implementing-sealers-unsealers :END: There are two ways to construct sealers and unsealers; one is the "coat check" pattern,[fn:coat-check-pattern] the other is the language-protected dynamic type construction pattern. The latter has less complications surrounding garbage collection and leads to some real "a-ha" moments, so that will be shown here. This uses dynamically constructed type-records (as taken from the [[https://srfi.schemers.org/srfi-9/srfi-9.html][SRFI-9 scheme extension]]). In Guile, import the following: #+BEGIN_SRC wisp use-modules srfi srfi-9 #+END_SRC To understand how these records work in the general case, here is an example of a srfi-9 record used to define a 2d positional object called ==: #+BEGIN_SRC wisp define-record-type ; : name of the type make-pos x y ; make-pos: constructor, takes two arguments . pos? ; pos?: brand-check predicate (is it a pos?) x pos-x ; pos-x: accessor for x y pos-y ; pos-y: accessor for y #+END_SRC Use of this pos is simple enough: #+BEGIN_SRC wisp REPL> define our-pos _____ make-pos 2 3 REPL> pos-x our-pos ;; => 2 REPL> pos-y our-pos ;; => 3 REPL> pos? our-pos ;; => #t REPL> pos? 'something-else ;; => #f #+END_SRC To define these utilities so that they can be used from other modules, start a new file called =simple-sealers.w= and define the following: #+BEGIN_SRC wisp :tangle simple-sealers.w define-module : simple-sealers . #:use-module : srfi srfi-9 . #:use-module : srfi srfi-9 gnu . #:export (make-sealer-triplet) #+END_SRC Following from this, look at how =make-sealer-triplet= works: #+BEGIN_SRC wisp :tangle simple-sealers.w ;; Make a sealer, unsealer, and brand-check predicate using ;; dynamic type generation. define (make-sealer-triplet) define-record-type seal val ; constructor (sealer) . sealed? ; predicate (brand-check) val unseal ; accessor (unsealer) ;; Prevents snooping on contents at REPL, etc define (print-seal _rec port) display "#" port set-record-type-printer! print-seal ;; Return sealer, unsealer, sealed? predicate values seal unseal sealed? #+END_SRC An invocation of =make-sealer-triplet= defines a new == type on the fly which will be completely distinct from any made during future invocations of =make-sealer-triplet=. The sealer is the constructor (accepting one argument, the sealed =val=), the brand-check is the type predicate, and the unsealer is the accessor of the sealed =val=. If running in a language environment which does not allow the user to piece apart a record without its corresponding accessor, there is no way to retrieve the associated value without the unsealer. Note that upholding the above requires cooperation from the language runtime to not expose tools for deconstructing arbitrary record structures. "Unfortunately", Guile does provide tools readily with =record-accessor=, =record-constructor=, and so on. However, "unfortunately" is in scare quotes because the situation is not so dire (or no more dire than the default situation in Guile, which already provides even more dangerous operations such as accessing the filesystem, the network, and so on). [[#application-library-safety][Application safety, library safety, and beyond]] describes how /language level safety/ can be achieved. By not providing these record deconstructing tools to a constrained execution environment, the properties of sealers and unsealers as defined above can be upheld. [fn:coat-check-pattern] The coat check pattern can be implemented and explained easily also: the coat is the value to be sealed, the sealer is the coat check desk, the ticket for later retrieval the sealed object, and the coat retrieval desk the unsealer. However this involves extra work to avoid garbage collection concerns amongst other issues; see "2.3.3 The Case for Kernel Support" in [[http://mumble.net/~jar/pubs/secureos/secureos.html][A Security Kernel Based on the Lambda Calculus]]. * COMMENT Appendix: Related work :PROPERTIES: :CUSTOM_ID: appendix-related-work :END: The influences on Goblins run deep in the history of computer science, and a thorough accounting could never reliably be given of all the works that contributed to it existing as it does. However, some of the most immediately relevant are collected here for those interested in furthering their understanding of the topics upon which Goblins touches. - [[http://mumble.net/~jar/pubs/secureos/secureos.html][A Security Kernel Based on the Lambda Calculus]] which provides insights into using lambdas for access control, and by extension: - [[https://spritely.institute/static/papers/scheme-primer.html][A Scheme Primer]] for an overview of Scheme - The [[https://research.scheme.org/lambda-papers/][Lambda Papers]] which introduced Scheme and related ideas - [[https://mitp-content-server.mit.edu/books/content/sectbyfn/books_pres_0/6515/sicp.zip/full-text/book/book.html][Structure and Interpretation of Computer Programs]], a classic textbook on Scheme and programming generally - The [[http://erights.org][E programming language]] and related works, which pioneered ocaps: - [[http://erights.org/elib/capability/ode/index.html][An Ode to the Granovetter Diagram]], an overview of object capabilities - [[http://www.erights.org/talks/thesis/][Robust Composition: Towards a Unified Approach to Access Control and Concurrency Control]], Mark Miller's thesis - [[http://erights.org/history/joule/][Joule]], E's predecessor - [[http://www.erights.org/elib/distrib/pipeline.html][Promise Pipelining]] - [[http://www.erights.org/elang/tools/causeway/index.html][Causeway]], a distributed debugger - [[http://erights.org/data/serial/jhu-paper/upgrade.html][Persistence and Upgrade]] - [[http://erights.org/data/serial/jhu-paper/index.html][Safe Serialization Under Mutual Suspicion]] - [[http://www.erights.org/elib/distrib/unum/index.html][Unum]] - [[http://www.erights.org/elib/equality/same-object.html][Object Sameness]] - [[http://erights.org/elib/equality/grant-matcher/index.html][Grant Matcher Puzzle]] - [[https://agoric.com/][Agoric]] and its ongoing ocap work: - [[https://github.com/Agoric/agoric-sdk/tree/master/packages/SwingSet][SwingSet]], an ocap library using JavaScript - [[https://www.ijcai.org/Proceedings/73/Papers/027B.pdf][A Universal Modular ACTOR Formalism for Artificial Intelligence]] which proposed the actor model and thus influenced Scheme as well as OCaps - [[https://odontomachus.wordpress.com/2020/12/09/pickling-uneval-unapply/][Pickling, uneval, unapply]] - [[http://habitatchronicles.com/2019/08/the-unum-pattern/][The Unum Pattern]] by one of its pioneers - [[https://www.youtube.com/watch?v=vrbmMPlCp3U][From Desktop to Donuts: Object-Caps Across Scales]] - [[https://tahoe-lafs.org/][Tahoe-LAFS]] - [[https://tahoe-lafs.readthedocs.io/en/latest/about-tahoe.html#what-is-provider-independent-security]["provider-independent security"]] - [[https://ipfs.io/][IPFS]] - [[https://freenetproject.org/index.html][Freenet]] - [[https://openengiadina.net/papers/eris.html][Encoding for Robust Immutable Storage (ERIS)]] - [[https://inqlab.net/projects/dmc/][Distributed Mutable Containers (DMC)]] - [[http://waterken.sourceforge.net/aclsdont/current.pdf][ACLs Don't]] - [[https://css.csail.mit.edu/6.858/2015/readings/confused-deputy.html][The Confused Deputy (or why capabilities might have been invented)]] - [[https://www.uni-weimar.de/fileadmin/user/fak/medien/professuren/Virtual_Reality/documents/publications/capsec_vr2008_preprint.pdf][Object-Capability Security in Virtual Environments]] - [[http://habitatchronicles.com/Habitat/historical/ProtocolReqs-2-27-95.pdf][Cyberspace Protocol Requirements]] - ...and other work directly related to Spritely: - [[https://gitlab.com/dustyweb/terminal-phase][Terminal Phase]] - [[https://dustycloud.org/blog/goblins-time-travel-micropreview/][Terminal Phase time travel blog post]] - [[https://gitlab.com/dustyweb/magenc/blob/master/magenc/scribblings/intro.org][Magenc]] - [[https://gitlab.com/spritely/crystal/blob/master/crystal/scribblings/intro.org][Crystal]] - [[https://gitlab.com/spritely/golem/blob/master/README.org][Golem]] - [[https://github.com/ocapn/ocapn][OCapN]] * Appendix: Glossary :PROPERTIES: :CUSTOM_ID: appendix-glossary :END: ** Goblins and capability terminology :PROPERTIES: :CUSTOM_ID: glossary-goblins-capability-terms :END: - *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 [[http://waterken.sourceforge.net/aclsdont/current.pdf][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 [[http://www.erights.org/elang/tools/causeway/index.html][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 [[https://css.csail.mit.edu/6.858/2015/readings/confused-deputy.html][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 [[https://en.wikipedia.org/wiki/Lambda_calculus][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 [[http://www.mumble.net/~jar/articles/oo.html][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 [[http://erights.org/data/serial/jhu-paper/index.html][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, [[https://github.com/Agoric/agoric-sdk/tree/master/packages/SwingSet][this one layered on Javascript]] and produced by [[https://agoric.com/][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 [[http://erights.org/data/serial/jhu-paper/index.html][Safe Serialization Under Mutual Suspicion]] paper. See also Rees's blogpost: [[https://odontomachus.wordpress.com/2020/12/09/pickling-uneval-unapply/][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 [[https://www.s48.org/][Scheme48]]) for Jonathan A. Rees's PhD dissertation, [[http://mumble.net/~jar/pubs/secureos/secureos.html][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 [[https://srfi.schemers.org/srfi-119/srfi-119.html][SRFI-119 specification]]. ** Core goblins operations :PROPERTIES: :CUSTOM_ID: glossary-goblins-operations :END: - =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 specific terminology :PROPERTIES: :CUSTOM_ID: glossary-portable-encrypted-storage :END: - *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. * Appendix: Acknowledgments :PROPERTIES: :CUSTOM_ID: appendix-acknowledgments :END: An enormous number of people reviewed and provided feedback to this paper. Thank you to: Alan Karp, Baldur Jóhannsson, Chris Hibbert, Dan Connolly, Dan Finlay, Douglas Crockford, Jessica Tallon, Jonathan A. Rees, Jonathan Frederickson, Mark S. Miller, Stephen Webber, Robin Templeton, Leilani Gilpin, Kate Sills, and Ludovic Courtès. (*NOTE:* if you think you should/shouldn't be on this list, let us know and we'll edit appropriately!) Thank you to Mark S. Miller who personally spent enormous amounts of time walking Christine through object capability ideas through the years and provided guidance on how to properly represent granovetter diagrams (which, as applied to object capability systems, really are a powerful but underdocumented visual language). Thank you to Jessica Tallon who actively used Spritely Goblins during the production of this paper, allowing for feedback from direct experience, including many suggestions for improvements in the examples. Thank you to Chip Morningstar who agreed to let Spritely use his diagrams of the unum pattern. Thank you to Arne Babenhauserheide, who developed the Wisp syntax for Lisp used in this paper. * Appendix: ChangeLog :PROPERTIES: :CUSTOM_ID: appendix-changelog :END: ** [2023-09-26 Tue] :PROPERTIES: :CUSTOM_ID: ChangeLog-2023-09-26 :END: Switched Wisp pre-processing of keywords hack to use normal Wisp approach (dots at the start of line). ** [2022-07-01 Fri] :PROPERTIES: :CUSTOM_ID: ChangeLog-2022-07-01 :END: - 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 ** [2022-06-30 Thu] :PROPERTIES: :CUSTOM_ID: ChangeLog-2022-06-30 :END: - 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][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 ** [2022-06-28 Tue] - Many duplicate words removed ** [2022-06-27 Mon] :PROPERTIES: :CUSTOM_ID: ChangeLog-2022-06-27 :END: - 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 ;)) ** [2022-06-26 Sun] - 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: #+BEGIN_SRC sh SHELL> guix shell # sets up dependencies GUIX-SHELL> make # builds papers, extracts all code GUIX-SHELL> make check # runs unit tests on examples #+END_SRC ** [2022-06-24 Fri] :PROPERTIES: :CUSTOM_ID: ChangeLog-2022-06-24 :END: - 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= ** [2022-06-23 Thu] :PROPERTIES: :CUSTOM_ID: ChangeLog-2022-06-23 :END: - Add tests for sealers/unsealers - Fix some examples in sealers/unsealers section ** [2022-06-22 Wed] :PROPERTIES: :CUSTOM_ID: ChangeLog-2022-06-22 :END: - 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 ** [2022-06-21 Tue] :PROPERTIES: :CUSTOM_ID: ChangeLog-2022-06-21 :END: - 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 ** [2022-06-20 Mon] :PROPERTIES: :CUSTOM_ID: ChangeLog-2022-06-20 :END: - 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 ** [2022-06-18 Sat] :PROPERTIES: :CUSTOM_ID: ChangeLog-2022-06-18 :END: - 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 ** [2022-06-17 Fri] :PROPERTIES: :CUSTOM_ID: ChangeLog-2022-06-17 :END: - Refactor introduction to language stuff, add [[#on-language-and-syntax][On language and syntax choice]] with a mini "how to convert wisp to parenthetical syntax in your head" explainer - [[#security-as-object-relationships][Security as relationships between objects]] written in full! - [[#guest-post-review][Guest post with review]] written! - [[#security-relationships-lessons-learned][Lessons learned]] written! ** [2022-06-16 Thu] :PROPERTIES: :CUSTOM_ID: ChangeLog-2022-06-16 :END: - 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 ** [2022-06-15 Wed] :PROPERTIES: :CUSTOM_ID: ChangeLog-2022-06-15 :END: - 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 == and == 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" ** [2022-06-14 Tue] :PROPERTIES: :CUSTOM_ID: ChangeLog-2022-06-14 :END: - Most of Appendix: A small-ish scheme and wisp primer written. - Correct footnote... we /do/ explore rights amplification in this paper :) ** [2022-06-11 Sat] :PROPERTIES: :CUSTOM_ID: ChangeLog-2022-06-11 :END: - Add Makefile, README, instructions for building HTML and extracting output ** [2022-06-10 Fri] :PROPERTIES: :CUSTOM_ID: ChangeLog-2022-06-10 :END: - Finished incomplete sandboxing footnote - Include explanations of how to build module files explicitly - Rename section: [[#application-library-safety][Application safety, library safety, and beyond]] (formerly "Application and library safety (and beyond)") - Some updates to [[#appendix-implementing-sealers-unsealers][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-scheme-wisp-primer][Appendix: A small scheme and wisp primer]] ** [2022-06-09 Thu] :PROPERTIES: :CUSTOM_ID: ChangeLog-2022-06-09 :END: - Added [[#application-library-safety][Application safety, library safety, and beyond]] - Added glossary definition for =on= - Add [[#portable-encrypted-storage][Portable encrypted storage]] section and relevant glossary terms - Made changelog and glossary subsections into actual reified, linkable-by-fragment subsections - Added [[#conclusions][Conclusions]] ** [2022-06-08 Wed] :PROPERTIES: :CUSTOM_ID: ChangeLog-2022-06-08 :END: - Added [[* Spritely Goblins as a society of networked objects][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][When schemes go awry: failure propagation through pipelines]] - Fleshed out the [[*Appendix: Glossary][Appendix: Glossary]] in no small amount of detail. ** [2022-06-07 Tue] :PROPERTIES: :CUSTOM_ID: ChangeLog-2022-06-07 :END: - Added [[#ocapn][OCapN section]] - =.w= wisp files now extracted from [[file:spritely-core.org]] (source of this document) via [[https://orgmode.org/worg/org-contrib/babel/][org-babel]]. You can view them at: - [[file:taste-of-goblins.w]] - [[file:goblins-blog.w]] - [[file:simple-sealer.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. ** [2022-04-02 Sat] :PROPERTIES: :CUSTOM_ID: ChangeLog-2022-04-02 :END: - [[*Promise pipelining][Promise pipelining]] examples added to [[*A taste of Goblins][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][Appendix: Implementing sealers and unsealers]] * License Copyright (C) 2022-2023 The Spritely Networked Communities Institute, Christine Lemmer-Webber, Randy Farmer, and Juliana Sims This work is licensed under the [[https://creativecommons.org/licenses/by/4.0/][Creative Commons Attribution 4.0 International License]] as well as the [[https://www.apache.org/licenses/LICENSE-2.0][Apache License 2.0]]. * TODO COMMENT Feedback and things to be done ** TODO Incorporate Alan Karp pola-polp footnote ** TODO Diagrams *** TODO show Lauren sending blogpost to Robert - This probably also needs to handle the network *** TODO show Post and Editor both access same cells *** TODO show Blog and Admin both access same list of articles *** TODO show Revocation and accountability *** TODO show Group-style editing? *** TODO show Guest post with review *** TODO Diagram of blog and admin in =spawn-blog-and-admin= *** TODO Diagram of blog, admin, post *** TODO Diagram AND process persistence for persistence Juliana: talk with Christine *** TODO Diagram AND process persistence for Unum Can we lift Chip's teacup diagrams? Juliana: talk with Christine *** DONE Refactor these as proper TODOs ;) ** Archive :ARCHIVE: *** DONE More sidebar'y things CLOSED: [2022-02-17 Thu 16:27] :PROPERTIES: :ARCHIVE_TIME: 2023-03-21 Tue 10:35 :END: ODT export helps! *** DONE Swap these and explain why CLOSED: [2022-02-22 Tue 12:29] :PROPERTIES: :ARCHIVE_TIME: 2023-03-21 Tue 10:35 :END: : Spritely's ambitious design requires firm footing. Building : peer-to-peer applications on contemporary programming architecture : is a complicated endeavour which requires careful planning. *** DONE Start with provide layers of abstractions here CLOSED: [2022-02-22 Tue 12:39] :PROPERTIES: :ARCHIVE_TIME: 2023-03-21 Tue 10:35 :END: : We need layers of abstractions that make building peer-to-peer : applications to be as natural as any other programming. Spritely's : core provides these needs. *** DONE Fix run-on in the-network a-networking, be consistent with the or a CLOSED: [2022-02-22 Tue 12:52] :PROPERTIES: :ARCHIVE_TIME: 2023-03-21 Tue 10:36 :END: : the network, a networking model *** DONE Mention javascript and the web sooner CLOSED: [2022-03-22 Tue 16:50] :PROPERTIES: :ARCHIVE_TIME: 2023-03-21 Tue 10:36 :END: *** DONE Add a section about capabilities showing both scheme and js CLOSED: [2022-03-03 Thu 15:13] :PROPERTIES: :ARCHIVE_TIME: 2023-03-21 Tue 10:36 :END: *** DONE More why about distributed, transactional, object programming in intro CLOSED: [2022-02-22 Tue 13:49] :PROPERTIES: :ARCHIVE_TIME: 2023-03-21 Tue 10:36 :END: *** DONE Encapsulated behavior is too important to be a footnote CLOSED: [2022-02-23 Wed 11:59] :PROPERTIES: :ARCHIVE_TIME: 2023-03-21 Tue 10:36 :END: Needs to move up from on-objects *** DONE Security's second sentence is the strongest, pull it up CLOSED: [2022-03-03 Thu 15:18] :PROPERTIES: :ARCHIVE_TIME: 2023-03-21 Tue 10:36 :END: "If you don't have it, you can't use it" Look at Stiegler's donuts talk Done in intro. Now look lower. *** DONE Using quotes in the vernacular around what should otherwise be technical terms CLOSED: [2022-02-23 Wed 08:05] :PROPERTIES: :ARCHIVE_TIME: 2023-03-21 Tue 10:36 :END: Use italics/emphasis instead *** DONE "The sender of the message" paragraph, move sentence up CLOSED: [2022-03-03 Thu 15:17] :PROPERTIES: :ARCHIVE_TIME: 2023-03-21 Tue 10:36 :END: *** DONE Eliminate all non /turn/ uses of "turn" ;) CLOSED: [2022-02-23 Wed 12:44] :PROPERTIES: :ARCHIVE_TIME: 2023-03-21 Tue 10:36 :END: *** DONE Get rid of "as we shall see" in "while the" paragraph CLOSED: [2022-03-03 Thu 15:12] :PROPERTIES: :ARCHIVE_TIME: 2023-03-21 Tue 10:36 :END: *** DONE In "turns are cheap transactions" talk about rollbacks CLOSED: [2022-02-23 Wed 12:42] :PROPERTIES: :ARCHIVE_TIME: 2023-03-21 Tue 10:36 :END: *** DONE Look at what Rees said in email about monads CLOSED: [2022-02-23 Wed 12:00] :PROPERTIES: :ARCHIVE_TIME: 2023-03-21 Tue 10:36 :END: In fact, maybe remove monads stuff *** DONE Add "cooperation between independent agents" to intro CLOSED: [2022-02-23 Wed 12:01] :PROPERTIES: :ARCHIVE_TIME: 2023-03-21 Tue 10:36 :END: "Cooperation between independent agents" vs "decentralized convergence" Well I more or less did cover this more clearly now, but let's see what Randy thinks *** DONE Bad attitude! CLOSED: [2022-03-03 Thu 15:15] :PROPERTIES: :ARCHIVE_TIME: 2023-03-21 Tue 10:36 :END: *** DONE Talking about convergent machines CLOSED: [2022-03-03 Thu 15:13] :PROPERTIES: :ARCHIVE_TIME: 2023-03-21 Tue 10:36 :END: Take this whole section about convergent machines and move to a separate early draft document but move distinguishing part up in the paper *** DONE First pragraph of process persistence and upgrade confusing CLOSED: [2022-03-03 Thu 15:22] :PROPERTIES: :ARCHIVE_TIME: 2023-03-21 Tue 10:36 :END: - dizzying zoo of acronymns confusing, just say it's a complicated space - Switch from process persistence to safe serialization - In fact process persistence sounds like the language snapshots - First paragraph needs to state the problem space *** DONE Second paragraph first sentence, also confusing CLOSED: [2022-03-03 Thu 15:53] :PROPERTIES: :ARCHIVE_TIME: 2023-03-21 Tue 10:36 :END: - Goblins has a mechanism that makes this easy - You really need it because since our security model IS the object reference graph, manually scribing and restoring is a sysphian(sp?) task ^- start with that last sentence, fix it up *** DONE Add upgrade problem after this CLOSED: [2022-03-03 Thu 15:53] :PROPERTIES: :ARCHIVE_TIME: 2023-03-21 Tue 10:36 :END: #+BEGIN_QUOTE However, this is wasteful; most serialized systems can be restored from a recipe of their construction rather than their current state at a fraction of the storage cost. #+END_QUOTE *** DONE Replace "all this" with "self-serialization" CLOSED: [2022-02-23 Wed 08:50] :PROPERTIES: :ARCHIVE_TIME: 2023-03-21 Tue 10:36 :END: Spritely Goblins provides a mechanism for all this which is built-in.[fn:aurie-history][fn:aurie-part-of-goblins] The serializer *** DONE Remove "Aurie" from "making Aurie performant" CLOSED: [2022-02-23 Wed 08:49] :PROPERTIES: :ARCHIVE_TIME: 2023-03-21 Tue 10:36 :END: *** DONE Unum and presence are technical terms CLOSED: [2022-02-23 Wed 13:27] :PROPERTIES: :ARCHIVE_TIME: 2023-03-21 Tue 10:36 :END: *** DONE Unum 3rd paragraph says most important thing CLOSED: [2022-02-23 Wed 13:27] :PROPERTIES: :ARCHIVE_TIME: 2023-03-21 Tue 10:36 :END: "This is the key thing!" #+BEGIN_QUOTE One difference between the unum pattern and most other distributed pattern literature is that the unum pattern is particularly interested in /distributed behavior/ rather than /distributed data/. #+END_QUOTE *** DONE pre-MVP list CLOSED: [2022-03-22 Tue 18:13] :PROPERTIES: :ARCHIVE_TIME: 2023-03-21 Tue 10:36 :END: **** DONE Comment out all TODOs CLOSED: [2022-03-22 Tue 16:50] **** DONE Run spell-checker CLOSED: [2022-03-22 Tue 18:00] *** DONE Jessica's remaining feedback CLOSED: [2022-04-02 Sat 17:43] :PROPERTIES: :ARCHIVE_TIME: 2023-03-21 Tue 10:36 :END: - [X] It took me (someone familiar with scheme, albeit not guile) multiple reasons to realise that cons was basically prepend I wonder if there’s a more obvious way of writing this? - [X] I wonder if we should specifically mention that cons is prepending to the list, this could just be a comment when using it. - [X] the update method does not use a named let, it’s making the ^editor become a new version of itself with the new information. - [X] Bit confused what’s happening with Roberts post. Is Robert drafting a post and sending it OOB to Lauren who is then making this or is the text: “Run by Lauren:” incorrect and this is in fact run by Robert? (Yeah I had it backwards) - [X] Not sure why but, I found the sealers implementation a bit difficult to understand. I think it is guile’s record stuff being less than obvious when you initially look at it. - [X] Something that’d be useful would maybe have the explanation of sealers/unsealers/brands with the usage of them and then either below or in the appendix have the implementation. - [X] The append to log message could be using <-np. I think this is probably intentional as I don’t think you’ve introduced <-np so maybe it’s good as it is. - [X] The explanation about Robert potentially giving admin-for-robert to someone else, it sounds like you’re only going to hold Robert accountable for actions he himself did (not someone who he’s passed it on to). Maybe it should be something like “Lauren will hold Robert accountable for any actions done with the admin-for-robert capability”. - [X] I think the explanation of promise pipelining would work better on page 9 & 10 where you introduce it. *** DONE Machine and vat :PROPERTIES: :ARCHIVE_TIME: 2023-03-21 Tue 11:09 :END: :LOGBOOK: - State "DONE" from "TODO" [2023-03-21 Tue 11:09] :END: Explain the added vat and machine diagram And think about "why we need vats" *** DONE near and far :PROPERTIES: :ARCHIVE_TIME: 2023-03-21 Tue 11:09 :END: :LOGBOOK: - State "DONE" from "TODO" [2023-03-21 Tue 11:09] :END: *** DONE Explain vat model stuff :PROPERTIES: :ARCHIVE_TIME: 2023-03-21 Tue 11:09 :END: :LOGBOOK: - State "DONE" from "TODO" [2023-03-21 Tue 11:09] :END: *** DONE Over and over: abstract need, then the goblins stuff :PROPERTIES: :ARCHIVE_TIME: 2023-03-21 Tue 11:09 :END: :LOGBOOK: - State "DONE" from "TODO" [2023-03-21 Tue 11:09] :END: *** DONE Footnote: coroutine support, splitchronous operations, re-entrancy attacks :PROPERTIES: :ARCHIVE_TIME: 2023-03-21 Tue 11:10 :END: :LOGBOOK: - State "DONE" from "TODO" [2023-03-21 Tue 11:10] :END: *** CANCELED new-spawn-blog-and-admin and etc are long. only include changes? :PROPERTIES: :ARCHIVE_TIME: 2023-03-21 Tue 11:18 :END: :LOGBOOK: - State "CANCELED" from "TODO" [2023-03-21 Tue 11:18] \\ We have the "*New:*" comments, and otherwise it would be a conceptual load :END: *** DONE Move all code sections (how) after the (what/why) :PROPERTIES: :ARCHIVE_TIME: 2023-03-21 Tue 11:18 :END: :LOGBOOK: - State "DONE" from "TODO" [2023-03-21 Tue 11:18] :END: - taste of goblins *** CANCELED Small check for style :PROPERTIES: :ARCHIVE_TIME: 2023-03-21 Tue 11:19 :END: :LOGBOOK: - State "CANCELED" from "TODO" [2023-03-21 Tue 11:18] \\ unclear :P :END: don't waste too much time on this *** DONE Add changelog and pre-release versioning :PROPERTIES: :ARCHIVE_TIME: 2023-03-21 Tue 11:19 :END: :LOGBOOK: - State "DONE" from "TODO" [2023-03-21 Tue 11:19] :END: *** DONE Export formats and makefile :PROPERTIES: :ARCHIVE_TIME: 2023-03-21 Tue 11:19 :END: :LOGBOOK: - State "DONE" from "TODO" [2023-03-21 Tue 11:19] :END: - PDF - HTML - org-mode - include source code alongside it *** DONE Add glossary appendix :PROPERTIES: :ARCHIVE_TIME: 2023-03-21 Tue 11:19 :END: :LOGBOOK: - State "DONE" from "TODO" [2023-03-21 Tue 11:11] :END: Stubbed it out, need to fill it in. *** DONE Juliana's review TODOs [6/6] :PROPERTIES: :ARCHIVE_TIME: 2023-03-22 Wed 15:22 :END: TODOs generated from Juliana reading the doc **** DONE Add vat creation to beginning of tutorial ***** DONE Introduce creating a vat for the first time ***** DONE Use ,enter-vat like in guile-goblins manual ***** DONE Use =[1]= syntax in code examples ***** DONE Switch between vats during newspaper examples **** DONE Change the introduction of async to add argument to 'greet call #+BEGIN_SRC wisp REPL> on (<- julius 'greet) _____ lambda (got-back) _____ format #t "Heard back: ~a\n" _____ . got-back ; prints (eventually): ; Heard back: [4] Hello Lear, my name is Julius! #+END_SRC Needs to have the target in the greet example **** DONE Error traceback in broken car factory example In the broken car factory example, defining car-vow invokes an error traceback. Let the user know this is normal! **** DONE Clarity in rewrite of spawn-adminable-post-and-editor make clearer during rewrite for spawn-adminable-post-and-editor that maple-valley-admin etc needs to be remade with new-spawn-blog-and-admin **** DONE Fix double "also" in paragraph before intro **** DONE narratives-before-implementation or no? :LOGBOOK: - State "DONE" from "TODO" [2023-03-21 Tue 10:45] :END: the narraptive-before-implementation approach makes following along with code examples difficult... perhaps a better approach would be breaking the implementations out entirely and merely having the narrative? or do implementation first Christine and Juliana declared this actually fine ;) *** DONE Add open standards and open source to beginning :PROPERTIES: :ARCHIVE_TIME: 2023-04-19 mer 10:52 :END: Just say everything that the Spritely Institute does is based on open source and open standards *** DONE Safe serialization spends a lot of time setting up before making a choice :PROPERTIES: :ARCHIVE_TIME: 2023-04-19 mer 10:52 :END: Footnote off the "one option would be..." debate *** CANCELED Switch spawn-post-and-editor to use cells instead :PROPERTIES: :ARCHIVE_TIME: 2023-04-19 mer 10:52 :END: - State "CANCELED" from "TODO" [2023-03-30 jeu 14:39] \\ Juliana and Christine discussed this and decided that using cells would obfuscate the power of =bcom= while also missing a chance to show off the power of closures *** DONE Add more end-of-line comments to code examples :PROPERTIES: :ARCHIVE_TIME: 2023-04-19 mer 10:52 :END: - State "DONE" from "TODO" [2023-04-19 mer 10:29] \\ LGTM, can add more in review if needed Did we do this? *** DONE spawn-post-and-editor introduces some new things :PROPERTIES: :ARCHIVE_TIME: 2023-04-19 mer 10:52 :END: - define* - #:key - cons One option is "see scheme primer for more details" **** DONE Explain define* :LOGBOOK: - State "DONE" from "TODO" [2023-03-21 Tue 11:12] :END: **** DONE Explain keywords Probably as part of the define-star footnote **** DONE Explain cons *** DONE Explain internal vat schematics diagram better :PROPERTIES: :ARCHIVE_TIME: 2023-04-19 mer 10:52 :END: #+BEGIN_SRC text .-----------------------. |Internal Vat Schematics| '=======================' stack heap ($) (actormap) .-------.----------------------. -. | | | | | | .-. | | | | (obj) .-. | | | | '-' (obj) | | | __ | '-' | | | |__>* | .-. | |- actormap | __ | (obj) | | territory | |__>* | '-' | | | __ | | | | |__>* | | | :-------'----------------------: -' queue | __ __ __ | -. (<-) | |__>* |__>* |__>* | |- event loop '------------------------------' -' territory #+END_SRC **** DONE Move diagram of vat schematics Diagram of internal vat schematics should probably move to [[#vat-model-of-computation][The vat model of computation]]. **** DONE Tie this together in turns as cheap transactions - State "DONE" from "TODO" [2023-04-19 mer 10:27] \\ This was already done; just moved the paragraph on it Every <- kicks off an atomic transaction as a /turn/. Within the atomic transaction, you can invoke near objects with $. Call this out in [[#turns-are-cheap-transactions][Turns are cheap transactions]] **** DONE Credit Mark Miller sufficiently - State "DONE" from "TODO" [2023-03-29 mer 14:44] \\ Maybe? It's hard to credit him sufficiently given how much he's contributed... *** DONE Better definition of vat :PROPERTIES: :ARCHIVE_TIME: 2023-04-19 mer 10:52 :END: And don't use "simply" #+BEGIN_QUOTE A /vat/ is simply an event loop that manages a set of objects which are /near/ to each other (and similarly, objects outside of a vat are /far/ from each other). #+END_QUOTE Maybe ask Randy *** DONE _bcom is a tiny distraction (maybe?) :PROPERTIES: :ARCHIVE_TIME: 2023-04-19 mer 10:52 :END: Just have the =bcom= and have it be unused, remove parenthetical about scheme conventions *** DONE clarify that =$= does not refer to a prompt :PROPERTIES: :ARCHIVE_TIME: 2023-04-19 mer 10:53 :END: *** DONE move Wisp/s-expr syntax explanation to appendix :PROPERTIES: :ARCHIVE_TIME: 2023-04-19 mer 10:53 :END: *** DONE "Using Guile, Wisp, and Goblins" appendix :PROPERTIES: :ARCHIVE_TIME: 2023-04-19 mer 10:53 :END: *** DONE Scheme Primer and guile-goblins "integration" :PROPERTIES: :ARCHIVE_TIME: 2023-04-19 mer 10:53 :END: - State "DONE" from "TODO" [2023-04-19 mer 10:28] \\ I think there's enough of this; may add more in later review but doesn't need to be a specific task imo We can lean on these a lot more heavily early on in the document, especially referencing the latter, currently not mentioned. That can reduce some of the explanations in this document. *** DONE Get Juliana's name in the AUTHORs at the top :PROPERTIES: :ARCHIVE_TIME: 2023-04-19 mer 10:53 :END: *** DONE REPL with prompt should have _ go to edge of REPL :PROPERTIES: :ARCHIVE_TIME: 2023-04-19 mer 10:53 :END: Eg, switch from: #+BEGIN_SRC wisp 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" #+END_SRC #+BEGIN_SRC wisp 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" #+END_SRC *** DONE Extract all uses of "I" and "we" :PROPERTIES: :ARCHIVE_TIME: 2023-04-19 mer 13:20 :END: *** CANCELED "Really counting on that full promise footnote!" :PROPERTIES: :ARCHIVE_TIME: 2023-04-19 mer 13:28 :END: - State "CANCELED" from "TODO" [2023-04-19 mer 13:27] \\ Redundant TODO Yep it's coming :) Juliana: ping Christine to work on this one *** DONE In-line TODOs :PROPERTIES: :ARCHIVE_TIME: 2023-04-19 mer 14:05 :END: **** CANCELED WAIT Explain usefulness of capability security in distributed contexts - State "CANCELED" from [2023-04-19 mer 14:05] \\ Disussed and decided context no longer neede Suggests to get recap from Danny - may need Christine on this ***** WAIT Reach out to Danny O'Brien :christine: ***** TODO Incorporate whatever Danny says **** DONE Explain alleviation of OCap tedium This part: # TODO (JFRED): How do you overcome the "that sounds really tedious" # bit? # # I think it could be done in inline - maybe say that solitaire() # now is actually doing all the file creation etc # # "Installation endowment" **** DONE Clarify what an "object", possibly w/ illustration - State "DONE" from "TODO" [2023-03-27 lun 10:49] \\ This was already done This is the convo starting with: # TODO: # (KATE): This first sentence feels clear to ocap people but # maybe non-ocap people :) **** CANCELED Appendix on following code examples - State "CANCELED" from "TODO" [2023-03-21 mar 12:02] \\ This is better done in-line **** DONE Clarify =spawn=, compare/contrast with =new= et al. # BALDUR: # Christine is using "spawn" in terms of create, # akin to "new" or "make" or "create" # "spawn" is often used in terms of make this new process # and get it running # If people think it spawns a process, it's a problem? **** DONE Clarify =bcom= and state management better/with simpler state machine # KATE: State machine example is an interesting one for use of bcom # Also if something is foreign to me, it's helpful that it might # sound foreign. If above this example you say "we're about to do # something that might be strange to you..." this lets the reader # know that this is maybe new **** DONE Describe =methods= as "syntax sugar"; explain "macro" in footnotes - State "DONE" from "TODO" [2023-03-23 jeu 10:08] \\ Also modify the language around =methods= to shorten the body text Done already in Scheme Primer, maybe we can just link to that? Make this a footnote that links to that **** DONE Check formatting on explanation of return in Scheme - State "DONE" from "TODO" [2023-03-21 mar 11:51] \\ LGTM **** CANCELED Move blog module header to appendix - State "CANCELED" from "TODO" [2023-03-21 mar 16:44] \\ Appendix is moving inline **** DONE Simplify up =define-values=, manual unpacking :LOGBOOK: - State "DONE" from "TODO" [2023-03-22 Wed 15:33] :END: Not entirely sure what this means; it looks relatively clean and consistent to me **** DONE Example of un-spoof-ibility of posts # TODO: Probably put an example of such a failed attempt here. How will this affect flow? Do your best attempt Juliana :) **** CANCELED Refactor blog to hide editors by default :LOGBOOK: - State "CANCELED" from "TODO" [2023-03-22 Wed 15:39] \\ Nobody knows what this means anymore so it couldn't be important! :END: How? **** CANCELED Clean up =spawn-adminable-post-and-editor= implementation :LOGBOOK: - State "CANCELED" from "TODO" [2023-03-22 Wed 15:41] \\ Not for Juliana to do! :END: It's not possible to clean this up until Christine adds the multiple-value-return feature to Goblins so we won't make this as a Juliana task ;) **** DONE Rewrite [[security-relationships-lessons-learned]] to emphasize ocap power Add words so that it's not just "sufficient", it sounds cool and like we can do awesome composable things because we can ;) **** DONE Describe OCapN in handwavey way :LOGBOOK: - State "DONE" from "TODO" [2023-03-22 Wed 15:43] :END: **** DONE Link to OCapN repo https://github.com/ocapn/ocapn *** DONE More feedback :PROPERTIES: :ARCHIVE_TIME: 2023-04-19 mer 14:05 :END: - Lauren should go on vacation sooner in the example - Lauren doesn't need to upgrade software to create attenuated systems Come back to this later, talk with Christine about it *** DONE Add license CC-BY-4.0 and Apache dual-license :PROPERTIES: :ARCHIVE_TIME: 2023-04-19 mer 15:58 :END: *** DONE Related works :PROPERTIES: :ARCHIVE_TIME: 2023-04-20 jeu 11:38 :END: *** DONE Write footnotes :PROPERTIES: :ARCHIVE_TIME: 2023-04-20 jeu 11:39 :END: Christine needs to dictate what these are and then Juliana can fill in **** DONE confused-deputies **** CANCELED pola-polp - State "CANCELED" from "TODO" [2023-04-20 jeu 11:39] \\ Moved to separate TODO ***** DONE Reach out to Alan Karp ***** CANCELED Incorporate notes **** DONE file-handles-usually-are-ocaps - POSIX supports file handles as objects to be passed between processes - essentially, you ask the kernel for a file handle (integer) - basically a capability - "if you know what file handles are, they're ocaps" - "you can pass a specific file handled instead of searching on disk" **** DONE making-launching-solitaire-convenient **** CANCELED typing-seals-and-signatures - State "CANCELED" from "TODO" [2023-04-19 mer 14:32] \\ Christine says it's not that important - can implement sealers three ways (Security Kernel ...): - protected type pattern (what Spritely does) - "coat check" pattern - booth is sealer - ticket is sealed object - pickup booth is unsealer - can use a hash table for this - "register" pattern - sealer and unsealer have access to same temp space - sealing gives procedure to put something there - unsealer takes this procedure, puts thing there, then takes it out **** CANCELED vat-terminology - State "CANCELED" from "TODO" [2023-04-19 mer 16:10] \\ Interesting historical footnote, but irrelevant to the paper - the name "vat" comes from the philosophical experiment about "how do you know you're not just a brain in a vat" **** DONE classic-actors **** DONE sessions-severance - the only time it matters whether or not an actor is local is: - objects within same process are certain to be able to communicate - network partitions introduce possibility of session failure - it's possible to mitigate with store-and-forward networks etc. **** DONE full-promise-vision term "promise" may be familiar from JavaScript, derived from E/Joule; these are not complete E promises incl. pipelining, but Goblins implements these