diff --git a/Dev_Docs/Future_Features/README.md b/Dev_Docs/Future_Features/README.md index f841e89..68bccfd 100644 --- a/Dev_Docs/Future_Features/README.md +++ b/Dev_Docs/Future_Features/README.md @@ -45,4 +45,4 @@ ### Дальнее будущее -- Сейчас задач нет. +- `far/2026-06-20_1639_homeserver_technical_commands_and_file_transfer.md` - технические команды для homeserver через SHiNE/WebRTC DataChannel и обмен файлами по чанкам с адресацией по `SHA-256`. diff --git a/Dev_Docs/Future_Features/far/2026-06-20_1639_homeserver_technical_commands_and_file_transfer.md b/Dev_Docs/Future_Features/far/2026-06-20_1639_homeserver_technical_commands_and_file_transfer.md new file mode 100644 index 0000000..1fa0c5e --- /dev/null +++ b/Dev_Docs/Future_Features/far/2026-06-20_1639_homeserver_technical_commands_and_file_transfer.md @@ -0,0 +1,114 @@ +# 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-файлообмену. diff --git a/Dev_Docs/Future_Features/far/README.md b/Dev_Docs/Future_Features/far/README.md index 5dc5d98..fa0cb78 100644 --- a/Dev_Docs/Future_Features/far/README.md +++ b/Dev_Docs/Future_Features/far/README.md @@ -1,5 +1,7 @@ # Дальнее будущее -Сейчас в этом горизонте нет активных идей. - Сюда переносить задачи, у которых нет понятного срока возврата и которые не нужно учитывать в ближайшем или среднесрочном планировании. + +## Идеи + +- `2026-06-20_1639_homeserver_technical_commands_and_file_transfer.md` - технические команды для homeserver через сервер SHiNE или WebRTC DataChannel, а также файловый обмен чанками с хранением на SD-карте. diff --git a/VERSION.properties b/VERSION.properties index db5ff47..9eb540d 100644 --- a/VERSION.properties +++ b/VERSION.properties @@ -1,2 +1,2 @@ -client.version=1.2.222 -server.version=1.2.210 +client.version=1.2.223 +server.version=1.2.211