| # Протокол синхронизации данных между доверенными ядрами HMP-агента | |
| ## 1. Общая идея | |
| Пользователь самостоятельно разворачивает несколько доверенных ядер HMP-агента на разных устройствах. Каждое ядро ведёт свою локальную БД знаний и может синхронизироваться с другими ядрами через лёгкий peer-to-peer протокол. Синхронизация осуществляется отдельной утилитой, запускаемой по расписанию или по запросу локального ядра. | |
| ## 2. Принципы | |
| - **Доверие**: Все ядра считаются доверенными, принадлежат одному пользователю. | |
| - **Изоляция**: Ядра разных пользователей не взаимодействуют напрямую — обмен знаниями происходит между независимыми агентами. | |
| - **Непрерывность**: Локальное ядро работает автономно, даже без связи с другими. | |
| - **Асинхронное разрешение конфликтов**: Конфликты не решаются моментально — вместо этого создаются задачи для агента, и все версии записей распространяются по всем ядрам. | |
| ## 3. Механизм синхронизации | |
| ### 3.1. Инициация | |
| Утилита синхронизации: | |
| 1. Устанавливает соединение с другими ядрами (по списку доверенных адресов). | |
| 2. Запрашивает: | |
| - список записей в БД (по хэшам, ID или timestamp), | |
| - список удалённых записей (soft-delete). | |
| ### 3.2. Сравнение и обнаружение различий | |
| Утилита сравнивает локальные и удалённые данные: | |
| #### 3.2.1. Типы различий | |
| - Запись **есть у соседа**, но **отсутствует локально** → добавить к себе (если не удалена). | |
| - Запись **есть локально**, но **отсутствует у соседа** → отправить (если не удалена). | |
| - Запись есть **в обоих ядрах**, но различается содержимое → **конфликт**: | |
| - Различие в полях. | |
| - Разное состояние удаления. | |
| - Разные версии (по содержанию и меткам времени). | |
| ### 3.3. Обработка конфликтов | |
| 1. Все обнаруженные версии конфликтной записи сохраняются в локальной БД. | |
| 2. Опрашиваются другие доступные узлы по поводу значений данной записи в их БД. | |
| 3. Создаётся задача агента вида `resolve_conflict(entry_id, versions, metadata, context)`. | |
| 4. Эта задача передаётся в очередь задач и может обрабатываться в фоновом режиме, с привлечением LLM или с участием пользователя. | |
| 5. Конфликтный набор записей и задача **рассылаются другим ядрам**, чтобы они: | |
| - тоже сохранили конфликтные версии, | |
| - не принимали преждевременное решение, | |
| - были готовы принять финальную `authoritative`-версию после обработки задачи агентом. | |
| ### 3.4. Применение решений | |
| Когда задача разрешена: | |
| - Финальная версия помечается как `authoritative`. | |
| - Эта версия синхронизируется со всеми доверенными ядрами. | |
| - Старые версии архивируются или удаляются. | |
| ## 4. Удаление записей | |
| - Удаление всегда начинается с soft-delete (пометка). | |
| - Через заданное время (TTL) может быть произведён hard-delete (физическое удаление). | |
| - Если при синхронизации найдено расхождение между soft-delete и существующей записью — создаётся конфликт и задача на разрешение. | |
| ## 5. Мини-протокол обмена | |
| Можно реализовать как API, CLI или TCP-протокол: | |
| ```http | |
| GET /entries/hash_list # список записей (ID + хэш или timestamp) | |
| GET /entry/<id> # получить полную запись | |
| POST /entry/<id> # отправить/обновить запись | |
| GET /deleted_list # список удалённых ID | |
| POST /conflict/<id> # отправка конфликтных версий и задачи | |
| ``` | |
| ## 6. Заключение | |
| Схема позволяет сохранить простоту «одиночного ядра», добавляя лишь синхронизирующую утилиту. Обработка конфликтов вынесена в агента, а не в протокол — это позволяет использовать когнитивные возможности ядра (в т.ч. LLM) для принятия решений, без перегрузки пользователя. | |