kotoba and murakumo on one bench: how to use each

The bench, as a figure

kotoba grants authority, itonami hands over a job with a stable ID, murakumo's resident nodes place it, and kotobase keeps the result as a signed commit. Click the figure for the next job; it is a self-contained page with no external requests.

Open the interactive figure (dark) · Open the light variant

kotoba: the CLI

Install the native executable with Homebrew (Homebrew 6 will not load an untrusted tap, hence the trust step), then evaluate an expression. A shell installer that verifies the release checksum is also documented in the kotoba README.

brew tap kotoba-lang/kotoba && brew trust kotoba-lang/kotoba && brew install kotoba
kotoba -e '(+ 1 2)'

kotoba id new
# browser opens, approve with Passkey; a verified username and Stable Principal are saved locally

kotoba id new needs a browser Passkey ceremony on auth.kotoba.cloud. The CLI receives only the public projection (username, principalId, accountDid, activeDid) and never a Passkey private key, wallet seed or long-lived bearer token. Source: kotoba-lang/kotoba README.

murakumo: join as a node

murakumo turns an ordinary machine into an inference node behind an OpenAI-compatible /v1 API. You bring your own model server (Ollama, llama.cpp, vLLM, MLX); murakumo provides identity, enrollment, heartbeat and job placement. It needs Node.js 22+ and npm.

curl -fsSL https://murakumo.cloud/install.sh | sh
export PATH="$HOME/.local/bin:$PATH"
murakumo node init

curl -fsS http://127.0.0.1:11434/v1/models
murakumo node doctor --model YOUR_MODEL_ID --local-url http://127.0.0.1:11434/v1
murakumo node check  --name my-pc --model YOUR_MODEL_ID --local-url http://127.0.0.1:11434/v1
murakumo node join   --name my-pc --model YOUR_MODEL_ID --local-url http://127.0.0.1:11434/v1

init creates a private device key (mode 0600). doctor writes nothing to the network. check enrolls and sends one signed heartbeat with zero free slots and never claims jobs; HTTP 201 proves acceptance, not inference. join serves jobs in the foreground until Ctrl-C and installs no service. The installer does not download a model or change your shell profile. Use the exact model ID your server returns from /v1/models. Source: murakumo README.

kotobase: the datom database

The primary API is kotobase.core: open, transact!, datoms, q, query and pull. The official correctness path is a signed immutable CID commit DAG executed by Kotoba native and Wasm targets; it requires no mutable ref service. S3/R2 and IPFS are untrusted immutable block transports. A storage provider is constructed by its adapter repository and passed to open as :storage.

(require '[kotobase.core :as core])
(core/open {:storage provider})   ; provider from an adapter repo
(core/transact! db tx-data)       ; returns a new commit
(core/q db pattern)

The snippet shows the public function shapes from kotobase's source (src/kotobase/core.clj.cljk), not a copy-paste program: choosing and constructing the storage provider is the caller's step, and the tests under test/kotobase show working open calls. Reads need an explicit commit CID or canonical frontier. Production use requires the production profile described in the kotobase README.

chain: a parent-linked commit chain

kotoba-lang/chain is the small primitive underneath: a parent-linked, content-addressed commit chain with a real IPLD link as prev. State is opaque to it. Storage is injected as put! and get-fn.

(require '[chain.core :as cd])
(def store (atom {}))
(def put!   (fn [cid bytes] (swap! store assoc cid bytes)))
(def get-fn (fn [cid] (get @store cid)))
(def c0 (cd/commit! put! get-fn "prolly-root-a" nil))
(def c1 (cd/commit! put! get-fn "prolly-root-b" c0))
(cd/verify-chain get-fn c1)   ;=> true

verify-chain is false if a store lies about a CID's bytes or a commit skips a seq. Chain verifies structure, not signatures: whether a grant was validly issued is decided elsewhere. Source: kotoba-lang/chain README.

kotobase-anchor-fevm: transparency log, optional EVM anchor

Checkpoint anchoring is asynchronous and chain-neutral. The default is a signed append-only transparency log that needs no blockchain, gas token, RPC service or IPFS; receipts carry only salted opaque commitments, a hash chain and an Ed25519 signature. Public-chain notarization on any compatible EVM is optional, and no anchor is ever a query or availability dependency of the database.

npm ci
npm run test:runtime
npm run qualify:transparency

These are the repository's own test and qualification scripts (the README lists kbb -M:test, test:cljs and test:contract as well). See docs/CHECKPOINT_ANCHOR_RUNBOOK.md in kotoba-lang/kotobase-anchor-fevm.

AWAI DNA: proposed, simulated-network only

Status first: the specification is proposed (ADR 0002, network-awai-apex pull request 14, branch dna-private-network-spec), and the network is simulation only. Real transport over kekkai-node is not implemented, and the host validates at roughly 0.6 to 1 second per entry, which is not production speed.

The idea: the DNA CID is the network id, so different rules mean a different network. Each agent keeps a signed, append-only source chain, entries are accepted only through a deterministic validator written in Kotoba and compiled to Wasm (ADR 0003), invalid behavior is shown as warrants that the node proposes but never issues itself, and one DNA maps to one kekkai realm, with kekkai deciding admission and a human approving machines (ADR 0004).

It is a separate, invitation-only private layer. It is not a replacement for or a layer above the public kotobase commit DAG or kotoba-lang/chain, and it does not do settlement.

# from awai-dna/ on the dna-private-network-spec branch (needs kotoba, amu, bb, Node, Deno, python3, kbb)
scripts/gates.sh

The awai-dna README itself notes that its own run of these gates failed in the author's environment for a missing amu dependency, so treat "all gates pass" as unconfirmed here.

Base and x402: paying for the public murakumo route

The public route is api.murakumo.cloud. Per cloud-murakumo, x402 settles bounded USDC charges on Base. Agents discover priced endpoints at https://murakumo.cloud/.well-known/x402 and use the SDK served at https://murakumo.cloud/sdk/x402-agent.mjs, which takes a caller-owned signPayment callback so murakumo never receives a wallet key. Every paid call carries a stable Idempotency-Key; the SDK checks network, asset, recipient and per-call limits before signing, and if transport fails after signing it returns an operation URL under /x402/operations/{id} instead of paying again.

Settlement is independent of DNA. The paid route in the figure is an illustration of this public route.

What this page does not claim

It does not claim DNA is deployed, that the figure's paid route is a recorded payment, or that any command was re-run for this page. Chain ID 260425 is decommissioned. The counts in the figure caption (2,767 repositories under kotoba-lang, 309 commits in kotoba since September) are a snapshot from the figure's author.