Сделать DM body opaque для сервера и улучшить fallback UI

2026-07-10 18:12:17 +04:00
parent cc1f78106d
commit 076b43e542
10 changed files with 190 additions and 56 deletions
@@ -0,0 +1,17 @@
+# Итог звонка как DM от инициатора
+
+- краткое описание фичи:
+  Вместо локальных `call-tech` записей итог звонка теперь отправляется как обычное DM-сообщение только от стороны, которая инициировала звонок.
+
+- что именно проверять:
+  1. Успешный звонок: после завершения инициатор отправляет в чат DM вида `Звонок: 37с` или `Звонок: 2м 14с`.
+  2. Неуспешный звонок без ответа: инициатор отправляет `Звонил, но недозвонился: нет ответа`.
+  3. Неуспешный звонок, когда у адресата нет доставленных сессий: инициатор отправляет `Звонил, но недозвонился: абонент не в сети`.
+  4. Неуспешный звонок при проблеме соединения: инициатор отправляет `Звонил, но недозвонился: не удалось установить соединение`.
+  5. Старые локальные `call-tech` bubble про итог звонка больше не появляются ни у инициатора, ни у принимающей стороны.
+
+- ожидаемый результат:
+  Итог звонка виден обеим сторонам как обычное DM-сообщение от инициатора, а локальные служебные записи про итог звонка больше не используются.
+
+- статус:
+  pending
@@ -0,0 +1,23 @@
+## Краткое описание
+
+Сервер перестал валидировать внутреннюю crypto-структуру `body` у контентных DM `type=1/2`.
+UI теперь не отбрасывает такие сообщения: если сообщение не удалось расшифровать, вместо текста показывается заглушка `Неудалось расшифровать сообщение`.
+
+## Что проверять
+
+- Отправка и приём обычных DM между штатными клиентами продолжают работать как раньше.
+- Сообщение с незнакомым форматом `body` у `type=1/2` принимается сервером и доходит до клиента.
+- В UI такое сообщение отображается в чате одной из ожидаемых заглушек:
+  - `Формат сообщения не поддерживается`
+  - `Не удалось расшифровать сообщение`
+  - `Сообщение повреждено`
+- После выхода из аккаунта и повторного входа backlog с такими сообщениями тоже отображается с той же заглушкой.
+- ACK доставки по сессии для такого сообщения не зацикливается и сообщение не приходит бесконечно повторно.
+
+## Ожидаемый результат
+
+Сервер выступает транспортом для opaque DM-body, а клиент при неудачной расшифровке показывает безопасный fallback вместо полного пропуска сообщения с различением основных причин.
+
+## Статус
+
+pending
@@ -71,7 +71,28 @@
 - сервер не должен расшифровывать DM;
 - ciphertext у `type=1` и `type=2` обычно разный и не обязан совпадать побайтно.

-### 2.3. Источник истины по пользователю
+### 2.3. Что именно знает сервер о `body`
+
+Для контентных DM (`type=1/2`) сервер в v1 должен рассматривать `body` как opaque blob:
+
+- сервер проверяет внешний контейнер `SHiNE_DM`;
+- сервер проверяет подпись;
+- сервер проверяет служебные поля envelope;
+- сервер проверяет только то, что `bodyLen > 0` и не превышает допустимый лимит;
+- сервер не обязан разбирать внутренний crypto-контейнер `body`;
+- сервер не обязан знать конкретный алгоритм шифрования `body`.
+
+Это позволяет альтернативным клиентам использовать совместимый внешний DM-envelope при собственном формате зашифрованного payload внутри `body`.
+
+Официальный UI SHiNE при приёме такого сообщения:
+
+- пытается расшифровать знакомый формат `EncryptedBody_v1_0`;
+- показывает текст сообщения при успешной расшифровке;
+- если внутренний формат не поддерживается, показывает `Формат сообщения не поддерживается`;
+- если формат понятен, но расшифровка не удалась, показывает `Не удалось расшифровать сообщение`;
+- если `body` повреждён или структурно битый, показывает `Сообщение повреждено`.
+
+### 2.4. Источник истины по пользователю

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

@@ -534,6 +555,7 @@ UI-следствие для клиента:

 - сервер не должен требовать одинаковый `encryptedBody` у `type=1` и `type=2`;
 - сервер не должен трактовать `encryptedBody` как обычный UTF-8 текст;
+- сервер не должен валидировать внутреннюю crypto-структуру `body` у контентных DM `type=1/2`;
 - DM должны реально шифроваться end-to-end;
 - удаление одного сообщения должно стать терминальным tombstone;
 - удаление всей переписки должно стать отдельным служебным событием;
@@ -164,6 +164,12 @@ Nonce/IV для `AES-GCM`.

 Сервер не должен трактовать это поле как UTF-8 текст и не должен пытаться расшифровывать его в обычной DM-логике.

+Важно:
+
+- официальный UI SHiNE сейчас использует именно `EncryptedBody_v1_0`;
+- сервер для контентных DM `type=1/2` не должен требовать, чтобы `body` обязательно был распознан как `EncryptedBody_v1_0`;
+- сервер должен хранить и пересылать `body` как opaque bytes, если внешний контейнер `SHiNE_DM` валиден.
+
 ### Точная схема для `cryptoMethod = 1`, `cryptoVersion = 0`

 - публичный ключ получателя для E2EE получается как стандартное преобразование `Ed25519 -> X25519`;