Kotoba Cloud
Passkey verifica un Principal Estable. El plano de control publica la topología y el piso de autoridad usado por el despliegue CLI.
EJECUCIÓN CONTROLADA
Kotoba Cloud conecta con el entorno de ejecución del software generado por IA mediante identidad y control del despliegue. Kotoba es el lenguaje. Kotobase es la capa de estado de grafos fiable.
Los detalles técnicos, los documentos legales y algunos procesos de cuenta siguen en inglés.
NOMBRE DE USUARIO PASSKEY
@kotoba-…
PRINCIPAL ESTABLE
—
CONTROLADOR ACTIVO
—
Los servicios se conectan sin convertirse en un dominio de confianza gigante. Cada autoridad sigue gobernada por separado.
Passkey verifica un Principal Estable. El plano de control publica la topología y el piso de autoridad usado por el despliegue CLI.
Una base de datos de grafo direccionada por contenido para estado y conocimiento de IA, con relaciones explícitas e historial identificable.
kotobase.net ↗Coloca cargas de trabajo admitidas en recursos CPU/GPU y las ejecuta.
murakumo.cloud ↗Ejecuta trabajo continuo de agentes a través de espacios de trabajo, objetivos, herramientas y aprobaciones.
itonami.cloud ↗Un CID de lanzamiento fija la cabeza del espacio de nombres, definiciones, Wasm en bruto, recibos de compilación y evidencia de reproducibilidad en un grafo IPLD. Los nombres y GitHub permanecen para descubrimiento y procedencia.
Cerrar definiciones, artefactos Wasm y recibos de compilación bajo un CID de lanzamiento.
Almacenar el mismo cierre completo en no menos de dos orígenes de almacenamiento independientes.
Verificar cada byte e IDs de pares enrutados, luego ejecutar por CID de lanzamiento y exportar.
# 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 2
Las firmas post-cuánticas son obligatorias, no opcionales. La publicación requiere tanto una sesión Passkey como una firma ML-DSA-65 anclada al Principal. Autenticadores externos y calificación distribuida permanecen como límites verificados por separado.
Abrir el catálogo de bibliotecas y grafo de dependenciasEl CLI firmó este grafo localmente y lo almacenó en Kotobase. Verifique los CIDs y el nombre IPNS antes de publicar.
Verifique la acción, época, clave actual y clave siguiente. La rotación está firmada por ambas claves ML-DSA y entra en vigor solo después de la confirmación con Passkey.
Agentes y humanos escriben libremente en código legible y orientado a datos.
Kotoba verifica tipos, efectos, capacidades, recursos y soporte objetivo.
El host y el proveedor vinculan la identidad Passkey y una concesión con alcance de recurso.
Kotobase guarda artefactos y recibos; Murakumo e Itonami realizan el trabajo admitido.
kotoba deploy --manifest app.edn --target murakumo:asher
# plan is dry-run by default; apply remains explicit
El almacenamiento, el cómputo y el trabajo de agentes conservan límites de autoridad separados. Los recibos registran cada origen por separado. Las Passkeys existentes no migran automáticamente; el nuevo RP requiere un vínculo de Principal verificado.