Сервер: дочистить legacy-слои и доки

2026-07-27 19:29:10 +04:00
parent 0db3c3af5a
commit 6ed91a105e
33 changed files with 127 additions and 165 deletions
@@ -2,13 +2,12 @@

 Этот файл описывает раздел API, связанный с проверкой наличия пользователя на сервере и dev/test операциями.

-Сейчас здесь три метода:
+Сейчас здесь два метода:

- `AddUser` — операция отключена (регистрация только через Solana);
 - `GetUser` — временная серверная проверка существования пользователя и чтение его базовых данных;
 - `SearchUsers` — dev/test поиск логинов по префиксу.

-Регистрация выполняется через Solana (`shine_users`). Сервер при входе может лениво импортировать пользователя из Solana PDA в локальную БД, если записи ещё нет.
+Регистрация выполняется только через Solana. Старый серверный `AddUser` оставлен лишь как legacy-ответ `410 / ADD_USER_DISABLED` для старых клиентов и больше не считается частью актуального flow.

 ## Статус документа

@@ -18,11 +17,11 @@

 ---

-## 1. Операция `AddUser`
+## Legacy-операция `AddUser`

 ### Назначение

-Операция отключена. Используется только как явный ответ клиентам старых версий.
+Операция удалена из текущего клиентского flow. Сервер сохраняет только совместимый ответ для клиентов старых версий.

 ### Запрос

@@ -62,7 +61,7 @@

 ---

-## 2. Операция `GetUser`
+## 1. Операция `GetUser`

 ### Назначение

@@ -153,7 +152,7 @@

 ---

-## 3. Операция `SearchUsers`
+## 2. Операция `SearchUsers`

 ### Назначение

@@ -195,7 +194,6 @@

 ## 4. Короткое резюме

- `AddUser` — отключен (`410 / ADD_USER_DISABLED`).
 - `GetUser` — проверка существования пользователя на сервере.
 - `SearchUsers` — временный поиск пользователей по префиксу.
 - Регистрация выполняется только через Solana.
@@ -138,7 +138,7 @@ AUTH_CREATE_SESSION:{login}:{sessionKey}:{storagePwd}:{timeMs}:{authNonce}

 Перед проверкой подписи сервер должен:

-1. взять актуальный `solana_users.client_key`;
+1. взять актуальный `solana_user_pda_current.client_key`;
 2. сравнить его с `payload.clientKey`;
 3. только потом проверять подпись.

@@ -19,7 +19,7 @@
 - `Ping` нужен для регулярной проверки, что соединение всё ещё живо;
 - `GetServerInfo` нужен до авторизации и до работы с данными, чтобы клиент понял, что сервер доступен, и показал пользователю краткую карточку этого узла.
 - `ListBlockchainHeads` нужен для сервер-сервер сверки: партнёр получает список heads по всем цепочкам, сравнивает его со своим состоянием и затем добирает недостающие блоки по диапазону.
- `GetSyncUserProfile` нужен для server-to-server режима, когда принимающий сервер хочет создать у себя локальные `solana_users + blockchain_state` без прямого обращения в Solana. Это используется как временный обход ограничений внешнего Solana RPC.
+- `GetSyncUserProfile` нужен для server-to-server режима, когда принимающий сервер хочет создать у себя локальную runtime-проекцию пользователя и `blockchain_state` без прямого обращения в Solana.
 - `SendSignal` нужен для доверенных межсессионных команд одного пользователя. Первое практическое применение — `remote AddBlock via homeserver session`, но формат задуман как общий transport на вырост.

 Ниже сначала описаны назначение методов, затем точные форматы запросов и ответов.
@@ -216,7 +216,7 @@
 - `clientKey`
 - `blockchainSizeLimitBytes`

-После этого принимающий сервер может локально создать записи в `solana_users` и `blockchain_state`, а затем уже докачивать блоки через `GetBlockchainBlock`.
+После этого принимающий сервер может локально создать runtime-проекцию пользователя и запись в `blockchain_state`, а затем уже докачивать блоки через `GetBlockchainBlock`.

 Этот запрос доступен без авторизации и предназначен именно для server-to-server sync.

@@ -12,7 +12,6 @@

 | Операция | Раздел документации | Кратко |
 | --- | --- | --- |
-| `AddUser` | `01_User_Registration_API.md` | отключено (`410 / ADD_USER_DISABLED`) |
 | `GetUser` | `01_User_Registration_API.md` | чтение/проверка пользователя + server-состояние его блокчейна |
 | `SearchUsers` | `01_User_Registration_API.md` | поиск логинов по префиксу |
 | `TestGetFreeAvatarQuota` | `14_Test_Free_Avatar_Upload_API.md` | временный тестовый просмотр остатка бесплатных загрузок аватара |
@@ -60,7 +60,7 @@

 - `ListBlockchainHeads` — список heads всех локальных цепочек партнёра;
 - `GetBlockchainBlock` — чтение одного конкретного блока партнёра;
- `GetSyncUserProfile` — минимальный профиль пользователя для локального создания `solana_users + blockchain_state` без обращения в Solana RPC.
+- `GetSyncUserProfile` — минимальный профиль пользователя для локального создания runtime-проекции пользователя и `blockchain_state` без обращения в Solana RPC.

 ### 4.3 Как сейчас работает periodic sync

@@ -73,7 +73,7 @@
   - локальное состояние;
 3. если локальная цепочка слабее, сервер по одному блоку вызывает `GetBlockchainBlock`;
 4. каждый скачанный блок локально применяется через существующий `AddBlock`;
-5. если у сервера ещё нет локальной записи пользователя/цепочки, перед этим подготавливается локальный `solana_users + blockchain_state`.
+5. если у сервера ещё нет локальной записи пользователя/цепочки, перед этим подготавливается локальная runtime-проекция пользователя и `blockchain_state`.
 6. если во время replay обнаруживается рассинхрон или на одинаковой высоте удалённая цепочка сильнее, запускается полный resync:
   - цепочка помечается in-memory как `resync in progress`;
   - создаётся marker-file в `data/`;
@@ -110,7 +110,7 @@ Full resync запускается только тогда, когда:
 Важно:

 - full resync не делает умный rollback по одному блоку;
- full resync не трогает DM-таблицы и `solana_users`;
+- full resync не трогает DM-таблицы и current users слой;
 - висячие cross-chain ссылки считаются допустимым поведением системы.

 ### 4.5 Как работает обычный `AddBlock` и его recovery
@@ -150,7 +150,7 @@ Full resync запускается только тогда, когда:

 - из `blockchainName` извлекался `login`;
 - сервер вызывал import пользователя из Solana PDA;
- по данным PDA локально создавались `solana_users + blockchain_state`.
+- по данным PDA локально создавались runtime-проекция пользователя и `blockchain_state`.

 На практике это упёрлось в ограничение внешнего Solana RPC: при чистом старте и массовой подтяжке чужих цепочек сервер мог получать `HTTP 429`.

@@ -159,7 +159,7 @@ Full resync запускается только тогда, когда:
 - настройка `sync.importUserProfileFromPartner.enabled=true`
 - в этом режиме сервер **не ходит в Solana RPC** для создания локальной цепочки во время sync;
 - вместо этого он запрашивает у сервера-партнёра `GetSyncUserProfile` и создаёт локальную запись по данным партнёра.
- если локальный `solana_users` уже существует, sync восстанавливает только `blockchain_state` и не трогает identity-слой.
+- если локальная runtime-проекция пользователя уже существует, sync восстанавливает только `blockchain_state` и не трогает user-layer.

 Это временная практическая заплатка, чтобы clean-start sync не зависел от rate limit внешнего Solana endpoint.

@@ -103,7 +103,7 @@

 Для DM-проверки сервер использует:

- локальную `solana_users` как кэш;
+- локальную runtime-проекцию пользователей как кэш;
 - Solana PDA как источник истины по `clientKey` и `access_servers`.

 Если нужного пользователя нет локально, сервер обязан попытаться lazy-import из Solana PDA:
@@ -9,8 +9,4 @@ shine.db.DatabaseInitializer — проверяет наличие `db_schema_ve


 shine.db.entities.* — POJO-модели строк таблиц (без логики, только поля/геттеры/сеттеры + иногда удобные методы вроде getClientKeyByte()).
-shine.db.dao.* — DAO по таблицам: ActiveSessionsDAO, CurrentUsersDAO, UserParamsDAO, IpGeoCacheDAO, BlockchainStateDAO, BlocksDAO; плюс “сервисные” DAO:
-
-UserCreateDAO — атомарная регистрация пользователя в транзакции (BEGIN IMMEDIATE + rollback/commit).
-// Временное runtime-решение, позволяющее регистрировать новых пользователей
-// атомарно и добавляющее запись в runtime-таблицы сервера.
+shine.db.dao.* — DAO по таблицам: ActiveSessionsDAO, CurrentUsersDAO, UserParamsDAO, IpGeoCacheDAO, BlockchainStateDAO, BlocksDAO, SignedMessagesDAO; плюс сервисные DAO под recovery/resync.
@@ -42,11 +42,11 @@ auth/ — авторизация и сессии

 blockchain/ — AddBlock

-tempToTest/ — AddUser (временный, потом уйдёт в блокчейн-логику)
+tempToTest/ — временные dev/test операции (`GetUser`, `SearchUsers`)

 ConnectionContext
 Состояние одного WebSocket-подключения (login, session, authStatus).

 ActiveConnectionsRegistry
 Глобальный реестр активных авторизованных соединений
-(нужно для закрытия других сессий).
+(нужно для закрытия других сессий).