[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.