[Ask for Feedback] I created a simple typed object-capability language Jo

[fengyun liu]

I've been studying and learning about object-capability systems for over 10 years. I firmly believe that ocaps as a reasoning principle in the language is the right way to go for building secure systems.

Following Mark Miller's E language, David Wagner et al's Joe-E, I'm building a typed ocaps language:

https://github.com/typescope/jo

In essence it is just a simple ocaps language with an interesting way to propagate capabilities (contextual capabilities) and with a compiler design trick for allowing FFI in trusted world but not in untrusted world.

The web site uses "compile-time sandboxing" --- that is just a way to speak to programmers, because I find "capability system" does not speak much to them.

The formal capability model is explain here:

https://github.com/typescope/contextual-capability

The language and tools are still young. I'll appreciate your feedback to help make it better and more usable for the world.

[Alan Karp]

The problem this paper is addressing, namely getting capabilities deep into the call chain without including them in every call, sounds familiar.  I think we talked about it a year or more ago, but I don't remember what it was called.  The word "fluid" comes to mind, but I can't find the discussion in my email.

--------------
Alan Karp

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/cap-talk/a9b52cb6-7042-43c0-9fca-baaa8728cde3n%40googlegroups.com.

[William ML Leslie]

On Tue, 23 Jun 2026 at 13:57, Alan Karp <alan...@gmail.com> wrote:

The problem this paper is addressing, namely getting capabilities deep into the call chain without including them in every call, sounds familiar.  I think we talked about it a year or more ago, but I don't remember what it was called.  The word "fluid" comes to mind, but I can't find the discussion in my email.

https://doc.guix.gnu.org/guile/latest/en/html_node/Fluids-and-Dynamic-States.html ?

--

William ML Leslie

A tool for making incorrect guesses and generating large volumes of plausible-looking nonsense.  Who is this very useful tool for?

[William ML Leslie]

On Tue, 23 Jun 2026 at 15:12, William ML Leslie <william.l...@gmail.com> wrote:

https://doc.guix.gnu.org/guile/latest/en/html_node/Fluids-and-Dynamic-States.html ?

Though this reads more like the implicit arguments from Scala, Agda, ATS or Idris i.e. where the concrete value of the argument can be inferred from the type signature and the lexical context.

[Alan Karp]

That's it.  Thanks.

--------------
Alan Karp

--

You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CAHgd1hGXJMe%2BOot4SiQEdDW1QdU5-GTh77tKoZMEnD%2B4E_u6kw%40mail.gmail.com.

[Matt Rice]

On Mon, Jun 22, 2026 at 8:16 PM fengyun liu <gur...@gmail.com> wrote:
>

It's unlikely I'll finish reading before I have to leave, initially I
was perhaps a bit confused and skeptical of 1.3 contributions point 4
"Solving the usability problem of passing authorities", My initial
reaction was that explicit hand-off, such as handing off the baton
in a relay race is a good thing, and I was skeptical of making this
hand-off implicit.

But then I got to thinking about section 9.2 of Robust Composition,
and all the other ways besides introduction that connectivity can
appear. I would suppose this feature is probably a form of
connectivity by endowment.

[fengyun liu]

Thank you, Matt. It is reasonable to question whether making
capabilities implicit is a good idea or not.

It's a usability problem we conjectured, but the idea is not yet
supported by any empirical evidence --- Jo is an experiment to test
one solution.

The hypothesis that passing capabilities in a program becomes a
usability problem originates from the observation that passing
parameters in an insecure language already poses a problem: that is
why there are many dependency injection frameworks out there. We
conjecture that to make secure programming practical, the usability
problem should be addressed in some ways.

The solution reminds of dynamic scoping in Lisp-family languages, that
is not an accident: the following paper by Lewis(2000) is an attempt
to make dynamic scoping safe in a type system

Implicit parameters: dynamic scoping with static types
https://dl.acm.org/doi/10.1145/325694.325708

Contextual capabilities are similar to Lewis(2000) but different in
that the parameters are not tags, but global names.

Java Scoped values also come from the lisp background:
https://openjdk.org/jeps/506

Dynamic scoping has a bad reputation, and commonly regarded as a bad
programming pattern. Will type-safe dynamic scoping change that? We
still need evidence for that. But nevertheless, I agree that the extra
power should be used sparingly.

>
> --
> You received this message because you are subscribed to a topic in the Google Groups "cap-talk" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/cap-talk/z6jaSrDq_GQ/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to cap-talk+u...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CACTLOFo%3DTFnsukEt8caEAD26nz2-rov4GWpBPrzv6g9FfEt9fg%40mail.gmail.com.

[Jonathan Aldrich]

Hi Fengyun,

It's great to see your work on this issue!  The Wyvern language my group worked on a while back also used typed capabilities in order to control access to FFIs, you might be interested:

1. A Capability-Based Module System for Authority Control. Darya Melicher, Yangqingwei Shi, Alex Potanin, and Jonathan Aldrich. Proc. European Conference on Object-Oriented Programming (ECOOP), June 2017.
2. A Case Study in Language-Based Security: Building an I/O Library for Wyvern. Jennifer Fish, Darya Melicher, and Jonathan Aldrich. Onward! 2020.

The first is an overview of our approach to capabilities and some theory, the second is a case study of using it to develop a reasonably featured I/O library.

In Wyvern, capability passing is explicit because we wanted capabilities to be visible, so we did not address what you call "the usability problem of passing authorities."  We did try to make the syntax for passing capabilities between modules lightweight.  I agree there are usability tradeoffs here, so it will be interesting to see how your approach develops further.

Good luck with your research!

Best,

Jonathan

You received this message because you are subscribed to the Google Groups "cap-talk" group.

To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CAKFJmEF4p4OnXMCXTFmbgN2YYFT854uH0QaUaCZqyM52%3DbY-Cg%40mail.gmail.com.

[fengyun liu]

Hi Jonathan,

Thank you very much for the pointers, I added them to the related work.

The design of the I/O library looks interesting to me. It is related to the question of how to restrict FFI in a secure language.

I see Wyvern represents a principled and typical approach: doing FFI requires special capability, therefore the "java" capability.

Jo did that in a less principled way and optimized for usability. FFI is restricted in a two-world architecture via a compilation trick:

(1) FFI is provided via a library with intrinsics

(2) The compiler separates checking libraries from linking libraries.

(3) A transitive confined world of programs & libraries where the FFI library is not reachable

(4) A trusted world where the platform-dependent FFI library is available

Jo's stdlib lives in the confined world, the language runtime lives in the trusted world.

The usability advantage is that in enforcing compile-time sandboxing: 

- The guest program has no FFI, transitively

- The trusted sandbox runtime has FFI (ambient authorities), freedom and convenience in implementing the runtime

This gives programmers an escape hatch in the same language without loosening the guarantees for the compile-time sandboxing.

We are yet to see whether this design indeed improves usability or it scares programmers who uphold security over convenience.

Fengyun

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CANwk4UYePYukne5xRsYk5pYodBhgFd8G0D4DTaHXGi_X5r2_gg%40mail.gmail.com.

[Jonathan S. Shapiro]

On Mon, Jun 22, 2026 at 8:57 PM Alan Karp <alan...@gmail.com> wrote:

The problem this paper is addressing, namely getting capabilities deep into the call chain without including them in every call, sounds familiar.  I think we talked about it a year or more ago, but I don't remember what it was called.  The word "fluid" comes to mind, but I can't find the discussion in my email.

It's a language-agnostic problem. For example, it's a big impediment to building libraries in KeyKOS/EROS/Coyotos. And the problem with reaching for dynamically scoped solutions is that it gets us right back into ambient authority.

This is one of those things that ultimately needs to be solved in hardware. It is why I wanted to look at adapting some of the CHERI work (though for all I know they may already have it solved). It appears to be a very solvable problem.

Unfortunately, some idiot decided US distribution of AMD FPGA parts should go through Canada, an even bigger idiot decided to tack on a set of tariffs that doubled the board prices, and then the market decided AI was important and we hit a supply chain problem with DRAM that is adding yet another multiplier. This drove a $1700 prototyping board north of $4500, which is more than I can afford right now.

Which is why I've made no progress on that.

Jonathan

[Raoul Duke]

I think there are a few UX/DX aspects here. How does a leaf-of-the-call-stack invoke a capability? Which means how does it get it?

Passing an explicit individual argument all the way through is one extreme. Dynamic ambient access is an opposite extreme. 

Depending on what kind of code is being used, I guess one could generate and test other pure software approaches? (I just mean from an ascii perspective of typing in the source code; things like side channel attacks need hardware fixes.)

Strawperson: If one trusts the compiler, it can statically generate and inline a token per leaf node. Then the leaf can call a directory (an instantiated object, or a service) with the token and the desired operation id-name: the directory is ambient but still constrains rights. The directory could be explicitly threaded down the call stack if desired. (Or, say, the "token" is a breadcrumb list of the callstack.)

Just trying to say that it would be good to codify the various dimensions: dynamicness vs. staticness of sundry aspects of the intended systems. Solutions do not have to be one size fits all?

[fengyun liu]

On Mon, Jun 29, 2026 at 6:55 PM Jonathan S. Shapiro <jonathan....@gmail.com> wrote:

On Mon, Jun 22, 2026 at 8:57 PM Alan Karp <alan...@gmail.com> wrote:

The problem this paper is addressing, namely getting capabilities deep into the call chain without including them in every call, sounds familiar.  I think we talked about it a year or more ago, but I don't remember what it was called.  The word "fluid" comes to mind, but I can't find the discussion in my email.

It's a language-agnostic problem. For example, it's a big impediment to building libraries in KeyKOS/EROS/Coyotos. And the problem with reaching for dynamically scoped solutions is that it gets us right back into ambient authority.

Thank you Jonathan. This is interesting. Could you give some pointers about the impediment to building libraries in KeyKOS/EROS/Coyotos? We tried to convince PL researchers that this is a problem in real-world engineering but failled (rejected twice and we gave up).

Regarding "dynamically scoped solutions ... gets us right back into ambient authority", both Lewis (2000) and contextual capabillities have provided a static discipline for dynamic scoping --- which is safe and statically trackable, quite different from Lisp-like dynamic scoping.

In particular, even though Jo currently performs capabililty inference, the model of contextual capabilities does give language designers the flexibility to require explicit specification on function signature (or only require explicit spec on public functions).

In the model of contextual capbilities, a capabillity is a lexically defined name of a given type, but dynamically bound and propogated. That is also a difference from Scala-like implicits, it's type-based mechanism instead of name-based.

The programmers can click a capability name, and go to its definition and inspect its documentation and contracts: this looks much like static scoping, which is a difference from Lewis (2000).

 

This is one of those things that ultimately needs to be solved in hardware. It is why I wanted to look at adapting some of the CHERI work (though for all I know they may already have it solved). It appears to be a very solvable problem.

Unfortunately, some idiot decided US distribution of AMD FPGA parts should go through Canada, an even bigger idiot decided to tack on a set of tariffs that doubled the board prices, and then the market decided AI was important and we hit a supply chain problem with DRAM that is adding yet another multiplier. This drove a $1700 prototyping board north of $4500, which is more than I can afford right now.

Which is why I've made no progress on that.

Jonathan

--
You received this message because you are subscribed to a topic in the Google Groups "cap-talk" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/cap-talk/z6jaSrDq_GQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to cap-talk+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CAAP%3D3QNJnuueKF7BtJRdai_MRD5-7H7-2CBt-KpR2WTGaKDU7w%40mail.gmail.com.

[Mark S. Miller]

On Mon, Jun 29, 2026 at 9:55 AM Jonathan S. Shapiro <jonathan....@gmail.com> wrote:

On Mon, Jun 22, 2026 at 8:57 PM Alan Karp <alan...@gmail.com> wrote:

The problem this paper is addressing, namely getting capabilities deep into the call chain without including them in every call, sounds familiar.  I think we talked about it a year or more ago, but I don't remember what it was called.  The word "fluid" comes to mind, but I can't find the discussion in my email.

It's a language-agnostic problem. For example, it's a big impediment to building libraries in KeyKOS/EROS/Coyotos. And the problem with reaching for dynamically scoped solutions is that it gets us right back into ambient authority.

This is one of those things that ultimately needs to be solved in hardware.

Hi Jonathan, I am not connecting the dots at all. Are we talking about the same "it", or even related ones?

I understood this conversation to essentially be about fluid scoping, and whether Fengyun's type system mitigates its problems enough to be safe-enough to use in ocap code. Fluid scoping is already much safer than dynamic scoping while providing all the utility that people want from dynamic scoping. The "call chain" Alan refers to might make it seem to be an implementation concern rather than a semantic one, but I don't think either Fengyun or Alan actually mean to focus on that level of abstraction. (Fengyun and Alan, please correct me if I'm wrong.) 

Instead, I'd rephrase in terms of dynamic (or temporal) scope (from time of entry to a block or callee until time of exit, except as shadowed by a nested dynamic/temporal scope). As contrasted with lexical (or spacial) scope (textually within this block or function, except as shadowed by a nested lexical scope). Fluid scope intersects the two: A fluid scoped variable designation is held in a lexical variable. The value of this fluid variable changes temporally, but access to this changing fluid variable is gated on access to the lexical variable that "names" it. https://github.com/tc39/proposal-async-context does this for JS, with many of the gotchas worked out as well as they could be.

All this seems to me to be at the level of abstraction of the semantics of programming languages. Or, at least at the level of abstraction of a high-enough-level virtual machine that the argument passing and context switching of an ocap call (message send, method invocation, ...) is part of the semantics of that VM. But that is not the VM "solving" the problem, it is the VM helping implement that abstract semantic property. If the language running on that VM does not surface the fluid scoping semantics, than for systems written purely on that language, the VM feature may as well not exist.

As for my own opinion of fluid scoping, I'll start a separate thread.

 

It is why I wanted to look at adapting some of the CHERI work (though for all I know they may already have it solved). It appears to be a very solvable problem.

Unfortunately, some idiot decided US distribution of AMD FPGA parts should go through Canada, an even bigger idiot decided to tack on a set of tariffs that doubled the board prices, and then the market decided AI was important and we hit a supply chain problem with DRAM that is adding yet another multiplier. This drove a $1700 prototyping board north of $4500, which is more than I can afford right now. 

Which is why I've made no progress on that.

Jonathan

--

You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CAAP%3D3QNJnuueKF7BtJRdai_MRD5-7H7-2CBt-KpR2WTGaKDU7w%40mail.gmail.com.

[Mark S. Miller]

Also, fluid scoping is straightforward enough to implement that I do
not see any need for hardware help. Conventional hardware is enough.

> To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CAK-_AD5uakmtHV6kG4pBKzPK%3DNU%3DZTzaVOxgPeJfhNqOir0WzA%40mail.gmail.com.



--
Cheers,
--MarkM