Kotoba

1 · Identity by content

A definition is named by what it means, not by what it was called.

The identity is computed after desugar, type checking, effect inference and ability elaboration — and it seals the effect row, so a pure definition and one requiring network authority can never share a name. Unison's idea; not Unison's syntax and not a global codebase.

2 · Memory safety, as a consequence

The thesis is confinement. Memory safety falls out of it.

Admitted components cannot address runtime or native memory, and component memory operations are bounded or trap. That holds without a general ownership/borrow system: affine consumption is scoped to capability values alone, because what a program must not forge is authority, not pointers.

3 · Component-first execution

The unit that runs is a Wasm component, not a process.

Each component gets its own WIT world built from its declared effects. Undeclared imports are rejected and there is no ambient WASI. The tender links and instantiates, binding only what policy granted. Native AOT for ordinary applications is an explicit non-goal — the boundary is the point.

A module

(ns example.greet)

(defn greeting [name :string] :string
  (string-concat "hello, " name))

(defn main [] :string
  (greeting "kotoba"))

Types are inline. No macros, no interop, no eval — those forms are not "discouraged", they are absent from the admitted grammar.

A policy

;; effective scope =
;;   requested ∩ delegated ∩ local policy
{:policy/allow
 #{{:cap/kind     :host/http
    :cap/resource "https://api.example.com/"
    :cap/expires  "2026-12-31T00:00:00Z"}}
 :policy/forbid-wildcard true}

what denies

empty-intersectionexpired-grantmissing-grantunknown-kind

Scope may only attenuate, never widen, and the handler receives a concrete post-intersection capability. Production policy must forbid wildcard scope; every attempt is receipted whether or not it succeeds.

T1 · memory

Admitted components cannot address runtime/native memory and component memory operations are bounded or trap.

trusted computing base

bounded reader · frontend admission · artifact verifier · Wasm/native runtime

residual risk

• runtime-engine vulnerabilities remain in the TCB
• native loaders require a second OS isolation boundary

T2 · effect

Every transitive component effect is declared and admitted before emission, including effects used by Kotoba-written providers.

trusted computing base

effect inference · capability catalog · frontend call graph

residual risk

• kotoba and compiler grammar/effect parity must be continuously compared

T3 · confinement

An ungranted capability is absent or unbound and cannot reach a provider or native handler.

trusted computing base

policy intersection · compiler import emission · tender import binding · host guard

residual risk

• provider and native implementations must independently validate resource scope
• production effective grants must forbid wildcard scope

T4 · determinism

The same admitted source, target, policy and lock produce the same observable pure result and artifact bytes.

trusted computing base

canonical reader · deterministic lowering · pinned toolchain

residual risk

• host effects are deterministic only where their capability contract says so

T5 · resource bounds

Source, admission, execution, memory and output use explicit finite bounds.

trusted computing base

admission limits · fuel meter · runtime quota · supervisor timeout

residual risk

• platform supervisors do not yet have equal production isolation evidence

T6 · supply chain

Release admission binds artifact identity, trusted signer, validity and reproducible evidence.

trusted computing base

signature verifier · trusted signer configuration · clock · revocation set

residual risk

• key custody and external revocation distribution remain operational TCB

T7 · backend parity

A shared portable component has equal acceptance, result and effect trace across qualified backends.

trusted computing base

shared conformance manifest · backend adapters · comparison runner

residual risk

• compiler-only features are not portable and must be rejected by portable profiles

T8 · host resource scope

A component import reaches its provider or native handler only with a concrete post-intersection resource scope and emits a receipt.

trusted computing base

capability intersection · host guard · provider handler · receipt sink

residual risk

• provider-specific path, redirect, symlink and tenant checks require Q5 kits

What you write

bounded-pure-desugardefdefndestructuringhigher-order-functionsifletloop-recurmapnsprotocolsrecordssetvector

What you never write

host-objectnumeric-capability-idportable-effect-envelopeprovider-callbackwit-import-syntax

Numeric capability IDs and WIT import syntax are a wire ABI, not source vocabulary. Explicit capability values are for attenuation, delegation, resource scope, quota and deadline — not for ordinary calls.

WebAssembly components

• Component Model pinned at e6bb1e456e94
• WASI 0.3.0 baseline
• world construction: per-component
• undeclared imports: reject
• ambient WASI: false

Async functions, futures and streams are explicit bounded effects with cancellation, deadline and budgets — never ambient authority.

Two lowering targets

The same checked intermediate representation lowers to either restricted-esm, wasm-component — under the same rules: exact imports, deny-by-default admission.

Ordinary-application native AOT is an explicit non-goal: the execution boundary is the component.

Who does what

• tender — Runtime that verifies/instantiates already-emitted Wasm components, links declared imports and exports, and binds only granted capabilities. kototama owns this role.
• broker — Authority above the tender that decides which principal may receive which scoped grant. aiueos is the named OS/capability broker.
• native-primitive — Minimal trusted boundary from typed component imports to the Wasm engine, WASI, OS syscall, device or root secret store. It revalidates concrete resource scope and cannot be removed by changing an extension.

kotoba-lang/kotoba-lang

The language authority: profile, grammar, capability semantics, safety claims, conformance fixtures.

github.com/kotoba-lang/kotoba-lang

kotoba-lang/compiler

Frontend admission, effect inference, KIR, and the emit backends.

github.com/kotoba-lang/compiler

kotoba-lang/kotoba

Language and library substrate, host implementations, semantic-code identity, integration tests.

github.com/kotoba-lang/kotoba

kotoba-lang/kototama

The tender: admits emitted components, links imports and exports, binds granted capabilities, enforces limits.

github.com/kotoba-lang/kototama