Миграция PDA на client.key

Dev_Docs/Keys/README.md

@@ -8,9 +8,9 @@
 
 В SHiNE у пользователя есть несколько уровней ключей:
 
-- `root key` - главный (master) ключ пользователя: тот, кто им владеет, управляет пользовательской PDA в Solana и может заменить все остальные ключи. Это не пополняемый кошелёк (комиссии платит `device key`).
+- `root key` - главный (master) ключ пользователя: тот, кто им владеет, управляет пользовательской PDA в Solana и может заменить все остальные ключи. Это не пополняемый кошелёк (комиссии платит `client key`).
 - `blockchain key` - ключ записи в персональный SHiNE-блокчейн пользователя.
-- `device key` - общий ключ пользовательских устройств для повседневной работы, звонков, DM и мелких платежей.
+- `client key` - общий ключ пользовательских устройств для повседневной работы, звонков, DM и мелких платежей.
 - `session key` - ключ конкретной сессии или конкретного устройства для авторизации на сервере.
 
 Главная идея: самые важные ключи можно держать на доверенном серверном или аппаратном устройстве, а обычные клиентские устройства получают только ключи, нужные для текущей работы.
@@ -30,7 +30,7 @@
 
 `root key` — это **главный (master) ключ** в следующем смысле: зная `root key`, можно управлять пользовательской PDA-записью в Solana (`create_user_pda` / `update_user_pda`) и тем самым **заменить все остальные ключи** пользователя (device, blockchain, homeserver). Поэтому компрометация `root key` равносильна компрометации всей личности пользователя.
 
-Важно не путать авторитет и кошелёк: `root key` — это авторитет над PDA-записью, а **SOL-комиссии за create/update платит `device key`** (он же fee payer и адрес для пополнения). Подробнее о том, какой ключ за что отвечает на Solana, — в `Dev_Docs/Keys/DERIVATION.md`, §3.
+Важно не путать авторитет и кошелёк: `root key` — это авторитет над PDA-записью, а **SOL-комиссии за create/update платит `client key`** (он же fee payer и адрес для пополнения). Подробнее о том, какой ключ за что отвечает на Solana, — в `Dev_Docs/Keys/DERIVATION.md`, §3.
 
 ## `blockchain key`
 
@@ -50,9 +50,9 @@
 
 Рабочая логика по умолчанию должна использовать последнюю актуальную ветку. Старые ветки остаются читаемыми и показывают историю смены ключей.
 
-## `device key`
+## `client key`
 
-`device key` - общий ключ, который знают доверенные устройства пользователя.
+`client key` - общий ключ, который знают доверенные устройства пользователя.
 
 Назначение:
 
@@ -63,11 +63,11 @@
 - derivation Arweave-кошелька;
 - оплата или подготовка добавления данных в Arweave-кошелек по отдельному протоколу.
 
-Arweave-кошелёк должен выводиться из `device key` по протоколу:
+Arweave-кошелёк должен выводиться из `client key` по протоколу:
 
 - `Dev_Docs/Протоколы/SHINE_ARWEAVE_DERIVATION_V1.md`
 
-Если пользователь теряет только `device key`, в худшем случае ломается повседневная переписка и доступ конкретных устройств к ежедневным операциям. `root key` и `blockchain key` при правильной архитектуре остаются отдельно защищёнными.
+Если пользователь теряет только `client key`, в худшем случае ломается повседневная переписка и доступ конкретных устройств к ежедневным операциям. `root key` и `blockchain key` при правильной архитектуре остаются отдельно защищёнными.
 
 ## `session key`
 
@@ -83,7 +83,7 @@ Arweave-кошелёк должен выводиться из `device key` по
 - авторизация сессии на сервере;
 - привязка устройства к пользователю;
 - подтверждение запросов от конкретной сессии;
-- доступ к зашифрованному `device key` после успешной авторизации.
+- доступ к зашифрованному `client key` после успешной авторизации.
 
 Одна и та же сессия может быть пригодна для подключения к нескольким серверам пользователя, если архитектура конкретного пользователя это допускает.
 
@@ -108,14 +108,14 @@ Arweave-кошелёк должен выводиться из `device key` по
 Обычное устройство обычно имеет:
 
 - собственный `session key`;
-- зашифрованный `device key`, который открывается после авторизации;
+- зашифрованный `client key`, который открывается после авторизации;
 - доступ к DM, звонкам и обычным пользовательским операциям.
 
 Доверенное серверное или аппаратное устройство может иметь:
 
 - `root key`;
 - `blockchain key`;
-- `device key`;
+- `client key`;
 - собственный `session key`.
 
 Такая сессия может подписывать операции повышенной важности по запросам пользователя.
@@ -139,7 +139,7 @@ Self-message - это сообщение пользователя самому
 
 Входящее сообщение может быть зашифровано:
 
-- `device key`;
+- `client key`;
 - `session key`;
 - отдельным ключом конкретного чата;
 - другим ключом, который уже известен клиенту.
@@ -158,12 +158,12 @@ Self-message - это сообщение пользователя самому
 
 ## Связанные документы
 
-- `Dev_Docs/Keys/DERIVATION.md` - **источник истины по конкретной деривации** секрета и ключей (формулы Argon2id, `base64|suffix→SHA-256→Ed25519`, суффиксы `root.key`/`bch.key`/`dev.key`/`homeserver.key:<имя>`, Solana-ключ, ссылки на код).
+- `Dev_Docs/Keys/DERIVATION.md` - **источник истины по конкретной деривации** секрета и ключей (формулы Argon2id, `base64|suffix→SHA-256→Ed25519`, суффиксы `root.key`/`bch.key`/`client.key`/`homeserver.key:<имя>`, Solana-ключ, ссылки на код).
 - `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`.
+- `Dev_Docs/Протоколы/SHINE_ARWEAVE_DERIVATION_V1.md` - derivation Arweave-кошелька из `client key`.
 
 ## Что нужно уточнить перед реализацией
 
@@ -172,5 +172,5 @@ Self-message - это сообщение пользователя самому
 - какие операции требуют `root key`, а какие достаточно подписывать `blockchain key`;
 - формат self-message-команд;
 - порядок перебора ключей при расшифровке входящих сообщений;
-- правила ротации `device key` и восстановления доступа после потери устройства;
+- правила ротации `client key` и восстановления доступа после потери устройства;
 - какие типы серверных и аппаратных сессий нужны в первой реализации.