Docs: добавить идею homeserver команд и обмена файлами
This commit is contained in:
AidarKC
parent
86eaf2139d
commit
3b12e14e71
@ -45,4 +45,4 @@
|
|||||||
|
|
||||||
### Дальнее будущее
|
### Дальнее будущее
|
||||||
|
|
||||||
- Сейчас задач нет.
|
- `far/2026-06-20_1639_homeserver_technical_commands_and_file_transfer.md` - технические команды для homeserver через SHiNE/WebRTC DataChannel и обмен файлами по чанкам с адресацией по `SHA-256`.
|
||||||
|
|||||||
@ -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-файлообмену.
|
||||||
@ -1,5 +1,7 @@
|
|||||||
# Дальнее будущее
|
# Дальнее будущее
|
||||||
|
|
||||||
Сейчас в этом горизонте нет активных идей.
|
|
||||||
|
|
||||||
Сюда переносить задачи, у которых нет понятного срока возврата и которые не нужно учитывать в ближайшем или среднесрочном планировании.
|
Сюда переносить задачи, у которых нет понятного срока возврата и которые не нужно учитывать в ближайшем или среднесрочном планировании.
|
||||||
|
|
||||||
|
## Идеи
|
||||||
|
|
||||||
|
- `2026-06-20_1639_homeserver_technical_commands_and_file_transfer.md` - технические команды для homeserver через сервер SHiNE или WebRTC DataChannel, а также файловый обмен чанками с хранением на SD-карте.
|
||||||
|
|||||||
@ -1,2 +1,2 @@
|
|||||||
client.version=1.2.222
|
client.version=1.2.223
|
||||||
server.version=1.2.210
|
server.version=1.2.211
|
||||||
|
|||||||
Loading…
Reference in New Issue
Block a user