diff --git a/AGENTS.md b/AGENTS.md
index d5eb785..377fd50 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -11,6 +11,7 @@
## Структура проекта (кратко)
- Серверный код SHiNE находится в папке `SHiNE-server/`.
- Код клиентского UI SHiNE находится в папке `shine-UI/`.
+- Веб-панель администратора сервера (управление Solana PDA сервера) — папка `shine-server-UI/`.
- Локальный Telegram-бот агента-кодера находится в папке `SHiNE-agent-bot-coder/` и не является кодом основного серверного приложения.
- Solana/Anchor-модуль находится в папке `shine-solana/shine/` и ведётся отдельно от основного server/UI деплоя.
diff --git a/CLAUDE.md b/CLAUDE.md
index 59206b9..1cf3fd3 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -7,3 +7,5 @@
## Справка по подпроектам
- При работе внутри `SHiNE-agent-bot-coder/` — читать `SHiNE-agent-bot-coder/AGENTS.md` и `SHiNE-agent-bot-coder/AGENT.md`.
- При работе внутри `shine-solana/shine/` — читать `shine-solana/shine/AGENTS.md`.
+- При работе внутри `shine-server-UI/` — читать `shine-server-UI/AGENTS.md`.
+- При работе внутри `SHiNE-server/` — читать `SHiNE-server/AGENTS.md`.
diff --git a/Dev_Docs/Blockchain/sync-between-servers.md b/Dev_Docs/Blockchain/sync-between-servers.md
new file mode 100644
index 0000000..427f954
--- /dev/null
+++ b/Dev_Docs/Blockchain/sync-between-servers.md
@@ -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 | Нужна реализация (заглушка) |
+
+Текущая версия сервера работает без межсерверной синхронизации.
+Синхронизация — задача следующего этапа разработки.
diff --git a/Dev_Docs/Future_Features/README.md b/Dev_Docs/Future_Features/README.md
index bbc5545..09da4a9 100644
--- a/Dev_Docs/Future_Features/README.md
+++ b/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 для файлов переписок и вложений.
+- `medium/2026-06-02_сессионные_саб_серверы_в_pda.md` - несколько саб-серверов пользователя как типизированные сессии в PDA с версией записи.
### Дальнее будущее
diff --git a/Dev_Docs/Future_Features/medium/2026-06-02_сессионные_саб_серверы_в_pda.md b/Dev_Docs/Future_Features/medium/2026-06-02_сессионные_саб_серверы_в_pda.md
new file mode 100644
index 0000000..0f480b0
--- /dev/null
+++ b/Dev_Docs/Future_Features/medium/2026-06-02_сессионные_саб_серверы_в_pda.md
@@ -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. затем уже проектировать операции регистрации, обновления и отключения таких сессий.
diff --git a/SHiNE-server/AGENTS.md b/SHiNE-server/AGENTS.md
new file mode 100644
index 0000000..793f54d
--- /dev/null
+++ b/SHiNE-server/AGENTS.md
@@ -0,0 +1,69 @@
+# AGENTS.md — SHiNE-server
+
+## Назначение
+
+SHiNE-server — серверная часть мессенджера SHiNE: WebSocket-сервер, хранение блоков блокчейна
+пользователей, доставка личных сообщений (DM), звонки.
+
+## Структура папок
+
+- `shine-server-net-server/` — точка входа, запуск HTTP/WS сервера
+- `shine-server-net-protocol/` — обработчики операций (RPC и события WS)
+- `shine-server-db/` — DAO, SQL-схема, SQLite
+- `shine-server-blockchain/` — логика хранения и проверки блоков блокчейна
+- `shine-server-crypto/` — криптографические утилиты
+- `shine-server-config/` — конфигурация сервера
+- `shine-server-log/` — логирование
+- `shine-server-geo/` — геолокация IP
+
+## Настройка сервера в Solana (Solana PDA)
+
+Серверный аккаунт SHiNE регистрируется в Solana в виде `user_pda` с флагом `is_server=true`.
+В PDA хранятся:
+
+- **адрес сервера** (URL WebSocket/HTTPS, например `https://shineup.me/ws`);
+- **список серверов синхронизации** (`sync_servers`) — логины SHiNE-аккаунтов серверов-партнёров,
+ с которыми синхронизируются блоки и DM;
+- **корневой ключ** сервера (`root_key`).
+
+Клиенты читают PDA напрямую из Solana, чтобы узнать адрес сервера и при необходимости подключиться.
+
+**Управление серверной PDA выполняется через Web-панель администратора:**
+
+```
+shine-server-UI/index.html
+```
+
+Страницы:
+- `create-server-pda.html` — первичная регистрация серверного аккаунта;
+- `update-server-pda.html` — обновление адреса или списка sync_servers.
+
+Для регистрации нужен полный keyBundle (root + device + blockchain).
+Для обновления — только root + device (blockchain-ключ не нужен).
+
+Актуальные адреса программ Solana (devnet):
+- `shine_users`: `FZS1YctoeEhCkZ5VTjsysUFAXR8CqxYztcLboXcg2Rpm`
+- `shine_payments`: `m48pWRGWrMj3TEHjuU4zsp5Gju4e7ZaPovk8RcVt7kR`
+
+Подробнее: `Dev_Docs/Инициализация_Solana_регистрации/README.md`
+
+## Синхронизация с партнёрскими серверами
+
+Сервер должен синхронизировать блоки блокчейна и DM с серверами-партнёрами из `sync_servers`.
+Детали: `Dev_Docs/Blockchain/sync-between-servers.md`
+
+## Деплой
+
+```
+./gradlew deployServer
+```
+
+Хост по умолчанию: `player@93.170.12.154` (shineup.me).
+
+Логи на проде:
+- `/home/player/SHiNE/shine-server/logs/app.log`
+- `/home/player/SHiNE/shine-server/logs/call-delivery-events.log`
+
+## Язык
+
+Комментарии в коде, документация и commit-сообщения — на русском языке.
diff --git a/VERSION.properties b/VERSION.properties
index a45515f..ab54975 100644
--- a/VERSION.properties
+++ b/VERSION.properties
@@ -1,2 +1,2 @@
-client.version=1.2.110
-server.version=1.2.102
+client.version=1.2.111
+server.version=1.2.103
diff --git a/shine-UI/js/services/solana-register-service.js b/shine-UI/js/services/solana-register-service.js
index 32f3de2..93913fd 100644
--- a/shine-UI/js/services/solana-register-service.js
+++ b/shine-UI/js/services/solana-register-service.js
@@ -175,9 +175,10 @@ function serializeCreateUserPdaArgs(
b.vecU8(new Uint8Array(32)); // last_block_hash
b.vecU8(lastBlockSig64); // last_block_signature
b.str(''); // arweave_tx_id
- b.bool(false); // is_server
- b.bytes32(new Uint8Array(32)); // server_key (default)
- b.str(''); // server_address
+ b.bool(false); // is_server
+ b.u8(0); // address_format_type
+ b.u8(0); // address_format_version
+ b.str(''); // server_address
b.vecStr([]); // sync_servers
b.vecStr(['shineup.me']); // access_servers
b.u8(0); // trusted_count
diff --git a/shine-server-UI/AGENTS.md b/shine-server-UI/AGENTS.md
new file mode 100644
index 0000000..0aa2c74
--- /dev/null
+++ b/shine-server-UI/AGENTS.md
@@ -0,0 +1,82 @@
+# AGENTS.md — shine-server-UI
+
+## Назначение
+
+`shine-server-UI/` — автономная веб-панель администратора для управления серверным аккаунтом SHiNE
+в Solana (регистрация и обновление `user_pda` с флагом `is_server=true`).
+
+Это не часть основного клиентского SPA (`shine-UI/`). Страницы — самостоятельные HTML-файлы,
+открываемые напрямую в браузере. Никакого бэкенда нет.
+
+## Структура файлов
+
+```
+shine-server-UI/
+ index.html — главная страница с навигацией
+ create-server-pda.html — регистрация нового серверного аккаунта
+ update-server-pda.html — обновление адреса/sync_servers существующей PDA
+ styles.css — тёмная тема
+ js/
+ server-pda-core.js — вся логика: парсинг PDA, Borsh, криптография, Solana
+```
+
+## Как пользоваться
+
+### Регистрация сервера (`create-server-pda.html`)
+
+Открыть страницу в браузере (требуется HTTPS для WebCrypto — локально либо через сервер).
+
+Ввести:
+- **Логин сервера** — уникальный логин в Solana (только a-z, 0-9, _ ; без точки ; макс. 20 символов).
+- **Адрес сервера** — полный WebSocket/HTTP URL, например `https://shineup.me/ws`.
+- **sync_servers** — логины SHiNE-аккаунтов серверов-партнёров (по одному на строку).
+
+**Способ ввода ключей (переключатель):**
+
+- **«Из пароля»** — ввести пароль. Ключи автоматически выводятся из логина + пароля
+ по той же схеме, что SHiNE-клиент (Argon2id + Ed25519). Занимает 2–5 сек.
+ На страницах сервера публичные и приватные ключи показываются в base58, приватный ключ
+ хранится как 32-байтовый seed в base58.
+- **«JSON ключей»** — вставить keyBundle JSON с тремя парами (rootPair, devicePair, blockchainPair).
+
+На **device-ключе** должно быть достаточно SOL для оплаты транзакции регистрации.
+
+### Обновление настроек сервера (`update-server-pda.html`)
+
+1. Ввести логин и нажать **«Загрузить PDA»** — страница прочитает существующую PDA из Solana и
+ покажет текущие данные.
+2. Изменить адрес сервера или список sync_servers.
+3. Выбрать способ ввода ключей:
+ - **«Из пароля»** — ввести пароль (логин берётся из поля выше);
+ - **«JSON ключей»** — вставить keyBundle (достаточно rootPair + devicePair).
+ Blockchain-ключ для обновления не нужен — существующая подпись из PDA переиспользуется.
+ При ручном вводе допустим base58 seed; если blockchain seed не указан, обновление
+ использует уже сохранённую подпись последнего блока.
+4. Нажать **«Обновить PDA»**.
+
+## Ключевой файл логики
+
+`js/server-pda-core.js` — автономный ES-модуль (без зависимостей на shine-UI).
+
+Экспортирует:
+- `readServerPdaData({ login, solanaEndpoint })` — читает и парсит PDA из Solana;
+- `registerServerOnSolana({ login, keyBundle, serverAddress, syncServers, ... })`;
+- `updateServerOnSolana({ login, keyBundle, serverAddress, syncServers, ... })`;
+- `parsePdaData(rawBytes)` — парсит бинарный формат PDA (matches Rust `deserialize_record_from_pda`).
+
+## Связанные документы
+
+- Формат PDA: `shine-solana/shine/doc/SHiNE-user-format-v.1.0.md`
+- Деплой Solana-программ: `Dev_Docs/Инициализация_Solana_регистрации/README.md`
+- Синхронизация между серверами: `Dev_Docs/Blockchain/sync-between-servers.md`
+- Настройки сервера: `SHiNE-server/AGENTS.md`
+
+## Правила при доработке
+
+- Формат Borsh-аргументов в `server-pda-core.js` должен строго соответствовать
+ `UserMutableFields` в `shine-solana/shine/programs/shine_users/src/users.rs`.
+- Бинарный формат PDA в `buildUnsignedRecordBytesServer` должен совпадать с
+ `serialize_unsigned_record` в Rust.
+- При любом изменении формата Solana-программы (`users.rs`) — обновлять `server-pda-core.js`
+ и документ формата PDA в том же коммите.
+- Язык кода и комментариев: русский.
diff --git a/shine-server-UI/create-server-pda.html b/shine-server-UI/create-server-pda.html
new file mode 100644
index 0000000..4a8a16a
--- /dev/null
+++ b/shine-server-UI/create-server-pda.html
@@ -0,0 +1,468 @@
+
+
+
+ Каждый SHiNE-сервер регистрирует свой аккаунт в Solana в виде user_pda
+ с флагом is_server=true.
+ В PDA хранятся:
+ • адрес сервера (например, https://shineup.me/ws);
+ • список серверов-партнёров для синхронизации блокчейна и DM;
+ • криптографический корневой ключ сервера.
+ Клиенты читают PDA прямо из Solana при попытке дозвониться до пользователя или
+ установить WebSocket-соединение через сервер.
+
+
+
+
+
Что потребуется
+
+ Для создания: полный keyBundle сервера (rootPair + devicePair + blockchainPair),
+ логин сервера (без точки, не более 20 символов), URL-адрес сервера, Solana-эндпоинт,
+ достаточный баланс SOL на device-ключе для комиссии.
+ Для обновления: только rootPair + devicePair (blockchain-ключ не нужен).
+