> Перевод даётся для удобства чтения. Нормативным является английский оригинал.

# Сообщения 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` в этой версии НЕОБЯЗАТЕЛЕН и определяется готовящейся моделью
  безопасности; при наличии это отделённая подпись над
  [канонической формой](../02-architecture/MMAS-Interchange.md) конверта с удалённым
  полем `signature`.

---

# 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` (см. §7). Протокол НЕ ДОЛЖЕН пропускать стадии: например, `ProjectionRequest`, полученный до состояния `CONTRACTED`, ОБЯЗАН быть отклонён.

---

# 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` ([контракт федерации](../03-federation/Federation-Contracts.md) в MUIF) |
| | `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` ([событие](../04-core-concepts/Event.md) MUIF), `streamId` |
| | `SyncAck` | `streamId`, `upTo` (идентификатор события) |
| Идентичность | `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`. Ошибка МОЖЕТ ссылаться на требование `requirement`, которое она обеспечивает (идентификатор из указателя требований).

---

# 8. Согласование версий

`Hello` несёт поддерживаемые инициатором диапазоны версий MUC, MMAS и MUFP. Отвечающая сторона ОБЯЗАНА выбрать для каждой из них наивысшую версию, которую поддерживает и она, и вернуть разрешённый набор в `HelloAck`/`CapabilityAccept`. Если по какой-либо обязательной оси общей версии нет, отвечающая сторона ОБЯЗАНА вернуть `MUFP-E-VERSION-UNSUPPORTED`, и федерация НЕ ДОЛЖНА продолжаться.

---

# 9. Соглашение об идентичности и отзыв

[Привязка идентичностей](../03-federation/Identity-Binding.md) предлагается сообщением `IdentityBindingProposal` и подтверждается сообщением `IdentityBindingAccept`, порождая версионированное прослеживаемое соглашение об идентичности. Любая из сторон МОЖЕТ позже послать `Revoke` с `target: "identityBinding"`. После отзыва обращения к привязанной идентичности ОБЯЗАНЫ завершаться ошибкой `MUFP-E-REVOKED`, пока не будет установлена новая привязка. Доверие и контракты отзываются тем же способом (`target: "trust"` / `"contract"`), с соответствующим понижением автомата состояний.

Отзыв ОБЯЗАН записываться как [событие](../04-core-concepts/Event.md); история ОБЯЗАНА сохраняться (привязка не стирается, она завершается).

---

# 10. Привязка HTTP/JSON

Это одна конкретная привязка, ТРЕБУЕМАЯ для совместимости. Другие привязки (gRPC, обмен сообщениями) МОГУТ быть определены позже.

- **Конечная точка:** `POST {baseUrl}/mufp`
- **Content-Type:** `application/mufp+json`
- **Тело запроса:** ровно один конверт.
- **Тело ответа:** ровно один конверт. Ошибка *уровня протокола* возвращается
  с HTTP `200` (ошибка семантическая, а не транспортная).
- **Коды состояния HTTP** отведены под сбои транспорта и аутентификации: `400`
  испорченный конверт, `401`/`403` аутентификация транспорта, `429` ограничение
  частоты на транспорте, `5xx` сбой сервера. Исходы протокола всегда едут в конверте.
- **Синхронизация:** если `CapabilityAccept` дал `callbackUrl`, производитель
  ОБЯЗАН доставлять конверты `SyncEvent` методом `POST` на этот адрес; иначе
  потребитель МОЖЕТ опрашивать, посылая собственный запрос `SyncEvent` с пустым
  `upTo`. Каждый `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 уровня 1) ОБЯЗАНА:

- принимать и отправлять действительные конверты по привязке 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 превращают
> "семантическую дипломатию" в конверты, состояния и ошибки, - чтобы две суверенные
> вселенные, построенные разными командами и на разных языках, всё же понимали
> друг друга на проводе.