> Esta traducción se ofrece por comodidad. El texto normativo es el original en inglés.

# Mensajes MUFP - mecánica del protocolo y enlaces

**Especificación del Meta-Universo**

**ID del documento:** MU-V2-FED-011  
**Título:** Mensajes MUFP, máquina de estados y enlaces  
**Clase de documento:** normativo  
**Versión:** 2.0 (borrador)  
**Estado:** borrador de trabajo  
**Referencias normativas:** [MUFP](../03-federation/MUFP.md), [Federation-Lifecycle](../03-federation/Federation-Lifecycle.md), [Federation-Contracts](../03-federation/Federation-Contracts.md), [Trust-Model](../03-federation/Trust-Model.md), [MMAS-Interchange](../02-architecture/MMAS-Interchange.md), RFC 2119, RFC 8259  
**Referencias informativas:** [Identity-Binding](../03-federation/Identity-Binding.md), [Consent-and-Disclosure](../03-federation/Consent-and-Disclosure.md), [Synchronization](../03-federation/Synchronization.md)  
**Copyright:** © Orkestron.AI  
**Licencia:** Apache-2.0

---

# 1. Propósito

[MUFP](../03-federation/MUFP.md) define *por qué* y *en qué orden* se federan los universos soberanos. Este documento hace MUFP **implementable**: define los **mensajes** concretos, la **máquina de estados**, la **taxonomía de errores**, la **negociación de versiones**, la **revocación** y un **enlace HTTP/JSON** concreto.

Un desarrollador DEBERÍA poder implementar un punto de acceso MUFP mínimo e interoperable solo con este documento y el esquema de mensajes.

---

# 2. Alcance

Este documento especifica el protocolo tal como viaja por el cable para la secuencia canónica de federación. No redefine la *semántica* de la confianza, los contratos, la identidad o la divulgación: eso sigue en sus propios documentos; aquí se convierte en mensajes.

Todo mensaje es una instancia del **sobre MUFP** y valida contra [`schemas/mufp-envelope.schema.json`](../schemas/mufp-envelope.schema.json).

---

# 3. Panorama del protocolo

El protocolo materializa la secuencia canónica de federación de [MUFP §6](../03-federation/MUFP.md):

```text
Discovery → Capability Negotiation → Trust Establishment → Semantic Contract
  → Schema Discovery → Projection Exchange → Synchronization → Continuous Federation
```

El conocimiento (una proyección) se intercambia por primera vez solo en el **intercambio de proyecciones**, el sexto paso. Todo lo anterior negocia *significado, confianza, reglas y propósito*.

---

# 4. El sobre MUFP

Todo mensaje - petición, respuesta o error - es un único **sobre** JSON:

```json
{
  "mufp": { "version": "1.0" },
  "messageId": "urn:mu:msg:9f1c...",
  "inReplyTo": "urn:mu:msg:7a02...",
  "type": "Hello",
  "from": "urn:mu:universe:acme",
  "to": "urn:mu:universe:gov-tax",
  "federationId": "urn:mu:fed:acme-govtax-001",
  "sentAt": "2026-06-27T10:00:00Z",
  "body": { },
  "signature": { "alg": "ed25519", "value": "base64..." }
}
```

- `messageId` DEBERÁ ser único por emisor; los receptores DEBERÁN tratar de forma
  idempotente la reentrega de un mismo `messageId`.
- `inReplyTo` DEBERÁ estar presente en toda respuesta y DEBERÁ referenciar la petición.
- `federationId` DEBERÁ estar presente una vez que el establecimiento haya ocurrido.
- `signature` es OPCIONAL en esta versión y lo define el próximo modelo de seguridad;
  cuando está presente es una firma desprendida sobre la
  [forma canónica](../02-architecture/MMAS-Interchange.md) del sobre con el campo
  `signature` eliminado.

---

# 5. Máquina de estados

Una federación entre dos partes progresa por los siguientes estados. La tabla enumera, para cada estado, el mensaje que lo hace avanzar y el estado resultante.

| Estado | Disparador (petición / respuesta) | Estado siguiente |
|-------|------------------------------|-----------|
| `INIT` | `Hello` → `HelloAck` | `DISCOVERED` |
| `DISCOVERED` | `CapabilityOffer` → `CapabilityAccept` | `NEGOTIATED` |
| `NEGOTIATED` | `TrustRequest` → `TrustResponse` (aceptada) | `TRUSTED` |
| `TRUSTED` | `ContractProposal` → `ContractAccept` | `CONTRACTED` |
| `CONTRACTED` | `SchemaRequest` → `SchemaResponse` | `SCHEMA_SHARED` |
| `SCHEMA_SHARED` | `ProjectionRequest` → `ProjectionResponse` | `ACTIVE` |
| `ACTIVE` | `ProjectionRequest`, `SyncEvent`/`SyncAck`, `IdentityBindingProposal`/`Accept` | `ACTIVE` |
| `ACTIVE` | `Suspend` | `SUSPENDED` |
| `SUSPENDED` | `Resume` | `ACTIVE` |
| *(cualquiera)* | `Terminate` | `TERMINATED` |
| *(cualquiera)* | `Revoke` | retrocede al estado previo al elemento revocado, o a `TERMINATED` |
| *(cualquiera)* | `Error` | sin cambios, salvo que el error sea fatal (véase §7) |

Quien responde DEBERÁ rechazar todo mensaje que no sea legal en el estado actual con un `Error` de código `MUFP-E-STATE` (véase §7). El protocolo NO DEBERÁ saltarse etapas: por ejemplo, un `ProjectionRequest` recibido antes de `CONTRACTED` DEBERÁ ser rechazado.

---

# 6. Catálogo de mensajes

Cada `type` de mensaje lleva un `body`. Se enumeran los campos obligatorios del cuerpo; las formas completas están en los `$defs` del esquema del sobre.

| Etapa | Mensaje | Cuerpo (campos clave) |
|-------|---------|-------------------|
| Descubrimiento | `Hello` | `supportedVersions` (rangos MUC/MMAS/MUFP), `purpose` |
| | `HelloAck` | `supportedVersions`, `capabilities` |
| Capacidades | `CapabilityOffer` | `muc`, `mmas`, `mufp` (seleccionados), `federationProfile?`, `projectionProfiles?` |
| | `CapabilityAccept` | `agreed` (versiones y perfiles resueltos), `callbackUrl?` |
| Confianza | `TrustRequest` | `evidence[]` (evidencia de confianza), `requestedPurpose` |
| | `TrustResponse` | `decision` (`accept`/`deny`), `trustVector` (por dimensión), `reason?` |
| Contrato | `ContractProposal` | `contract` (un [contrato de federación](../03-federation/Federation-Contracts.md) en MUIF) |
| | `ContractAccept` | `contractId`, `contractFingerprint` |
| | `ContractReject` | `contractId`, `reason`, `counter?` |
| Esquema | `SchemaRequest` | `namespaces[]` / `csns[]`, `knownFingerprints?` |
| | `SchemaResponse` | `schemas[]` (MUIF), `fingerprints[]` |
| Proyección | `ProjectionRequest` | `subject` (identidad), `purpose`, `contractId`, `profile?` |
| | `ProjectionResponse` | `projection` (proyección MUIF), `contractId` |
| Sincronización | `SyncEvent` | `event` ([evento](../04-core-concepts/Event.md) MUIF), `streamId` |
| | `SyncAck` | `streamId`, `upTo` (id de evento) |
| Identidad | `IdentityBindingProposal` | `binding` (canónica ↔ local), `evidence?` |
| | `IdentityBindingAccept` | `bindingId` |
| Ciclo de vida | `Suspend` / `Resume` / `Terminate` | `reason?`, `effectiveAt?` |
| Revocación | `Revoke` | `target` (`trust`/`contract`/`identityBinding`), `targetId`, `reason` |
| Error | `Error` | `code`, `requirement?`, `message`, `retriable` |

Todas las cargas MUIF (`contract`, `schemas`, `projection`, `event`, `binding`) DEBERÁN ser válidas según [MMAS-Interchange](../02-architecture/MMAS-Interchange.md) y DEBERÁN llevar la huella semántica necesaria para su verificación.

---

# 7. Taxonomía de errores

Los errores son sobres `Error` de nivel de protocolo (la respuesta HTTP sigue siendo `200`; véase §10). Cada uno tiene un `code` estable:

| Código | Significado | Reintentable |
|------|---------|-----------|
| `MUFP-E-VERSION-UNSUPPORTED` | No hay versión común de MUC/MMAS/MUFP | no |
| `MUFP-E-CAPABILITY-MISMATCH` | El perfil o la capacidad exigidos no están disponibles | no |
| `MUFP-E-TRUST-DENIED` | No hay confianza establecida para el propósito solicitado | quizá |
| `MUFP-E-CONTRACT-REJECTED` | El contrato propuesto no es aceptable | quizá |
| `MUFP-E-SCHEMA-UNAVAILABLE` | El esquema o espacio de nombres solicitado no se expone | no |
| `MUFP-E-DISCLOSURE-DENIED` | Proyección rechazada (propósito, contrato, mínimo conocimiento) | no |
| `MUFP-E-FINGERPRINT-MISMATCH` | La huella de una carga no verifica | no |
| `MUFP-E-IDENTITY-UNRESOLVED` | La identidad del sujeto no está vinculada ni es conocida | quizá |
| `MUFP-E-REVOKED` | La confianza, el contrato o el vínculo han sido revocados | no |
| `MUFP-E-STATE` | Mensaje ilegal en el estado actual | no |
| `MUFP-E-RATE-LIMITED` | Demasiadas peticiones | sí |
| `MUFP-E-INTERNAL` | Fallo interno de quien responde | sí |

`MUFP-E-DISCLOSURE-DENIED` hace cumplir `MUC-R21`, `MUC-R22` y `MUC-R23`; `MUFP-E-FINGERPRINT-MISMATCH` hace cumplir `MUIF-R12`. Un `Error` PUEDE citar el `requirement` que hace cumplir (un ID del índice de requisitos).

---

# 8. Negociación de versiones

`Hello` lleva los rangos de versión que el iniciador admite para MUC, MMAS y MUFP. Quien responde DEBERÁ seleccionar, para cada uno, la versión más alta que también admita, y devolver el conjunto resuelto en `HelloAck`/`CapabilityAccept`. Si algún eje obligatorio no tiene versión común, quien responde DEBERÁ devolver `MUFP-E-VERSION-UNSUPPORTED` y la federación NO DEBERÁ continuar.

---

# 9. Acuerdo de identidad y revocación

Un [vínculo de identidad](../03-federation/Identity-Binding.md) se propone con `IdentityBindingProposal` y se confirma con `IdentityBindingAccept`, produciendo un acuerdo de identidad versionado y trazable. Cualquiera de las partes PUEDE enviar después `Revoke` con `target: "identityBinding"`. Tras la revocación, las referencias a la identidad vinculada DEBERÁN fallar con `MUFP-E-REVOKED` hasta que se establezca un nuevo vínculo. La confianza y los contratos se revocan del mismo modo (`target: "trust"` / `"contract"`), degradando la máquina de estados en consecuencia.

La revocación DEBERÁ registrarse como un [evento](../04-core-concepts/Event.md); la historia DEBERÁ conservarse (el vínculo no se borra, se termina).

---

# 10. Enlace HTTP/JSON

Este es un enlace concreto, REQUERIDO para interoperar. Otros enlaces (gRPC, mensajería) PUEDEN definirse más adelante.

- **Punto de acceso:** `POST {baseUrl}/mufp`
- **Content-Type:** `application/mufp+json`
- **Cuerpo de la petición:** exactamente un sobre.
- **Cuerpo de la respuesta:** exactamente un sobre. Un `Error` de *nivel de protocolo*
  se devuelve con HTTP `200` (el error es semántico, no de transporte).
- **Los códigos de estado HTTP** quedan reservados para fallos de transporte o de
  autenticación: `400` sobre mal formado, `401`/`403` autenticación de transporte,
  `429` límite de tasa de transporte, `5xx` fallo del servidor. Los desenlaces del
  protocolo viajan siempre en el sobre.
- **Sincronización:** si `CapabilityAccept` aportó un `callbackUrl`, el productor
  DEBERÁ entregar los sobres `SyncEvent` mediante `POST` a esa URL; en caso contrario
  el consumidor PUEDE sondear enviando su propia petición `SyncEvent` con `upTo` vacío.
  Cada `SyncEvent` DEBERÁ confirmarse con un `SyncAck`.
- **Idempotencia:** los receptores DEBERÁN eliminar duplicados por `messageId`.

---

# 11. Transcripción comentada (ilustrativa)

Un intercambio mínimo con éxito (cuerpos omitidos). La federación completa de extremo a extremo de dos meta-modelos reales está en [`examples/federation-handshake`](../examples/federation-handshake/).

```text
acme → gov-tax : Hello            (supportedVersions, purpose="tax-filing")
gov-tax → acme : HelloAck         (capabilities)
acme → gov-tax : CapabilityOffer  (muc=2.0, mmas=A4, mufp=1.0)
gov-tax → acme : CapabilityAccept (agreed, callbackUrl)
acme → gov-tax : TrustRequest     (evidence)
gov-tax → acme : TrustResponse    (accept, trustVector)
acme → gov-tax : ContractProposal (FederationContract MUIF)
gov-tax → acme : ContractAccept   (contractId, fingerprint)
acme → gov-tax : SchemaRequest    (namespaces=[person])
gov-tax → acme : SchemaResponse   (schemas, fingerprints)
acme → gov-tax : ProjectionRequest(subject=person:Person, purpose, contractId)
gov-tax → acme : ProjectionResponse(projection)        ← first data, step 6
acme → gov-tax : SyncAck          (streamId, upTo)
```

---

# 12. Conformidad - punto de acceso mínimo

Un **punto de acceso MUFP mínimo** (la base del nivel 1 de MUFP) DEBERÁ:

- aceptar y emitir sobres válidos por el enlace HTTP/JSON;
- implementar la máquina de estados de §5 y rechazar los mensajes fuera de estado con
  `MUFP-E-STATE`;
- realizar la negociación de versiones (§8);
- verificar la huella semántica de toda carga MUIF (`MUIF-R12`), fallando con
  `MUFP-E-FINGERPRINT-MISMATCH`;
- hacer cumplir que no se devuelva ninguna proyección sin un contrato aceptado y un
  propósito declarado (`MUC-R21`, `MUC-R25`), fallando con `MUFP-E-DISCLOSURE-DENIED`.

Los niveles superiores de MUFP añaden sincronización, vínculo de identidad, tratamiento de conflictos y sobres firmados.

---

# 13. Consideraciones de seguridad

Esta versión define la mecánica del protocolo; el modelo de amenazas completo y las protecciones exigidas (firma de sobres, defensa frente a repeticiones, propagación de revocaciones, prevención de fugas en la divulgación) los especifica el próximo **modelo de seguridad** (hoja de ruta WS5) y los acota [Trust-Model](../03-federation/Trust-Model.md). Hasta entonces, las implementaciones DEBERÍAN ejecutar el enlace sobre TLS autenticado y DEBERÍAN tratar los sobres sin firmar como no verificados.

---

# 14. Invariantes arquitectónicas

- El conocimiento (una proyección) NO DEBERÁ intercambiarse antes de `CONTRACTED` y de un
  propósito declarado.
- El protocolo NO DEBERÁ saltarse etapas de la secuencia canónica.
- Toda carga MUIF DEBERÁ verificarse por huella al recibirla.
- La revocación DEBERÁ ser posible en cualquier momento y DEBERÁ registrarse como historia.
- Los desenlaces del protocolo DEBERÁN viajar en el sobre, no en los códigos de estado del transporte.

---

# Direcciones futuras

- **Sobres firmados** y protección frente a repeticiones (junto con el modelo de seguridad).
- **Enlaces** adicionales (gRPC, colas de mensajes, libp2p).
- Un **banco de pruebas de conformidad** que recorra un punto de acceso a través de la
  máquina de estados (alimenta el Semantic Test Kit, hoja de ruta WS6).
- Un **registro de capacidades y perfiles**, para que las capacidades se descubran y no se codifiquen a mano.

---

# Declaración final

> Un protocolo es una promesa hecha precisa. Los mensajes MUFP convierten la
> "diplomacia semántica" en sobres, estados y errores, para que dos universos soberanos
> puedan estar construidos por equipos distintos, en lenguajes distintos, y aun así
> entenderse en el cable.