## Инвариант R6 — Модель доверия Доверие в Pheix строится на проверяемых внешних фактах, а не на правах доступа или административных привилегиях. **Fail-fast** поведение: нарушение проверки внешнего факта → ошибка. > Как осуществляется проверка, что за внешний факт? Можешь представить тривиальный пример? --- ## Что означает «доверие на внешних фактах» Если формулировать грубо: система верит не тому, _кто ты_, а тому, _что можно проверить независимо_. Это противопоставление: | Модель | Основание доверия | | ------------ | ------------------ | | Традиционная | Роль / админ / ACL | | R6 | Проверяемый факт | --- ## Что может быть «внешним фактом» Внешний факт — это не мнение системы о пользователе. Это сущность, которую можно проверить независимо от её внутреннего состояния. Примеры: * криптографическая подпись; * хэш документа; * timestamp с подписью; * запись в блокчейне; * commit с GPG-подписью; * webhook с проверяемым HMAC. --- ## Тривиальный пример ### Классическая модель Доверие строится на роли: ```perl if $user.role eq "admin" { publish($article) } ``` ### Модель R6 Предположим, что для публикации должны выполниться следующие условия: * статья подписана владельцем домена; * подпись валидна; * ключ привязан к статье; #### Процесс: 1. Пользователь отправляет статью + цифровую подпись. 2. Pheix проверяет: - подпись валидна? - подпись соответствует публичному ключу? - ключ зарегистрирован как допустимый для этого контента? Если да → **публикация возможна**. Если нет → **fail-fast**. --- ## Пример на минимальном уровне Допустим: ```bash POST /publish ``` В запросе: ```javascript { "content_id": "A1", "signature": "0x98af..." } ``` Система: ```perl if !verify_signature($content_hash, $signature, $public_key) { die "Invalid signature"; } ``` Вот это и есть: **нарушение проверки внешнего факта → ошибка**. --- ## Более простой пример (без криптографии) Допустим, публикация разрешена если: * commit подписан; * CI pipeline прошёл; * линтер не выдал ошибок. Здесь «внешний факт» — результат CI. Pheix не верит роли. Он верит проверяемому событию: ```perl if !ci_status($commit_id) eq "passed" { die "failure"; } ``` --- ## Где это особенно уместно для Pheix Pheix — dCMS с blockchain-направлением. R6 логично применять к: * публикации; * перемещению контента в архив; * изменению контента; * смене состояния жизненного цикла. Например: Переход `Draft → Published` выполняется только если: * есть проверяемая подпись автора; * есть зафиксированная версия; * есть хэш, записанный в immutable storage. --- ## Где нужно быть осторожным Инвариант R6 звучит радикально: > «а не на правах доступа или административных привилегиях» Это красиво, но полностью отказаться от ролей трудно. Чаще всего получается гибрид: * роли определяют, кто может инициировать действие; * внешний факт определяет можно ли завершить действие; Это более реалистичная формулировка. Возможно, стоит переформулировать мягче. Сейчас: > Доверие строится на проверяемых внешних фактах, а не на правах доступа. Более инженерно: > Критические переходы состояния в Pheix подтверждаются проверяемыми внешними фактами, а не только внутренними ролями доступа.