CONTROLLED EXECUTION
Kotoba Cloud na di entrance for identity and deploy control to di place wey software wey AI write go run. Kotoba na di language. Kotobase na di graph state layer wey you fit trust.
Technical details, legal documents and some account steps still dey for English.
PASSKEY USERNAME
@kotoba-…
STABLE PRINCIPAL
—
ACTIVE CONTROLLER
—
Di services connect without become one giant trust domain. Each authority still dey separately governed.
Passkey dey verify Stable Principal. Di control plane dey publish di topology and authority floor wey CLI deploy dey use.
Na content-addressed graph database for AI state and knowledge, with explicit relationships and identifiable history.
kotobase.net ↗E dey place admitted workloads for CPU/GPU resources and e dey execute dem.
murakumo.cloud ↗E dey run continuing agent work across workspaces, goals, tools, and approvals.
itonami.cloud ↗One release CID dey fix di namespace head, definitions, raw Wasm, compile receipts, and reproducibility evidence inside one IPLD graph. Names and GitHub still remain discovery and provenance.
Put definitions, Wasm artifacts and compile receipts together under one release CID.
Store di same complete closure for no less than two independent storage origins.
Check every byte and routed peer IDs, then use di release CID and export take run am.
# install and run the live Ed25519 + ML-DSA-65 reference package
kotoba package add kotoba-lang/reference-math@0.1.0 --catalog-cid bafkreidcy5stqvnyfpmud6ozz5qz3supd3r3uzk7glmntuv36ezliaxstm
kotoba package run kotoba-lang/reference-math # 42
kotoba library inspect <name|CID|#hash> --store .kotoba/codebase --namespace demo
# dry-run by default
kotoba library publish --store .kotoba/codebase --namespace demo --hosted
# replicate one exact release closure
kotoba library publish --store .kotoba/codebase --namespace demo --hosted --dry-run false \
--pqc-seed-file <ml-dsa-seed> \
--provider east=https://east.example --provider-token-file <east-token> \
--provider west=https://west.example --provider-token-file <west-token>
# qualification and execution are release-CID addressed
kotoba library verify ipfs://<release-cid> --store .kotoba/codebase \
--provider east=https://east.example --provider west=https://west.example
kotoba library run ipfs://<release-cid> --entry answer --store .kotoba/codebase \
--provider east=https://east.example --provider west=https://west.example
# rotate or revoke the Principal-pinned ML-DSA key; both finish with Passkey
kotoba pq-key rotate --current-pqc-seed-file <current> \
--next-pqc-seed-file <next> --expected-epoch 1
kotoba pq-key revoke --current-pqc-seed-file <current> --expected-epoch 2Post-quantum signatures na mandatory, no be optional. Publication need both Passkey session and ML-DSA-65 signature wey pin to di Principal. External authenticators and distributed qualification still dey separately verified boundaries.
Open di library catalog and dependency graphDi CLI sign this graph locally and store am for Kotobase. Verify di CIDs and IPNS name before you publish.
Verify di action, epoch, current key, and next key. Rotation na signed by both ML-DSA keys and e go start only after Passkey confirmation.
Agents and humans dey write freely for readable, data-oriented code.
Kotoba dey check types, effects, capabilities, resources, and target support.
Di host and provider dey bind Passkey identity and resource-scoped grant.
Kotobase dey keep artifacts and receipts; Murakumo and Itonami dey perform di admitted work.
kotoba deploy --manifest app.edn --target murakumo:asher
# plan is dry-run by default; apply remains explicitStorage, compute and agent work still get their own separate authority boundaries. Receipt dey record each origin separately. Existing Passkeys no dey move automatically; di new RP need Principal link wey dem don verify.