Epic: make Common Lisp and JavaScript actors first-class peers behind one host API #57

New issue

Open

opened 2026-08-26 07:36:39 +00:00 by lost-rob0t · 0 comments

lost-rob0t commented

2026-08-26 07:36:39 +00:00

(Migrated from github.com)

Goal

Quasar must support both Common Lisp actors and JavaScript actors as first-class peers.

Neither language is secondary. Both actor runtimes receive the same host capabilities through a language-neutral contract.

Core invariant

Actor abilities are determined by principal/capability policy, not implementation language.

Do not create separate security models such as js_actor vs lisp_actor authority.

Language-neutral Actor Host API

Define one versioned host surface covering at least:

actor spawn/message/stop/status
document query/get/save/remove
graph query/mutation
tools
MCP calls
HTTP/network access
artifacts/files where permitted
memory
targets
research/Auto-Dig lifecycle where permitted
Quasar UI/event integration where appropriate

Both runtimes must map to the same semantic operations and typed errors.

Common Lisp actors

supervised lifecycle
bounded mailbox/resource controls
capability checks at every privileged boundary
stable actor identity
async messaging semantics matching JS actors

JavaScript actors

preserve convenience and browser/local JS actor support where policy permits
bring capabilities/error semantics/lifecycle to parity with Common Lisp
no special bypass because an actor runs in browser/Electron

Spawn authority

All actor spawns, including child/recursive spawns from either language, must cross the same authoritative host gate. This is required for per-user quotas and resource policy.

Relationship to existing work

Build on #2's Common Lisp control-plane migration and current principal/capability model rather than creating a parallel runtime authority.

TDD acceptance

Tests first should prove:

equivalent Lisp and JS actors can invoke the same allowed host operations
denied capability produces equivalent stable denial semantics in both runtimes
one language cannot obtain a capability unavailable to the other solely due to runtime implementation
child spawn crosses the same quota/auth gate
actor crash/timeout/mailbox limits are supervised consistently
audit records identify actor/principal/capability without depending on language-specific policy

Non-goals

no requirement that implementation internals be identical
no unrestricted JS renderer access to Node/Electron
no automatic init.lisp/operator-level privilege for Common Lisp actors

## Goal Quasar must support both **Common Lisp actors** and **JavaScript actors** as first-class peers. Neither language is secondary. Both actor runtimes receive the same host capabilities through a language-neutral contract. ## Core invariant Actor abilities are determined by principal/capability policy, not implementation language. Do not create separate security models such as `js_actor` vs `lisp_actor` authority. ## Language-neutral Actor Host API Define one versioned host surface covering at least: - actor spawn/message/stop/status - document query/get/save/remove - graph query/mutation - tools - MCP calls - HTTP/network access - artifacts/files where permitted - memory - targets - research/Auto-Dig lifecycle where permitted - Quasar UI/event integration where appropriate Both runtimes must map to the same semantic operations and typed errors. ## Common Lisp actors - supervised lifecycle - bounded mailbox/resource controls - capability checks at every privileged boundary - stable actor identity - async messaging semantics matching JS actors ## JavaScript actors - preserve convenience and browser/local JS actor support where policy permits - bring capabilities/error semantics/lifecycle to parity with Common Lisp - no special bypass because an actor runs in browser/Electron ## Spawn authority All actor spawns, including child/recursive spawns from either language, must cross the same authoritative host gate. This is required for per-user quotas and resource policy. ## Relationship to existing work Build on #2's Common Lisp control-plane migration and current principal/capability model rather than creating a parallel runtime authority. ## TDD acceptance Tests first should prove: - equivalent Lisp and JS actors can invoke the same allowed host operations - denied capability produces equivalent stable denial semantics in both runtimes - one language cannot obtain a capability unavailable to the other solely due to runtime implementation - child spawn crosses the same quota/auth gate - actor crash/timeout/mailbox limits are supervised consistently - audit records identify actor/principal/capability without depending on language-specific policy ## Non-goals - no requirement that implementation internals be identical - no unrestricted JS renderer access to Node/Electron - no automatic `init.lisp`/operator-level privilege for Common Lisp actors