UI: обновлена шапка каналов, закрыты pending-задачи и обновлены версии

Dev_Docs/Future_Features/README.md

@@ -36,6 +36,7 @@
 
 - `medium/2026-05-24_1140_репосты_в_каналах_и_тредах.md` - репосты в каналах и тредах.
 - `medium/2026-05-25_1106_shine_balance_wallet.md` - кошелёк и пополнение баланса сияния через блокчейн.
+- `medium/2026-05-26_0029_esp32s3_file_storage.md` - ESP32S3 как личное файловое хранилище SHiNE для файлов переписок и вложений.
 
 ### Дальнее будущее
 

Dev_Docs/Future_Features/medium/2026-05-26_0029_esp32s3_file_storage.md

@@ -0,0 +1,44 @@
+# ESP32S3 как личное файловое хранилище SHiNE
+
+## Горизонт
+
+Среднесрочный: ближайшие недели или 1-2 месяца.
+
+## Зачем нужна фича
+
+Нужно проработать маленький физический сервер на ESP32S3 как персональное или доверенное файловое хранилище SHiNE.
+
+Идея: при обмене сообщениями пользователи смогут использовать такой сервер для хранения своих файлов, вложений, файлов общих переписок и связанных данных.
+
+## Что нужно сделать
+
+- Описать роль ESP32S3-сервера в общей архитектуре ключей и сессий.
+- Определить, какие ключи может хранить такое устройство.
+- Решить, хранит ли устройство только файлы или также подписывает пользовательские операции.
+- Описать протокол загрузки, скачивания и удаления файлов.
+- Определить правила шифрования файлов до отправки на устройство.
+- Продумать индексацию файлов для личных и общих переписок.
+- Решить, как устройство авторизуется на основном сервере SHiNE.
+
+## Вопросы перед реализацией
+
+- ESP32S3 должен работать как полностью локальное устройство или как публично доступный мини-сервер?
+- Нужен ли внешний relay, если устройство находится за NAT?
+- Какие ограничения по размеру файла считаем допустимыми?
+- Хранит ли устройство метаданные переписок или только зашифрованные blob-файлы?
+- Как восстанавливать доступ, если устройство потеряно или заменено?
+
+## Что уже сделано
+
+Код не реализован. Идея зафиксирована как будущая задача после описания модели ключей.
+
+## Документы, которые нужно обновить при возврате
+
+- `Dev_Docs/Keys/README.md`
+- `Dev_Docs/Personal_Messages/README.md`
+- `Dev_Docs/API/`
+- `Dev_Docs/Blockchain/`, если появятся новые блоки или команды для файлов.
+
+## С какого места продолжать
+
+Начать с короткого протокольного документа: роли устройства, авторизация, шифрование файлов, минимальные API-операции и сценарии восстановления.

Dev_Docs/Keys/README.md

@@ -0,0 +1,175 @@
+# Ключи SHiNE
+
+Этот документ описывает роли ключей в SHiNE и их связь с Solana, персональным блокчейном, личными сообщениями, сессиями и будущими аппаратными устройствами.
+
+Документ является архитектурной справкой. Он не меняет текущие форматы API, DM-блоков или блокчейна сам по себе.
+
+## Коротко
+
+В SHiNE у пользователя есть несколько уровней ключей:
+
+- `root key` - главный корневой ключ пользователя, он же основной Solana-ключ.
+- `blockchain key` - ключ записи в персональный SHiNE-блокчейн пользователя.
+- `device key` - общий ключ пользовательских устройств для повседневной работы, звонков, DM и мелких платежей.
+- `session key` - ключ конкретной сессии или конкретного устройства для авторизации на сервере.
+
+Главная идея: самые важные ключи можно держать на доверенном серверном или аппаратном устройстве, а обычные клиентские устройства получают только ключи, нужные для текущей работы.
+
+## `root key`
+
+`root key` - главный ключ пользователя.
+
+Назначение:
+
+- регистрация пользователя в Solana;
+- создание и обновление пользовательской PDA-записи;
+- вызов критически важных Solana-функций;
+- изменение главных настроек пользователя;
+- управление остальными ключами;
+- подтверждение операций, которые должны иметь максимальный уровень доверия.
+
+В текущей модели `root key` совпадает по смыслу с главным Solana-ключом пользователя.
+
+На `root key` могут храниться значимые средства, если пользователь сознательно выбирает такую модель. Для мелких текущих расходов предпочтительнее использовать `device key`.
+
+## `blockchain key`
+
+`blockchain key` - ключ записи в персональный SHiNE-блокчейн пользователя.
+
+Назначение:
+
+- подпись записей в персональном блокчейне пользователя;
+- подтверждение действий, которые должны попасть в SHiNE-блокчейн;
+- разделение полномочий между главным Solana-ключом и ключом ежедневной записи.
+
+У пользователя может быть несколько персональных блокчейнов или веток. При смене `blockchain key` фактически создаётся новая ветка записи:
+
+- `username-001` - первая ветка;
+- `username-002` - вторая ветка;
+- `username-003` - третья ветка.
+
+Рабочая логика по умолчанию должна использовать последнюю актуальную ветку. Старые ветки остаются читаемыми и показывают историю смены ключей.
+
+## `device key`
+
+`device key` - общий ключ, который знают доверенные устройства пользователя.
+
+Назначение:
+
+- повседневные входящие и исходящие личные сообщения;
+- звонки и связанные с ними сообщения;
+- self-messages, то есть внутренние сообщения пользователя самому себе;
+- мелкие Solana-расходы на текущие операции;
+- derivation Arweave-кошелька;
+- оплата или подготовка добавления данных в Arweave-кошелек по отдельному протоколу.
+
+Arweave-кошелёк должен выводиться из `device key` по протоколу:
+
+- `Dev_Docs/Протоколы/SHINE_ARWEAVE_DERIVATION_V1.md`
+
+Если пользователь теряет только `device key`, в худшем случае ломается повседневная переписка и доступ конкретных устройств к ежедневным операциям. `root key` и `blockchain key` при правильной архитектуре остаются отдельно защищёнными.
+
+## `session key`
+
+`session key` - уникальный ключ конкретной сессии или устройства.
+
+Возможные форматы:
+
+- `Ed25519` - предпочтительный современный вариант;
+- `RSA` - legacy-вариант, полезный для устройств, где системное защищённое хранилище хорошо поддерживает RSA-ключи и не позволяет извлекать приватный ключ.
+
+Назначение:
+
+- авторизация сессии на сервере;
+- привязка устройства к пользователю;
+- подтверждение запросов от конкретной сессии;
+- доступ к зашифрованному `device key` после успешной авторизации.
+
+Одна и та же сессия может быть пригодна для подключения к нескольким серверам пользователя, если архитектура конкретного пользователя это допускает.
+
+У сессии должны быть:
+
+- имя сессии;
+- тип сессии;
+- публичная часть ключа;
+- ссылка на пользователя;
+- информация о сервере или серверах, которым эта сессия доверена.
+
+Имя сессии может создаваться автоматически из названия устройства и короткого случайного идентификатора, например `Android-a1b2c3`, `Ubuntu-f47a90`. Пользователь может переименовать сессию.
+
+## Типы сессий
+
+Базовые типы:
+
+- обычная пользовательская сессия;
+- серверная сессия;
+- аппаратная или доверенная сессия с доступом к расширенным ключам.
+
+Обычное устройство обычно имеет:
+
+- собственный `session key`;
+- зашифрованный `device key`, который открывается после авторизации;
+- доступ к DM, звонкам и обычным пользовательским операциям.
+
+Доверенное серверное или аппаратное устройство может иметь:
+
+- `root key`;
+- `blockchain key`;
+- `device key`;
+- собственный `session key`.
+
+Такая сессия может подписывать операции повышенной важности по запросам пользователя.
+
+## Внутренние self-messages
+
+Self-message - это сообщение пользователя самому себе.
+
+Такие сообщения нужны, чтобы обычное устройство могло попросить доверенное устройство выполнить действие:
+
+- подписать запись `blockchain key` и передать её в SHiNE-блокчейн;
+- подписать изменение настройки через `root key`;
+- обновить ключи;
+- сохранить внутреннюю команду или настройку;
+- отправить сообщение другому пользователю с сохранением копии себе;
+- сохранить сообщение только себе.
+
+Важно: self-message не является публичной командой сервера. Это пользовательская внутренняя команда, которую сервер или доверенное устройство обрабатывает в рамках прав конкретного пользователя.
+
+## Шифрование входящих сообщений
+
+Входящее сообщение может быть зашифровано:
+
+- `device key`;
+- `session key`;
+- отдельным ключом конкретного чата;
+- другим ключом, который уже известен клиенту.
+
+В сообщении не должно быть лишнего раскрытия того, каким именно ключом оно зашифровано. Клиент пробует расшифровать сообщение доступными ключами по порядку. Если расшифровка не удалась, сообщение остаётся непонятным для этого устройства.
+
+## Копии сообщений
+
+Для отправки сообщений нужны несколько режимов:
+
+- сообщение другому пользователю с исходящей копией себе;
+- сообщение другому пользователю без локальной исходящей копии;
+- сообщение только себе.
+
+Это должно позволить строить обычные DM, внутренние команды, личные заметки и зашифрованные пользовательские чаты поверх одной общей модели сообщений.
+
+## Связанные документы
+
+- `Dev_Docs/Personal_Messages/README.md` - текущая документация личных сообщений.
+- `Dev_Docs/Blockchain/README.md` - точка входа по форматам SHiNE-блокчейна.
+- `Dev_Docs/Solana_Architecture/README.md` - архитектура Solana-программ, PDA-счетов, DAO и движения средств.
+- `Dev_Docs/Инициализация_Solana_регистрации/README.md` - деплой и первичная инициализация Solana-регистрации.
+- `Dev_Docs/Протоколы/SHINE_ARWEAVE_DERIVATION_V1.md` - derivation Arweave-кошелька из `device key`.
+
+## Что нужно уточнить перед реализацией
+
+- точный формат записи списка ключей в Solana PDA;
+- как именно обозначать активную ветку персонального блокчейна;
+- какие операции требуют `root key`, а какие достаточно подписывать `blockchain key`;
+- формат self-message-команд;
+- порядок перебора ключей при расшифровке входящих сообщений;
+- правила ротации `device key` и восстановления доступа после потери устройства;
+- какие типы серверных и аппаратных сессий нужны в первой реализации.