Перевести звонки на SendSignal с client key

2026-08-09 20:09:54 +04:00
parent 5c38f8f0d8
commit c511910b8f
11 changed files with 556 additions and 43 deletions
@@ -0,0 +1,89 @@
+# ESP32 и wallet-extension: перейти на единый `SendSignal` и обязательную подпись `client key`
+
+## Зачем
+
+Сейчас в проекте уже есть универсальный transport `SendSignal`, который умеет работать и в режим `all_sessions`, и в режим `single_session`.
+
+При этом в коде всё ещё живут старые call-like транспорты:
+
+- `CallInviteBroadcast`
+- `CallSignalToSession`
+
+Для web-call логики их можно постепенно убрать в пользу одного `SendSignal`.
+
+Отдельный хвост остался в ESP32 homeserver/wallet-сценариях:
+
+- в ESP32-скетче технический ответ wallet RPC всё ещё уходит через `CallSignalToSession`;
+- в ESP32 send-signal сценарии сейчас допускается режим только с `sessionSignatureB64`, без обязательной подписи `client key`;
+- такое поведение выбивается из общей модели безопасности и создаёт лишнюю специальную ветку.
+
+## Что уже есть в коде
+
+- универсальный серверный transport `SendSignal` уже существует и поддерживает:
+  - `single_session`;
+  - `all_sessions`.
+- web UI уже использует `SendSignal` в части межсессионных сценариев.
+- звонки пока ещё используют старые call-specific методы.
+- ESP32 homeserver main использует:
+  - `CallSignalToSession` для wallet RPC response;
+  - `SendSignal` для части технических ответов.
+- в ESP32 есть код генерации:
+  - `sessionSignatureB64`;
+  - `clientSignatureB64`;
+  но для некоторых send-signal вызовов `client key` сейчас не обязателен.
+
+## Что сделать
+
+1. Перевести ESP32 сценарии со старого `CallSignalToSession` на `SendSignal(single_session)`.
+2. Убрать из ESP32-special flow странное исключение, где можно жить без `client key`.
+3. Переделать wallet-extension / связанный ESP32-клиент так, чтобы он тоже хранил `client key` и подписывал им `SendSignal`, как обычные клиенты SHiNE.
+4. Сделать `SendSignal` контрактно обязательным по подписи `client key`, а не только `session key`.
+5. После этого зачистить legacy call-like транспорт там, где он больше не нужен.
+6. Отдельно проверить, не осталось ли старых обработчиков, завязанных на:
+   - `IncomingCallSignal`;
+   - `IncomingCallInvite`;
+   там, где должен работать общий `IncomingSignal`.
+
+## Отдельно про шифрование
+
+Нужно продумать будущее расширение: чтобы через `SendSignal` можно было передавать не только подписанные, но и зашифрованные payload.
+
+Предварительный вывод по текущей архитектуре:
+
+- для сервера это почти не должно требовать специальной логики;
+- сервер в `SendSignal` в основном:
+  - валидирует подписи;
+  - маршрутизирует событие в нужные сессии;
+  - пересылает `data` дальше.
+
+Если UI/ESP32 начнут передавать уже клиентски зашифрованный `data`, сервер должен это пережить без серьёзных изменений, пока:
+
+- формат `data` остаётся строковым/JSON-совместимым;
+- сервер продолжает считать `SHA-256` от фактической передаваемой строки;
+- подписи строятся по уже зашифрованному payload.
+
+То есть возможное E2E-шифрование `SendSignal` в будущем скорее относится к клиентским участникам протокола, а не к серверной маршрутизации.
+
+## Что важно учесть при миграции
+
+- не ломать текущие звонки и текущий wallet RPC сценарий одним большим рывком;
+- сначала перевести ESP32 и wallet-extension на единый `SendSignal`;
+- только потом убирать старые call-specific методы;
+- не оставлять “особый ESP32-режим” без `client key`;
+- проверить, что у расширения/ESP32 есть безопасное хранение `client key` и понятный сценарий восстановления/перепривязки.
+
+## Откуда продолжать
+
+- от `TODO/medium/2026-06-28_send_signal_перенос_старых_сигналов.md`;
+- от текущего ESP32 homeserver-скетча:
+  - `ESP32/esp32/ESP32-S3-Touch-AMOLED-2.16/main-device/shine_homeserver_main/shine_homeserver_main.ino`
+- от web UI auth/call transport логики:
+  - `shine-UI/js/services/auth-service.js`
+  - `shine-UI/js/services/call-service.js`
+
+## Какие документы потом обновить
+
+- `TODO/medium/2026-06-28_send_signal_перенос_старых_сигналов.md`;
+- `TODO/README.md`;
+- документацию по ESP32 homeserver/wallet flow, если появится отдельный утверждённый transport contract;
+- документацию по межсессионным сигналам, если будет зафиксирован единый список `signalType`.