Реализовать SHiNE_DM v1 с E2EE и tombstone

Dev_Docs/Personal_Messages/README.md

@@ -0,0 +1,17 @@
+# Личные сообщения SHiNE
+
+Эта папка содержит актуальную документацию по личным сообщениям SHiNE.
+
+Точка входа:
+
+- `Dev_Docs/Personal_Messages/Протокол_DM_v1.md` — логика протокола, роли API, серверное поведение, routing по `access_servers`
+- `Dev_Docs/Personal_Messages/Формат_DM_v1.md` — точный бинарный формат контейнера `SHiNE_DM`
+
+Исторический устаревший документ сохранён отдельно:
+
+- `Dev_Docs/Personal_Messages/Спецификация_DM_v0.5_устаревшая.md`
+
+Правило сопровождения:
+
+- код DM и оба документа `Протокол_DM_v1.md` + `Формат_DM_v1.md` всегда должны обновляться синхронно;
+- если меняется поведение DM в коде, в том же наборе изменений обновляется и эта документация.

Dev_Docs/Personal_Messages/Протокол_DM_v1.md

@@ -2,13 +2,13 @@
 
 ## Статус документа
 
-Этот файл — актуальная логическая спецификация DM-протокола SHiNE следующего этапа.
+Этот файл — актуальная логическая спецификация DM-протокола SHiNE v1.
 
 Важно:
 
-- это целевая спецификация;
-- в текущем коде она ещё реализована не полностью;
-- при реализации код должен приводиться именно к этой спецификации, а не наоборот.
+- это актуальная реализованная спецификация;
+- код и документы по DM должны изменяться синхронно;
+- при любых будущих изменениях DM сначала обновляется эта спецификация и соседний документ формата.
 
 Документ фиксирует:
 
@@ -151,7 +151,6 @@
 
 - новые входящие сообщения;
 - входящие обновления/редактирования;
-- входящие служебные события удаления;
 - будущие входящие перешифрованные копии.
 
 ## 5. Удаление одного сообщения
@@ -286,7 +285,7 @@
 Их роли в v1:
 
 - `SendMessagePair` — новая пара сообщений и редактирование старой пары автором;
-- `ReceiveIncomingMessage` — приём одной входящей копии, входящих редактирований и служебных DM-событий;
+- `ReceiveIncomingMessage` — приём одной входящей копии, входящих редактирований и входящего read-receipt;
 - `ReceiveOutcomingMessage` — алиас `SendMessagePair`.
 
 ### 8.2. Новые методы, которые нужны
@@ -399,7 +398,6 @@ Request:
 
 - приём одной входящей копии по схеме server-to-server;
 - приём входящего редактирования;
-- приём служебного входящего события удаления;
 - приём входящего read-receipt.
 
 Request:

Dev_Docs/Personal_Messages/Формат_DM_v1.md

@@ -6,9 +6,9 @@
 
 Важно:
 
-- это целевой формат следующего этапа;
-- в текущем коде он ещё реализован не полностью;
-- особенно это касается перехода всех типов `1..8` на единый контейнер `SHiNE_DM`.
+- это актуальный формат, реализованный в текущем коде;
+- контейнер `SHiNE_DM` используется для всех типов `1..8`;
+- при любых будущих изменениях DM этот документ обновляется одновременно с кодом.
 
 Логика протокола, API и поведение сервера описаны отдельно:
 
@@ -156,6 +156,19 @@ Nonce/IV для `AES-GCM`.
 
 Сервер не должен трактовать это поле как UTF-8 текст и не должен пытаться расшифровывать его в обычной DM-логике.
 
+### Точная схема для `cryptoMethod = 1`, `cryptoVersion = 0`
+
+- публичный ключ получателя для E2EE получается как стандартное преобразование `Ed25519 -> X25519`;
+- отправитель генерирует ephemeral `X25519` приватный ключ и кладёт соответствующий `ephemeralPubKey` в контейнер;
+- общий секрет вычисляется как `X25519(ephemeralPrivKey, recipientX25519PubKey)`;
+- `HKDF-SHA256` использует:
+  - `salt = ephemeralPubKey || recipientX25519PubKey`
+  - `info = "SHiNE_DM|1|0|X25519+HKDF-SHA256+AES-256-GCM"` в ASCII
+  - `outputLen = 32`
+- полученные `32` байта используются как ключ `AES-256-GCM`;
+- поле `cipherText` хранит стандартный результат библиотеки `AES-GCM` в виде:
+  - `ciphertext || tag`
+
 ## 6. Поле `body` для типов `3/4`
 
 Для read-receipt типов `3/4` поле `body` содержит открытый контейнер ссылки на исходное сообщение:
@@ -291,8 +304,6 @@ ReadReceiptBody_v1_0
 - ciphertext может различаться;
 - `reencryptedAtMs` при одной парной ревизии тоже должен совпадать.
 
-## 13. Примечание о текущем коде
+## 13. Примечание о поддержке
 
-В текущем коде типы `3/4` пока ещё реализованы старым контейнером `SHiNE_dm2`.
-
-Для версии протокола v1 целевой формат фиксируется уже как единый `SHiNE_DM` для всех типов `1..8`.
+В версии DM v1 все типы `1..8` используют единый контейнер `SHiNE_DM`.