> 译文仅供阅读便利。具有规范效力的是英文原文。

# MUFP 消息 - 协议机理与绑定

**元宇宙规范**

**文档编号：** MU-V2-FED-011  
**标题：** MUFP 消息、状态机与绑定  
**文档类别：** 规范性  
**版本：** 2.0（草案）  
**状态：** 工作草案  
**规范性引用：** [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  
**说明性引用：** [Identity-Binding](../03-federation/Identity-Binding.md)、[Consent-and-Disclosure](../03-federation/Consent-and-Disclosure.md)、[Synchronization](../03-federation/Synchronization.md)  
**版权：** © Orkestron.AI  
**许可：** Apache-2.0

---

# 1. 目的

[MUFP](../03-federation/MUFP.md) 规定主权宇宙*为何*以及*按什么次序*结成联邦。本文档让 MUFP 变得**可实现**：它规定具体的**消息**、**状态机**、**错误分类**、**版本协商**、**撤销**，以及一种具体的 **HTTP/JSON 绑定**。

开发者应当能够仅凭本文档与消息模式，就实现出一个最小且可互操作的 MUFP 端点。

---

# 2. 适用范围

本文档规定正典联邦序列在线路上的协议形态。它并不重新定义信任、契约、身份或披露的*语义* - 那些仍留在各自的文档里；在这里，它们化为消息。

每一条消息都是一个 **MUFP 信封**的实例，并须通过 [`schemas/mufp-envelope.schema.json`](../schemas/mufp-envelope.schema.json) 的校验。

---

# 3. 协议概览

本协议实现 [MUFP §6](../03-federation/MUFP.md) 所述的正典联邦序列：

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

知识（一份投影）最早只在**投影交换**这一步才被交换 - 也就是第六步。在它之前的一切，谈的都是*含义、信任、规则与目的*。

---

# 4. MUFP 信封

每一条消息 - 无论请求、响应还是错误 - 都是一个 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` 必须在同一发送方内唯一；接收方必须以幂等的方式处理同一
  `messageId` 的重复投递。
- `inReplyTo` 必须出现在每一条响应中，并且必须引用对应的请求。
- `federationId` 在建立完成之后必须出现。
- `signature` 在本版本中是可选的，由即将发布的安全模型定义；出现时，它是对移除
  `signature` 字段之后信封的[正典形式](../02-architecture/MMAS-Interchange.md)
  所作的分离式签名。

---

# 5. 状态机

两方之间的联邦经由下列状态推进。表中列出每个状态下推动其前进的消息，以及由此得到的状态。

| 状态 | 触发（请求 / 响应） | 下一状态 |
|-------|------------------------------|-----------|
| `INIT` | `Hello` → `HelloAck` | `DISCOVERED` |
| `DISCOVERED` | `CapabilityOffer` → `CapabilityAccept` | `NEGOTIATED` |
| `NEGOTIATED` | `TrustRequest` → `TrustResponse`（接受） | `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` |
| *（任意）* | `Terminate` | `TERMINATED` |
| *（任意）* | `Revoke` | 降回被撤销元素出现之前的状态，或降为 `TERMINATED` |
| *（任意）* | `Error` | 保持不变，除非该错误是致命的（见 §7） |

应答方必须以代码 `MUFP-E-STATE` 的 `Error` 拒绝任何在当前状态下不合法的消息（见 §7）。协议不得跳过阶段：例如，在进入 `CONTRACTED` 之前收到的 `ProjectionRequest` 必须被拒绝。

---

# 6. 消息目录

每种消息 `type` 都带一个 `body`。此处列出必需的正文字段；完整形态见信封模式的 `$defs`。

| 阶段 | 消息 | 正文（关键字段） |
|-------|---------|-------------------|
| 发现 | `Hello` | `supportedVersions`（MUC/MMAS/MUFP 区间）、`purpose` |
| | `HelloAck` | `supportedVersions`、`capabilities` |
| 能力 | `CapabilityOffer` | `muc`、`mmas`、`mufp`（已选定）、`federationProfile?`、`projectionProfiles?` |
| | `CapabilityAccept` | `agreed`（敲定的版本与配置）、`callbackUrl?` |
| 信任 | `TrustRequest` | `evidence[]`（信任证据）、`requestedPurpose` |
| | `TrustResponse` | `decision`（`accept`/`deny`）、`trustVector`（逐维度）、`reason?` |
| 契约 | `ContractProposal` | `contract`（以 MUIF 表示的[联邦契约](../03-federation/Federation-Contracts.md)） |
| | `ContractAccept` | `contractId`、`contractFingerprint` |
| | `ContractReject` | `contractId`、`reason`、`counter?` |
| 模式 | `SchemaRequest` | `namespaces[]` / `csns[]`、`knownFingerprints?` |
| | `SchemaResponse` | `schemas[]`（MUIF）、`fingerprints[]` |
| 投影 | `ProjectionRequest` | `subject`（身份）、`purpose`、`contractId`、`profile?` |
| | `ProjectionResponse` | `projection`（MUIF 投影）、`contractId` |
| 同步 | `SyncEvent` | `event`（MUIF [事件](../04-core-concepts/Event.md)）、`streamId` |
| | `SyncAck` | `streamId`、`upTo`（事件 id） |
| 身份 | `IdentityBindingProposal` | `binding`（正典 ↔ 本地）、`evidence?` |
| | `IdentityBindingAccept` | `bindingId` |
| 生命周期 | `Suspend` / `Resume` / `Terminate` | `reason?`、`effectiveAt?` |
| 撤销 | `Revoke` | `target`（`trust`/`contract`/`identityBinding`）、`targetId`、`reason` |
| 错误 | `Error` | `code`、`requirement?`、`message`、`retriable` |

所有 MUIF 载荷（`contract`、`schemas`、`projection`、`event`、`binding`）都必须符合 [MMAS-Interchange](../02-architecture/MMAS-Interchange.md)，并且必须携带验证所需的语义指纹。

---

# 7. 错误分类

错误是协议层面的 `Error` 信封（HTTP 响应仍为 `200`；见 §10）。每一种都有稳定的 `code`：

| 代码 | 含义 | 可重试 |
|------|---------|-----------|
| `MUFP-E-VERSION-UNSUPPORTED` | 没有共同的 MUC/MMAS/MUFP 版本 | 否 |
| `MUFP-E-CAPABILITY-MISMATCH` | 所需的配置或能力不可得 | 否 |
| `MUFP-E-TRUST-DENIED` | 尚未为所请求的目的建立信任 | 或许 |
| `MUFP-E-CONTRACT-REJECTED` | 所提契约不可接受 | 或许 |
| `MUFP-E-SCHEMA-UNAVAILABLE` | 所请求的模式或命名空间未对外公开 | 否 |
| `MUFP-E-DISCLOSURE-DENIED` | 投影被拒（目的 / 契约 / 最小知识） | 否 |
| `MUFP-E-FINGERPRINT-MISMATCH` | 某载荷的指纹校验不过 | 否 |
| `MUFP-E-IDENTITY-UNRESOLVED` | 主体身份未绑定或未知 | 或许 |
| `MUFP-E-REVOKED` | 信任、契约或绑定已被撤销 | 否 |
| `MUFP-E-STATE` | 消息在当前状态下不合法 | 否 |
| `MUFP-E-RATE-LIMITED` | 请求过多 | 是 |
| `MUFP-E-INTERNAL` | 应答方内部故障 | 是 |

`MUFP-E-DISCLOSURE-DENIED` 落实 `MUC-R21`、`MUC-R22`、`MUC-R23`；`MUFP-E-FINGERPRINT-MISMATCH` 落实 `MUIF-R12`。`Error` 可以援引它所落实的 `requirement`（一个需求索引 ID）。

---

# 8. 版本协商

`Hello` 携带发起方对 MUC、MMAS 与 MUFP 所支持的版本区间。应答方必须为每一项选出自己同样支持的最高版本，并在 `HelloAck`/`CapabilityAccept` 中回送敲定的结果。若某个必需的轴上没有共同版本，应答方必须返回 `MUFP-E-VERSION-UNSUPPORTED`，并且这段联邦不得继续。

---

# 9. 身份协议与撤销

[身份绑定](../03-federation/Identity-Binding.md)以 `IdentityBindingProposal` 提出、以 `IdentityBindingAccept` 确认，由此产生一份带版本、可追溯的身份协议。任何一方日后都可以发送 `target: "identityBinding"` 的 `Revoke`。撤销之后，对该被绑定身份的引用必须以 `MUFP-E-REVOKED` 失败，直到建立新的绑定为止。信任与契约的撤销方式相同（`target: "trust"` / `"contract"`），并相应地把状态机降级。

撤销必须记为一条[事件](../04-core-concepts/Event.md)；历史必须保全（绑定不是被抹去，而是被终结）。

---

# 10. HTTP/JSON 绑定

这是一种具体的绑定，为达成互操作**必须**支持。其他绑定（gRPC、消息中间件）可以日后定义。

- **端点：** `POST {baseUrl}/mufp`
- **Content-Type：** `application/mufp+json`
- **请求体：** 恰好一个信封。
- **响应体：** 恰好一个信封。*协议层面*的 `Error` 以 HTTP `200` 返回
  （该错误属语义，而非传输）。
- **HTTP 状态码**留给传输与认证的失败：`400` 信封格式有误，`401`/`403` 传输层认证，
  `429` 传输层限流，`5xx` 服务器故障。协议层面的结果永远走信封。
- **同步：** 若 `CapabilityAccept` 给出了 `callbackUrl`，生产方必须以 `POST` 把
  `SyncEvent` 信封投递到该地址；否则消费方可以轮询 - 自行发出一条 `upTo` 为空的
  `SyncEvent` 请求。每一条 `SyncEvent` 都必须以 `SyncAck` 确认。
- **幂等性：** 接收方必须按 `messageId` 去重。

---

# 11. 逐条示例（示意）

一次最小的成功交换（正文从略）。两个真实元模型端到端的完整联邦，见 [`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. 合规 - 最小端点

**最小 MUFP 端点**（MUFP 一级的基础）必须：

- 能在 HTTP/JSON 绑定上接收并发出合法的信封；
- 实现 §5 的状态机，并以 `MUFP-E-STATE` 拒绝不合状态的消息；
- 执行版本协商（§8）；
- 校验每一份 MUIF 载荷的语义指纹（`MUIF-R12`），失败时报
  `MUFP-E-FINGERPRINT-MISMATCH`；
- 确保没有已接受的契约与已声明的目的就不返回任何投影（`MUC-R21`、`MUC-R25`），
  失败时报 `MUFP-E-DISCLOSURE-DENIED`。

更高的 MUFP 级别会加上同步、身份绑定、冲突处置与已签名的信封。

---

# 13. 安全考量

本版本规定的是协议机理；完整的威胁模型与必需的防护（信封签名、重放防御、撤销传播、披露泄漏的防止）由即将发布的**安全模型**（路线图 WS5）规定，并受 [Trust-Model](../03-federation/Trust-Model.md) 约束。在那之前，实现应当把该绑定跑在经过认证的 TLS 之上，并应当把未签名的信封视为未经验证。

---

# 14. 架构不变量

- 在进入 `CONTRACTED` 并具备已声明的目的之前，知识（投影）不得被交换。
- 协议不得跳过正典序列中的阶段。
- 每一份 MUIF 载荷都必须在收到时经指纹校验。
- 撤销必须随时可行，并且必须记入历史。
- 协议层面的结果必须走信封，而不是走传输层的状态码。

---

# 未来方向

- **已签名的信封**与重放防护（与安全模型一并推进）。
- 更多**绑定**（gRPC、消息队列、libp2p）。
- 一套**合规测试台架**，驱动端点走完整条状态机
  （供给 Semantic Test Kit，路线图 WS6）。
- **能力 / 配置注册表**，使能力可被发现，而不是写死在代码里。

---

# 结语

> 协议，是把承诺说到精确。MUFP 消息把"语义外交"化作信封、状态与错误 -
> 于是两个主权宇宙纵然由不同团队、以不同语言建成，在线路上依然彼此听得懂。