Обновлён server UI и приватные ключи переведены в base58

2026-06-02 15:52:22 +04:00
parent 67f882b9bc
commit a06b76b800
14 changed files with 2277 additions and 5 deletions
@@ -0,0 +1,100 @@
+# Синхронизация блоков и DM между серверами SHiNE
+
+Документ описывает архитектуру и протокол синхронизации данных между партнёрскими серверами SHiNE.
+
+## 1. Зачем нужна синхронизация
+
+Пользователи SHiNE могут быть «приписаны» к разным серверам.
+Когда пользователь A (на сервере X) пишет пользователю B (на сервере Y):
+
+1. Сервер X принимает сообщение;
+2. Сервер X должен переслать DM-блок серверу Y;
+3. Сервер Y сохраняет блок и доставляет в активные сессии пользователя B.
+
+Аналогично, блоки пользовательского блокчейна (записи `AddBlock`) должны синхронизироваться,
+чтобы любой партнёрский сервер мог отдать полную историю пользователя.
+
+## 2. Список серверов синхронизации (`sync_servers`)
+
+Каждый сервер регистрирует в своей Solana PDA список `sync_servers` —
+логины SHiNE-аккаунтов партнёрских серверов, с которыми он синхронизируется.
+
+- Список хранится в блоке `ServerProfileBlock` внутри `user_pda` сервера.
+- Адрес каждого партнёрского сервера читается из его PDA на Solana.
+- Синхронизация двусторонняя: оба сервера должны иметь друг друга в `sync_servers`.
+
+## 3. Что синхронизируется
+
+### 3.1 Личные сообщения (DM)
+
+- Все DM-блоки форматов типов `1/2` (текст) и `3/4` (read-receipt).
+- Сервер-отправитель: при получении пары блоков от клиента перенаправляет их серверу получателя.
+- Сервер-получатель: сохраняет блоки в `signed_messages_v2`, доставляет в активные сессии.
+- Дедупликация по уникальному `message_key = from|to|timeMs|nonce|type`.
+
+### 3.2 Блоки пользовательского блокчейна
+
+- Все блоки `AddBlock` пользователей, зарегистрированных на сервере или синхронизирующихся через него.
+- Синхронизируются в обе стороны между всеми партнёрами из `sync_servers`.
+- Порядок блоков сохраняется (по глобальному номеру блока и хэшу).
+- Дедупликация по глобальному номеру блока и хэшу.
+
+## 4. Протокол синхронизации (целевой, не реализован)
+
+### 4.1 Межсерверное соединение
+
+- Серверы устанавливают постоянное WebSocket-соединение друг с другом.
+- Адрес партнёра определяется по `server_address` из его Solana PDA.
+- Аутентификация: подпись Ed25519 корневым ключом сервера (`root_key` из PDA).
+- При разрыве — переподключение с экспоненциальным backoff.
+
+### 4.2 Доставка новых данных (push)
+
+- При получении нового блока или DM сервер немедленно пушит его всем подключённым партнёрам.
+- Партнёр подтверждает приём (ACK). Без ACK — повтор с backoff.
+
+### 4.3 Начальная синхронизация (backfill)
+
+- При первом подключении к партнёру серверы обмениваются «курсорами» состояния:
+  последний глобальный номер блока, последний известный DM-ключ.
+- Сервер с более полной историей досылает недостающее партнёру.
+
+### 4.4 Разрешение конфликтов
+
+- Блоки пользовательского блокчейна: порядок определяется глобальным номером блока.
+  Конфликтующие ветки (fork) разрешаются по правилам `AddBlock` (см. `Dev_Docs/Blockchain/README.md`).
+- DM: конфликтов нет, `message_key` уникален.
+
+## 5. Маршрутизация DM между серверами
+
+При отправке DM от пользователя A к пользователю B:
+
+1. Клиент A отправляет пару блоков на свой сервер X.
+2. Сервер X определяет, на каком сервере зарегистрирован пользователь B.
+   - Сначала проверяет локально (если B зарегистрирован на X).
+   - Иначе читает PDA пользователя B из Solana и смотрит `access_servers`.
+   - Выбирает первый доступный сервер из `access_servers` и перенаправляет туда DM.
+3. Сервер Y (из `access_servers` B) сохраняет и доставляет блоки.
+
+Кэш адресов серверов: обновляется раз в сессию (при ошибке соединения).
+
+## 6. Безопасность
+
+- Все блоки подписаны ключами пользователя на клиенте — сервер не может подделать содержимое.
+- Серверы не расшифровывают DM-контент (шифрование — задача следующего этапа).
+- При синхронизации каждый блок проходит валидацию подписи на принимающем сервере.
+
+## 7. Статус реализации
+
+| Компонент | Статус |
+|-----------|--------|
+| Регистрация серверной PDA в Solana | ✅ Реализовано |
+| Чтение `sync_servers` из PDA | Нужна реализация |
+| Межсерверный WebSocket-канал | Нужна реализация |
+| Push новых DM партнёрам | Нужна реализация |
+| Push блоков блокчейна партнёрам | Нужна реализация |
+| Backfill при первом подключении | Нужна реализация |
+| Маршрутизация DM через access_servers | Нужна реализация (заглушка) |
+
+Текущая версия сервера работает без межсерверной синхронизации.
+Синхронизация — задача следующего этапа разработки.
@@ -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 для файлов переписок и вложений.
+- `medium/2026-06-02_сессионные_саб_серверы_в_pda.md` - несколько саб-серверов пользователя как типизированные сессии в PDA с версией записи.

 ### Дальнее будущее

@@ -0,0 +1,103 @@
+# Сессионные саб-серверы в PDA пользователя
+
+- Статус:
+  `future`
+
+- Горизонт:
+  `medium`
+
+- Ориентир:
+  после завершения первого этапа по пользовательским сессиям
+
+- Основание:
+  Идея зафиксирована после обсуждения архитектуры пользовательских сессий и внутренних саб-серверов. Сейчас задача сознательно отложена: сначала нужно аккуратно ввести базовую модель сессий, а затем возвращаться к расширенной серверной роли.
+
+## Зачем нужна фича
+
+У одного пользователя может быть несколько доверенных внутренних саб-серверов, и каждый из них должен жить как отдельная пользовательская сессия, а не как отдельная особая сущность вне общей модели.
+
+Это нужно, чтобы:
+
+- хранить несколько саб-серверов у одного пользователя одновременно;
+- различать обычные клиентские сессии и серверные сессии по явному типу;
+- дать расширяемый формат записи с версией;
+- использовать единый подход для DM, звонков и внутренних команд между сессиями.
+
+## Целевая идея
+
+В пользовательском PDA должен появиться список записей сессий, где каждая запись содержит как минимум:
+
+- `sessionType` (`u8`);
+- `sessionVersion` (`u8`);
+- `sessionName`;
+- `sessionPubKey`.
+
+Предварительные значения:
+
+- тип `1` - обычная пользовательская сессия;
+- тип `10` - саб-сервер пользователя;
+- версия `1` - первая рабочая версия формата записи сессии.
+
+Важно: саб-серверов у одного пользователя может быть несколько.
+
+## Архитектурный принцип
+
+Внутренний протокол взаимодействия должен оставаться транспортным.
+
+То есть SHiNE-сервер не должен разбирать прикладной смысл внутренней нагрузки саб-сервера, а должен:
+
+- доставлять сообщения между сессиями;
+- доставлять сигналы звонков между сессиями;
+- хранить и маршрутизировать адресацию;
+- не принимать на себя бизнес-логику содержимого внутренних команд.
+
+## Что уже подтверждается текущим кодом
+
+- Личные сообщения уже доставляются по всем сессиям целевого пользователя с отдельным учётом доставки на каждую сессию.
+- Подтверждение доставки DM уже идёт отдельно по каждой сессии.
+- Вызов звонка уже рассылается по нескольким активным сессиям пользователя.
+- Сигналы звонка уже адресуются конкретной сессии, а stop-сигналы дублируются на остальные сессии того же пользователя.
+
+Иными словами, текущая серверная логика ближе к модели "сервер доставляет между сессиями", чем к модели "сервер понимает внутренний протокол саб-сервера".
+
+## Что нужно сделать при возврате к задаче
+
+1. Согласовать финальный бинарный формат записи сессии в PDA пользователя.
+2. Проверить, не меняет ли это уже опубликованный формат пользовательской PDA-записи.
+3. Если формат PDA меняется, заранее предупредить пользователя и получить отдельное подтверждение.
+4. Решить, где именно хранится массив сессий:
+   - в основной записи пользователя;
+   - в отдельной PDA-структуре расширения;
+   - или в смешанной схеме с базовой записью и внешними индексами.
+5. Зафиксировать ограничения:
+   - максимальное число сессий;
+   - максимальную длину `sessionName`;
+   - правила удаления и обновления записи;
+   - правила ротации `sessionPubKey`.
+6. Продумать, как UI и сервер будут отличать тип `1` и тип `10`.
+7. Определить, какие внутренние сообщения саб-сервера останутся полностью прозрачными для SHiNE-сервера, а какие потребуют только технической маршрутизации.
+8. Добавить API/операции чтения и обновления списка сессий, если для этого не хватит существующих механизмов.
+9. После реализации обязательно обновить документацию.
+
+## Что нужно обновить при реализации
+
+- `shine-solana/shine/doc/SHiNE-user-format-v.1.0.md`
+- `Dev_Docs/Solana_Architecture/README.md`
+- `Dev_Docs/Инициализация_Solana_регистрации/README.md`
+- `Dev_Docs/Keys/README.md`
+- `Dev_Docs/Personal_Messages/README.md`, если изменится адресация DM по типам сессий
+- `Dev_Docs/API/`, если появятся новые серверные операции или изменятся ответы
+
+## Что пока не делать
+
+- Не включать это автоматически в основной deploy сервера.
+- Не менять сейчас Solana PDA-формат без отдельного подтверждения.
+- Не добавлять временные поля в публичный API "на всякий случай".
+
+## С какого места продолжать
+
+Продолжать после завершения первой части:
+
+1. описать минимальный формат записи пользовательской сессии;
+2. отдельно решить, живут ли саб-серверы в том же списке, что и обычные сессии;
+3. затем уже проектировать операции регистрации, обновления и отключения таких сессий.