Pierre Thierry (Sep 01 2026 at 17:13): Pierre Thierry (Sep 01 2026 at 17:13):In my introduction, I mentioned capability-based security, and I think it could be a great addition to Roc, especially since it doesn't start with the assumption of "ambient authority", meaning that things like opening files and doing network connections is implicitly always available.
If people want to read up on the subject, there are two very good introductory papers:
If you want to delve a bit deeper, there's Mark Miller's PhD thesis, Robust Composition: Towards a Unified Approach to Access Control and Concurrency Control. That one could of special interest to Roc because it describes the E programming language with its semantics that make concurrent programming more robust. Providing E's concurrency model as a Roc platform would be extremely nice, I think!
But without going that far, providing an API to do side-effects that doesn't rely on ambient authority and instead on capabilities, meaning that a function could only do those side-effects if passed the appropriate authority-giving value, would be a first great step. The Bytecode Alliance has started doing that for Rust with their cap-std.
I'd love to help!
Karl (Sep 01 2026 at 17:40):I didn't mention it in the other thread but I read through those not too long after they were published.
Anything that's security interesting is entirely within the purview of the platform and there's nothing special about basic-cli over something you'd write yourself. The seahaven platform is my attempt on this topic. The platform provides the normal APIs which will simply not do stuff outside the configured boundary. The platform is using cap-std.
Karl (Sep 01 2026 at 17:40):If anybody else is doing similar work, they haven't told us about it.
Pierre Thierry (Sep 02 2026 at 01:03):Karl said:
The seahaven platform is my attempt on this topic. The platform provides the normal APIs which will simply not do stuff outside the configured boundary. The platform is using
cap-std.
I'm surprised, with Roc's platform, I would expect that keeping the "old" API isn't needed, especially with Roc being still quite new.
I didn't find this seahaven project, could you link to it?
Karl (Sep 02 2026 at 01:04):https://github.com/grayrest/seahaven
Strictly speaking, keeping the APIs isn't required but it makes migrating a project from basic-cli easier and I don't have a specific reason to change the APIs.
Pierre Thierry (Sep 02 2026 at 13:22):My intuition is usually that a paradigm change needs to be reflected in the way people think and work, but I know I've already been surprised a couple of times how far people can be transparently led into such a change…
Is it possible to build one application with several platforms? I would imagine that the best of both worlds would be a transparent wrapper like you did for legacy code, with the ability to give that wrapper explicit capabilities, and explicit capabilities as the default for new code… I don't know if that's possible.
Anton (Sep 02 2026 at 14:37):Is it possible to build one application with several platforms?
Currently it is one application one platform, but if another platform has the exact same API for the functions you use, switching to it is trivial. There is also the pure app idea.
Luke Boswell (Sep 02 2026 at 21:51):I'm very interested in general ideas around this. I've been definitely focussed elsewhere recently, but would love to see any ideas for hardening basic-cli or basic-webserver (or any platform I work on) using methods that fit naturally with Roc. I feel like there are lots of directions to go in any it's not yet clear which patterns will work the best.
Luke Boswell (Sep 02 2026 at 21:54):I see at least a few different approaches to achieve this.
You could add cli flags that the host intercepts and controls e.g. --host-dirs ./ (or use some other method like adding a config file) and the app never sees those. The host could manage the capabilities under the hood completely transparently from the application, and simply return an error -- or do the pop-up box confirmation thing.
Luke Boswell (Sep 02 2026 at 21:55):Shape or tailor the API's around capabilities like the Rust cap-std folks are doing
Pierre Thierry (Sep 02 2026 at 22:07):Luke Boswell said:
You could add cli flags that the host intercepts and controls e.g.
--host-dirs ./(or use some other method like adding a config file) and the app never sees those. The host could manage the capabilities under the hood completely transparently from the application, and simply return an error -- or do the pop-up box confirmation thing.
That appraoch leaves the possibility of confused deputy attacks, which we can bet will become more and more of a problem with AI. That legacy approach, though, is easier to write safely through explicit capabilities, so I wouldn't see the two as choices or competitors, more the "host managed" being a consumer of the capability API.
Luke Boswell (Sep 02 2026 at 22:11):@Pierre Thierry would you propose any changes to basic-cli (for example) that move us towards the ideal? Or are you thinking more broadly in terms of language semantics, or maybe the roc cli itself?
Last updated: Sep 03 2026 at 15:16 UTC