What is the current status of SES, tinySES and Jessie?

I'm discovering SES, and the adjascent projects, tinySES and Jessie, which all seem interesting in their own right.

I'm a bit puzzled by the state of the affairs though. The TinySES repo I could find points to this fork as current, but that link is actually a redirect to Jessie, which itself looks inactive.

On top of that the Google Caja project which relied on SES has been archived...

Endo, a SES implementation, looks alive, but the spec itself has been idle for a long time.

Is the TC still interested in any of these projects? TinySES was the most promising AFAI'm concerned, but it looks dead, even though there are still references to it in the Jessie docs.

There are regular SES meetings that are recorded and uploaded. Lots of interesting conversations happening!

1 Like

Many thanks! That's pretty good to know.

So, am I correct that TinySES and Jessie are not handled by the TC at the moment, but they are personal projects of TC members ?

Oh, I see the Jessica architecture has been discussed recently at a meeting :-) Edit: oh, not so recently, the playlist is backwards timewise...

Thank you for inquiring about SES, or as we among the champion group have been calling it recently, “Hardened JavaScript”. I can offer a snapshot of the status of some SES proposals.

In summary, please look to the Endo and Moddable/XS repositories for practical vetting of Compartment, lockdown, and harden, from which we intend to update our proposals. Please join the SES strategy meetings to participate in the evolution of these and related proposals. Please anticipate joining the TC39-TG3 meetings, since this will be the first group to hear proposal updates.

The SES proposal is very stale and reflects an earlier state of the SES architecture which resulted in the recent advancement of Shadow Realms. The champions have pivoted and the next planned action is to work toward advancing the Compartment proposal. We intend to reduce the Compartment proposal to provide the missing JavaScript module loader API and nothing more.

Then, we intend to rearchitect the SES proposal under the moniker Hardened JavaScript, which will cover two coupled language features: Lockdown and Harden. Lockdown is a function that transforms the current JavaScript realm into a Hardened JavaScript realm. Lockdown makes some modifications to the graph of language intrinsics including the creation of a subgraph of “shared frozen intrinsics” that can be safely shared by multiple compartments.

The champion group has most recently focused on vetting the API’s we intend to propose, in the “ses” shim (in the Endo repository) and the XS JavaScript engine. Moddable and Agoric have been collaborating to implement Compartments and other proposals, converging these implementations so that we can be sure that the proposal is implementable both as a shim and native code.

In the Endo repository, we go on to demonstrate practically that we can use Compartments to virtualize a module loading behavior that is consistent with Node.js packaging conventions and capable of supporting third-party module records for CommonJS and WASM, for example. It is necessary for Compartments to be able to virtualize the host behaviors of both Node.js, the web, and embedded systems like XS, since the module specification does not provide these opinions, so we have carefully designed Compartments to separate concerns like module specifier referrer resolution and import.meta. XS verifies that Compartments are coherent with top-level-await. We expect to need to do more work to verify that they are coherent with import assertions.

This new architecture frees Compartments to advance as a generally useful tool, not just for hardened JavaScript but also for implementers of bundlers, import mappers, test scaffolds, and plugin ecosystems. Then, the Lockdown and Harden proposal treats Compartments as evaluators, just as with Function and eval. After Lockdown, each Compartment has its own Compartment, Function, and eval that are isolated to that compartment, though all of these share the same frozen intrinsic prototype.

At Agoric, we’ve explored using Jessie as a language subset that’s enforced with a linter to make certain programs easier to review or audit. Jessie is analogous to JSON. If it is successful as a compiler target in the wider language community, I can imagine many years from now proposing the inclusion of a Jessie language subset evaluator to the language.


As another lurker: thanks a lot for the concise recapitulation of the current state! It's a bit hard to follow what's going on in that area without being deeply involved.

This sounds great!

1 Like

Thanks for the update @kriskowal . I probably will not have the time to attend the meetings, but thanks for the invitation !