Обновить Telegram-бота, документацию и связанные доработки

2026-06-06 13:45:02 +04:00
parent ce5c348023
commit c5ec32f87a
16 changed files with 772 additions and 56 deletions
@@ -39,6 +39,10 @@
 - `medium/2026-06-03_подключение_других_устройств_через_qr.md` - довести подключение других устройств через QR: сейчас заготовка есть, но сценарий работает нестабильно и его нужно будет отдельно доделать.
 - `medium/2026-06-02_сессионные_саб_серверы_в_pda.md` - несколько саб-серверов пользователя как типизированные сессии в PDA с версией записи.

+### DAO-запуск
+
+- `dao_запуск/2026-06-05_esp32_hardware_wallet_device_session.md` - ESP32 как аппаратный кошелёк: постоянная device-сессия на сервере, подтверждение операций на экране, делегированные сессии для браузера/телефона.
+
 ### Дальнее будущее

 - Сейчас задач нет.
@@ -0,0 +1,64 @@
+# ESP32 как аппаратный кошелёк (device-сессия)
+
+## Суть фичи
+
+ESP32 становится аппаратным HSM (hardware security module): хранит ключи, постоянно подключён к SHiNE-серверу как device-сессия, подтверждает операции нажатием на экране. Другие устройства (браузер, телефон) взаимодействуют с ESP32 через сервер — без прямого соединения.
+
+## Два ключевых сценария
+
+### Сценарий 1 — Создание делегированной сессии
+1. Браузер/телефон → сервер: «хочу делегированную сессию от имени пользователя X»
+2. Сервер → ESP32 (device-сессия): «запрос на одобрение»
+3. Пользователь нажимает «Да» на сенсорном экране ESP32
+4. ESP32 → сервер: одобрено → сервер создаёт делегированную сессию для браузера
+
+### Сценарий 2 — Подпись транзакции / блока
+1. Браузер (через делегированную сессию) → сервер → ESP32: «подпиши вот это»
+2. ESP32 показывает запрос на экране, пользователь подтверждает
+3. ESP32 подписывает нужным ключом → ответ через сервер → браузер
+
+## Что нужно сделать
+
+### ESP32 (основная работа)
+- [ ] Инициализация WiFi (SSID/пароль в NVS)
+- [ ] WebSocket-клиент (`WebSocketsClient`) — постоянное соединение с сервером
+- [ ] Авторизация на сервере: `AuthChallenge` → `CreateAuthSession` через `deviceKey` (уже есть в NVS), сохранить `sessionId` в NVS
+- [ ] Обработчик входящих WebSocket-событий: JSON-парсинг, диспетчер по типу
+- [ ] Новые UI-экраны: «Разрешить сессию?» и «Подписать?» с кнопками Да/Нет
+- [ ] Расширенное хранилище ключей в NVS (произвольные именованные ключи сверх базовых трёх)
+- [ ] Переподключение при разрыве (reconnect loop)
+
+### Сервер (минимальные изменения)
+- [ ] Добавить поле `sessionType` (`USER` / `DEVICE`) в таблицу `active_sessions`
+- [ ] Новая операция `DeviceApprovalRequest` — браузер запрашивает одобрение у device-сессии
+- [ ] Новая операция `DeviceApprovalResponse` — ESP32 отвечает (одобрено/отклонено)
+- [ ] Новые операции `SignRequest` / `SignResponse` — запрос подписи и ответ
+- [ ] Роутинг: при получении запроса найти device-сессию через `ActiveConnectionsRegistry.getByLogin(login)` + фильтр по `sessionType=DEVICE`, переслать туда
+
+### Клиент (отдельный этап)
+- [ ] Браузерное расширение или UI: создание делегированной сессии, отправка `SignRequest`
+
+## Что уже готово (переиспользуем)
+
+- **Роутинг сообщений** — `SendDirectMessage` с `TARGET_ONE_SESSION` и `CallSignalToSession` уже умеют точечно доставлять в конкретный `sessionId`. Механизм готов, нужно добавить только новые op-коды поверх него.
+- **Ed25519 на ESP32** — библиотека `<Ed25519.h>` уже используется в скетче. Подписи работают.
+- **NVS** — уже хранит логин, мастер-секрет, 3 пары ключей. Расширяется легко.
+- **`ActiveConnectionsRegistry`** — поиск по `login` и `sessionId` уже есть на сервере.
+- **Аутентификация** — схема `AuthChallenge` → `CreateAuthSession` через Ed25519 уже полностью реализована.
+
+## Оценка сложности
+
+| Компонент | Сложность |
+|---|---|
+| ESP32: WiFi + WebSocket-клиент + авторизация | Средняя |
+| ESP32: обработчик входящих + UI подтверждений | Средняя |
+| Сервер: флаг sessionType + 4 новых op-а + роутинг | Низкая–средняя |
+| Браузерное расширение | Высокая (отдельный этап) |
+
+**Итого фазы ESP32 + сервер: ~1–1.5 недели.**
+
+## С чего начинать
+
+1. Серверная часть проще и быстрее — начать с добавления `sessionType` и `DeviceApprovalRequest/Response`.
+2. Затем ESP32: WiFi → WebSocket → авторизация → обработчик входящих → UI.
+3. Браузерное расширение — отдельная итерация после того как ESP32 + сервер работают.
@@ -0,0 +1,25 @@
+# ESP32 Argon2/UI совместимость и экран результата
+
+- краткое описание фичи:
+  выравнивание derivation на `ESP32` с текущим `UI` по нормализации логина, совместимости `master secret`/`root.key`/`bch.key`/`dev.key`, а также правки экрана результата и progress bar.
+
+- что именно проверять:
+  1. На `UI` и `ESP32` ввести один и тот же логин в разном регистре, например `Anya24`, и один и тот же непустой пароль.
+  2. Убедиться, что после нормализации логина на `ESP32` и `UI` получаются одинаковые:
+     `master secret`, `root`, `blockchain`, `device` в `Base58`.
+  3. Проверить режим пустого пароля:
+     `UI` и `ESP32` должны выдать одинаковые ключи в legacy-режиме.
+  4. Проверить, что пустой логин на `ESP32` не запускает расчёт и показывает сообщение об ошибке.
+  5. Проверить progress bar:
+     при непустом пароле полоса должна быть видна и двигаться.
+  6. Проверить экран результата:
+     сначала `Login`, затем `Password`, затем `Master secret` и ключи;
+     свайп вверх/вниз должен прокручивать длинный результат без артефактов.
+
+- ожидаемый результат:
+  `ESP32` и `UI` считают одинаковый `master secret` и одинаковые ключи для одинаковых входных данных;
+  progress bar виден;
+  экран результата читаемый и корректно прокручивается.
+
+- статус:
+  pending
@@ -0,0 +1,17 @@
+## Краткое описание
+В `SHiNE-agent-bot-coder` для личных чатов добавлен режим одного редактируемого статусного сообщения. Бот принимает запрос, обновляет это сообщение по этапам обработки и в конце превращает его в финальный текстовый ответ. При длинном ответе допускается ещё одно дополнительное текстовое сообщение с продолжением. Голосовой ответ остаётся отдельным сообщением.
+
+## Что проверять
+1. Отправить в личный чат короткий текстовый запрос и убедиться, что бот не шлёт цепочку промежуточных сообщений, а редактирует одно сообщение до финального ответа.
+2. Отправить в личный чат `voice` или `audio` и убедиться, что в том же сообщении последовательно видны этапы распознавания и выполнения.
+3. Проверить длинный ответ, который не помещается в один Telegram message: должно получиться не больше двух текстовых сообщений.
+4. Проверить, что `voice`-ответ приходит отдельным новым сообщением после текстового.
+5. Проверить, что в `@shine_writing` по-прежнему логируются только итоговые `вопрос -> ответ`, без промежуточных статусов.
+
+## Ожидаемый результат
+- В личке основная переписка стала чище: промежуточные этапы живут в одном редактируемом сообщении.
+- При длинном ответе бот не разбрасывает ответ на много сообщений.
+- Канал `@shine_writing` работает по старой схеме без лишнего шума.
+
+## Статус
+`pending`
@@ -0,0 +1,24 @@
+## Краткое описание
+В локальный Telegram-бот `SHiNE-agent-bot-coder` добавлена команда `/settings`, которая сразу показывает текущие персональные настройки пользователя и список доступных команд для их изменения. В `/help` оставлена только ссылка на `/settings` без перечисления самих команд настроек. Также добавлен переключатель режима ответа в личке: один редактируемый статус или отдельные сообщения по этапам.
+
+## Что проверять
+1. Отправить `/help` и убедиться, что в справке есть `/settings`, но нет списка команд `/voice_*` и `/single_message_*`.
+2. Отправить `/settings` и проверить, что бот показывает текущие значения:
+   - озвучивание финальных ответов;
+   - адаптацию текста перед озвучкой;
+   - режим одного редактируемого сообщения в личке.
+3. По очереди переключить:
+   - `/voice_on` и `/voice_off`;
+   - `/voice_rewrite_on` и `/voice_rewrite_off`;
+   - `/single_message_on` и `/single_message_off`.
+4. После каждого переключения снова вызвать `/settings` и убедиться, что статус изменился и сохранился.
+5. При `/single_message_on` отправить обычный запрос в личку и проверить, что бот ведёт его через одно редактируемое сообщение.
+6. При `/single_message_off` отправить обычный запрос в личку и проверить, что бот снова шлёт отдельные сообщения по этапам и отдельный финальный ответ.
+
+## Ожидаемый результат
+- `/settings` стал основной точкой входа для пользовательских настроек.
+- `/help` стал короче и не дублирует список команд настроек.
+- Режим ответа в личке реально переключается персонально для пользователя и сохраняется после перезапуска сервиса.
+
+## Статус
+`pending`