# Homeserver: технические команды и передача файлов через SHiNE/WebRTC

## Зачем нужна фича

Идея на дальнее будущее: дать возможность обращаться к homeserver не только как к участнику сети SHiNE, но и как к удалённой технической точке управления.

Цели:
- отправлять на homeserver технические команды в текстовом виде;
- получать текстовый ответ на команду;
- при наличии WebRTC DataChannel передавать части файлов в обе стороны;
- хранить полученные файлы на SD-карте homeserver;
- использовать единый механизм доставки как через сервер SHiNE, так и напрямую через DataChannel.

## Горизонт

`far` - идея без ближайшего срока реализации. Сейчас приоритет ниже, чем запуск и стабилизация основного проекта.

## Что именно имеется в виду

### 1. Единая модель технической команды

Техническая команда должна иметь единый смысл независимо от транспорта доставки:
- через любой доступный сервер SHiNE;
- через уже установленный WebRTC DataChannel.

Если конкретный транспорт недоступен, ответ по нему может не прийти. Это считается нормальным поведением протокола.

### 2. Команда как короткоживущий подписанный сигнал

У команды должны быть:
- `commandId`;
- временная метка;
- TTL около 10 секунд;
- криптографическая подпись.

Смысл такой:
- если команда быстро дошла, homeserver подтверждает принятие;
- если не дошла вовремя, команда считается протухшей;
- отправитель может безопасно послать повтор;
- при повторе homeserver отвечает либо `команда принята`, либо `уже выполнено ранее`.

Это даёт дедупликацию и безопасный resend без повторного выполнения действия.

### 3. Текстовые технические команды

Базовый сценарий похож на короткий удалённый shell-протокол, но на уровне строго ограниченных команд:
- отправил строку-команду;
- получил строку-ответ.

Команды не обязаны исполнять произвольный shell. Предпочтительная модель - белый список операций с контролируемым форматом аргументов и ответа.

### 4. Передача файлов только при наличии DataChannel

Если между устройствами есть WebRTC DataChannel, через него можно передавать технические сообщения для файлового обмена.

Предварительная модель:
- имя файла = `SHA-256` содержимого;
- можно запросить диапазон байт `from..to`;
- можно отправить диапазон байт `from..to`;
- homeserver хранит полученные данные на SD-карте;
- если DataChannel нет, на запрос файловой передачи возвращается ответ в духе `не могу передать, нет data channel`.

Фактически файл-обмен должен быть частным случаем общего протокола технических команд.

### 5. Установка data-соединения по явной команде

Нужна техническая команда уровня:
- `установить data-соединение`.

Ответ:
- либо `да`, после чего запускается обычная процедура `offer/answer/ICE`;
- либо `нет` и причина отказа.

### 6. Доставка на пользовательские сессии

Логика должна быть совместима с общей моделью SHiNE, где технические сигналы можно отправлять на конкретные активные сессии пользователя.

Идея:
- на любую активную сессию пользователя можно посылать техническую команду;
- контакт пользователя может инициировать такую техническую коммуникацию так же, как он уже инициирует звонок или другой служебный сигнал.

## Что нужно будет сделать при возврате к задаче

- Спроектировать отдельный формат технических команд и ack-ответов.
- Решить, будет ли это новый тип служебных сообщений в существующем протоколе блокчейн/сигналинга или отдельная ветка поверх уже имеющихся transport-операций.
- Отдельно продумать авторизацию: кто именно из контактов и какие команды имеет право слать.
- Ограничить набор допустимых команд, чтобы не превратить механизм в небезопасный удалённый shell.
- Спроектировать протокол чанков файлов: размер чанка, нумерация, повторная отправка, контроль целостности, дозагрузка, завершение файла.
- Продумать хранение на SD-карте: временные файлы, сборка чанков, проверка итогового `SHA-256`, очистка мусора.
- Продумать поведение при отсутствии DataChannel, таймаутах и дублирующихся командах.
- Проверить, как это лучше встраивать в текущие клиентские сессии, звонки и homeserver-логику.

## Вопросы для будущего уточнения

- Это должен быть строго служебный протокол или пользователь сможет вызывать его и вручную из UI.
- Нужен ли доступ только к заранее разрешённым каталогам/файлам.
- Нужна ли двусторонняя синхронизация файлов или достаточно ручных команд `запросить кусок` / `отправить кусок`.
- Нужно ли разрешать передачу файлов через сервер SHiNE как fallback, или файл-обмен должен идти только через DataChannel.
- Какой максимальный размер файлов и допустимый объём хранения на SD-карте.

## Что уже сделано

Пока только зафиксирована идея и базовая концепция. Реализация не начиналась.

## Какие документы нужно будет обновить при реализации

- `Dev_Docs/Blockchain/README.md` и связанные файлы, если изменятся типы служебных сообщений или форматы блокчейн-команд.
- `Dev_Docs/API/` если изменится публичный серверный API или появятся новые операции.
- `Dev_Docs/Personal_Messages/README.md` если часть маршрутизации или подтверждений будет встроена в существующую логику доставки/сессий.
- Документацию по homeserver/ESP32, если появится пользовательская или сервисная файловая логика на устройстве.

## С какого места продолжать позже

Возвращаться к задаче только после стабилизации запуска проекта и базовых текущих функций. Начинать с проектирования протокола команд и матрицы прав доступа, а уже потом переходить к DataChannel-файлообмену.
