A key goal of Spritely is that different instances can be written in different languages as long as the code obeys the protocol. Still, a reference implementation will be important to attract developers. Criteria if that implementation is to achieve its goals are, in order of importance,
- Familiar to a wide audience (rules out APL)
- Memory safe (reduces cognitive effort and vulnerabilities)
- Availability of needed libraries (especially crypto, but also UI)
- A decent development environment (because developers will delta off it)
- Performant enough (can’t be so slow as to be annoying, factors of 10 matter)
- Small enough memory footprint (not too important, but I’d hate to see it be 10GB)
Spritely is comitted to providing reference implementations in two languages/environments.
@alanhkarp - Is “Memory Safe” the only security-ish feature required? Doesn’t strict mode in JS do more than that?
I’m also not 100% sure about the library-availability requirement as we’re likely to need to create capability safe ones. Perhaps rephrasing that might include oCap compliant libraries?
Tamed libraries are very important, but I don’t know if any exist. Is the work Stiegler did for Caja still viable? I expect bit rot has set in for the tamed Java libraries.
Given Oracle’s apparent desire to lock down Java with patents and license terms, I think it might be better to avoid it. [bias disclosure: I am disposed against Java based on years of programming in it.]
As someone who took a rabit hole dive into JavaCard I second this. No java, it is pretty terrible pl.
@hibbert - Has Agoric published/shared anything about hardening any of the popular UI frameworks?
Has Agoric published/shared anything about hardening any of the popular UI frameworks?
I’m not familiar enough with any of the frameworks to have participated in discussions concerning them, so I don’t know how they’re being handled.
I’ve held off on replying to this one until I had the energy to ramble a bit.
Of course, Spritely already does have [a] reference implementation[s]… two of them! One is in Racket, and one is in Guile. These are both in scheme, so it may appear that this is a trivial port, but you’d be underestimating the amount of effort between these implementations because of wide divergence between the languages. That said, we do want a non-scheme, non-lisp implementation (and I agree that JS is the most likely target… the question is whether or not a port needs to be done at all, if demonstration with Agoric’s tooling can be done, or if cross-compilation to JS/WASM is possible. But that’s for the kernel-layer… Goblins/Swingset, basically. That’s just the foundation for Spritely’s work.)
However, the fact that Guile and Racket are much more similar than most but not quite as similar as they appear was intentional for the porting effort. Rather than simply copy-pasting the Racket code and massaging it until it was valid Guile code, I ported from Racket in Guile in stages… see the pre-goblins drectory in the Guile-Goblins repo. This done with the very intent that we’d be able to port to other languages in the future, and also to give me a chance to reassess the fundamentals of Goblins. I was surprised even though Goblins was mostly manually re-typed-in in phases, I ended up finding that most of the design decisions that have been made felt like the right ones. That’s not usually the case for something like this, so it increased my confidence in Goblins’ design greatly. It also means that porting elsewhere, and having a workflow for porting that can be reproduced, is very possible.
Now, @alanhkarp gave a list of requirements at the top. I agree with them, but I think there are other desirable properties which are missing. More soon… I will expand on the thinking, rationale, and some projections, in incremental pieces.
I’ve advocated in the past for rust, for a few reasons: it both has a lot of momentum and a chance to influence the default inclinations of its users, it has a community that is already experimenting with capabilities, and it’s sufficiently different from Scheme (static type system, AOT compilation, C-style, close to the metal) that it would demonstrate that Spritely can work indepedently of those language characteristics. There are also a lot of eyes on it right now.
I also think that it’s worth reaching out to language communities who are much (much!) smaller but would benefit from a collective connection to what has the potential to be a multi-language object marketplace.
The descendants of Smalltalk were built for that world in some ways, especially Newspeak with its capability-adjacent security model (Gilad has been doing some renewed work on it, I hear).
Common Lisp would be an easier hop and has been getting some “so retro it’s fun again” traction recently (I remember when vi the editor suddenly leapt back into popularity as a new generation discovered its obscure appeal).
Really it’s less about “what can this language do for Spritely” and more “what can Spritely do for this language”. Some language ecosystems have a niche that Spritely would fit nicely into — either because secure networked objects haven’t been seriously worked in that ecosystem, or that the previous solutions have atrophied away. Others, I think, have other similar equivalents or a huge diversity of competing choices which makes it tricky for Spritely to get a foothold. Python’s Twisted architecture for instance, or C++’s vast back catalog would make it hard for folks to notice Spritely or wire it into existing work.
Also my language learning time allocation is going towards rustlang, so if anyone starts implementing things in that, it may be good for me to try following along.
We don’t harden any of the popular UI frameworks. We integrate our hardened JS code with them, though… with no small amount of wailing and gnashing of teeth.
I suppose most of the wailing is around build tools: front end dev requires a bundler, and bundlers tend to mangle the SES shim.
The most recent solution I have seen to this is:
but I tried to reproduce those results in a project of my own without luck.
I suppose this post is more or less completely opaque. Here’s hoping we find time to document it to some extent… How to use Hardened JS with react/vue/etc? · Agoric/agoric-sdk · Discussion #6494 · GitHub
The rust runtime is the ordinary C / assembly runtime. Nothing prevents one object from clobbering another without its consent.
Memory safety is a bedrock requirement for ocap security, no?
Meanwhile, cap-std — Rust filesystem library // Lib.rs is pretty interesting…
I still think this idea is not completely crazy:
OOoh! Glad to see someone is putting in that work I’ve been mulling over how I would implement something similar if it ever got to it. So glad I won’t have to
He he, I think you’ll get as many language suggestions as there are developers with their own preference
Bringing in Erlang/Elixir. Not the biggest, most popular language but growing in popularity (e.g. by attractiveness of Phoenix LiveView for webapps). It is nice to have a reference impl. based on FP paradigm. And Erlang/OTP has a native actor model. The language is specifically designed for distributed, fault-tolerant applications (originating from Ericsson for use in telecoms applications).