CartoQuantum Protocol

Definicion corta

CQ no reemplaza el storage. Le saca al storage el monopolio de la identidad. Un objeto puede vivir en una base de datos comun, pero su ID se recalcula desde bytes canonicos, por lo que cualquier cambio silencioso queda expuesto.

Usuario ideal

El primer usuario ideal es una persona o equipo que opera con agentes, normalizadores o integraciones y necesita saber de donde salio cada dato. No busca una blockchain: busca evidencia portable, auditable y facil de recomputar.

Nombre

Arquitecta de pipelines verificables

Dolor

No puede probar si un dato fue editado, normalizado o reinterpretado.

Deseo

Mover objetos entre agentes sin perder identidad ni causalidad.

Decision

Usa CQ cuando el backend no debe ser la unica fuente de confianza.

El problema que resuelve

En una aplicacion tradicional, el servidor dice que objeto es cual, cual es la version vigente y de donde vino. CQ cambia esa relacion: el servidor puede guardar y servir objetos, pero cualquiera puede recalcular su ID y revisar sus bordes de procedencia declarada.

RAW input A
  id(A) = cq:sha256:...

Semantic object B
  derived_from: [id(A)]
  id(B) = cq:sha256:...

Que garantiza y que no

El hash demuestra integridad, no veracidad. `derived_from` declara una relacion, pero no prueba por si solo que la transformacion fue autentica. Para eso entran firmas, identidad del agente, attestations, logs y politicas de confianza.

Content ID
  asks: is this exact content?
  solved by: canonical bytes + hash

Signature
  asks: who claims this?
  solved by: key + signature suite

Provenance
  asks: what does it claim to derive from?
  solved by: derived_from edges

Policy
  asks: do I accept that claim?
  solved by: trust rules

Objeto CQ minimo

La unidad basica es inmutable. Si cambia algo, se crea otro objeto y se declara `derived_from`.

{
  "cq": "2",
  "id": "cq:sha256:...",
  "kind": "message",
  "coords": {},
  "payload": {},
  "provenance": {
    "parents": [],
    "derived_from": [],
    "caused_by": []
  },
  "operations": [],
  "signatures": [],
  "lifecycle": {
    "issued_at": 1786320000,
    "not_before": null,
    "expires_at": null,
    "supersedes": [],
    "revokes": []
  }
}

Canonicalizacion

CQ-C14N/1 define los bytes exactos sobre los que se calcula la identidad. Acepta JSON restringido, usa enteros seguros, rechaza floats, `-0` y enteros enormes, no normaliza Unicode, ordena claves por valor escalar Unicode y preserva el orden de arrays que no sean sets.

Los sets declarados del protocolo, como `provenance.derived_from` y `operations[*].inputs`, se deduplican y ordenan antes del JSON canonico. Por eso Python, Rust, TypeScript o Go pueden llegar a los mismos bytes y al mismo hash.

Si algo sale mal

CQ no deberia terminar en "esta corrupto". Una falla produce un reporte idempotente con ruta: aceptar, aislar, readdress, reparar por derivacion, pedir padre, forkear desde el ultimo valido o rechazar solo para esa operacion.

validate(input)
  -> valid: accept
  -> id_mismatch: quarantine | readdress
  -> malformed: raw_ref + quarantine
  -> missing_parent: request_parent | fork_from_last_valid

same failure -> same cqop:sha256 idempotency key

Considera CartoQuantum si estas creando...

Si tu app transforma datos y despues necesita explicar de donde salieron, CartoQuantum va ahi.

Donde se implementa

• Ingestion: convertir input externo en CQ Object raw.
• Normalizacion: derivar objetos semanticos desde raws.
• Memoria del agente: guardar conclusiones con procedencia.
• Exports/imports: transportar objetos verificables.
• Auditoria: validar chains, detectar cambios y emitir reportes.
• Recovery: quarantine, readdress o fork desde ultimo valido.

CABAB

CABAB es consentimiento portable. A propone algo y lo firma; B acepta esa propuesta y la firma; A confirma que recibio la aceptacion y firma el cierre.

Dicho simple: no alcanza con que el server diga "estan de acuerdo". CABAB deja una cadena CQ donde ambas partes firmaron declaraciones compatibles sobre el mismo acuerdo. No es blockchain, wallet, token, storage ni verdad semantica por si solo.

A -> B
  cabab.intent/1
  A propone y firma

B -> A
  cabab.commitment/1
  B acepta y firma

A -> B
  cabab.consent_close/1
  A confirma el cierre y firma

CABAB settlement report
  kind: cabab.settlement_report/1
  derived_from: [intent, commitment, consent_close, policy]
  idempotency_key: cqop:sha256:...