SHA256
Первая версия вложенных файлов работает
This commit is contained in:
AidarKC
@@ -9,6 +9,7 @@
|
||||
- `docs/Personal_Messages/Доставка_и_синхронизация_DM.md` — доставка на
|
||||
единственный access-сервер, retry-воркер и UI-статусы
|
||||
- `docs/Personal_Messages/Технические_вставки_DM_v1.md` — формат специальных `<S:...>` вставок внутри plaintext DM после расшифровки
|
||||
- `docs/API/18_DM_File_Storage_API.md` — HTTP-хранилище зашифрованных файлов DM на access-сервере отправителя
|
||||
|
||||
Исторический устаревший документ сохранён отдельно:
|
||||
|
||||
@@ -19,3 +20,15 @@
|
||||
- код DM и оба документа `Протокол_DM_v1.md` + `Формат_DM_v1.md` всегда должны обновляться синхронно;
|
||||
- если меняется поведение DM в коде, в том же наборе изменений обновляется и эта документация.
|
||||
- локальная таблица пользователей для DM считается кэшем, а источником истины остаётся Solana PDA; если серверная логика DM меняет правила lazy-import пользователей из PDA, это тоже обязательно фиксируется в документации.
|
||||
|
||||
## Зашифрованные файлы DM
|
||||
|
||||
Официальный UI v1 умеет отправлять файл как внешний зашифрованный объект:
|
||||
|
||||
- файл шифруется в браузере `AES-256-GCM`;
|
||||
- ciphertext хранится только на access-сервере отправителя под именем `Base58(SHA-256(ciphertext))`;
|
||||
- AES-key, IV, исходное имя, MIME, размер и URL находятся в `<S:file...>` внутри plaintext DM, а значит сами защищены существующим E2EE DM;
|
||||
- получатель скачивает ciphertext с сервера отправителя, проверяет SHA-256, расшифровывает локально и только затем отдаёт Blob браузеру для сохранения под исходным именем;
|
||||
- сервер файлов ключ расшифрования не получает.
|
||||
|
||||
Формат бинарного контейнера `SHiNE_DM` при этом не меняется.
|
||||
|
||||
@@ -228,3 +228,22 @@ DeleteMessage принимает type=5/6. DeleteConversation принимает
|
||||
- при удалении чата с `friend`/`close_friend` UI должен отдельно предупредить, что одна очистка истории не уберёт строку чата, и при подтверждении снять социальную связь и очистить историю.
|
||||
|
||||
Это правило не меняет wire/API-формат DM и не меняет байтовый формат tombstone.
|
||||
|
||||
|
||||
## 15. Файлы в личных сообщениях
|
||||
|
||||
Файл не встраивается байтами в `SHiNE_DM`. До отправки DM официальный браузерный клиент:
|
||||
|
||||
1. генерирует отдельные случайные `AES-256-GCM` key и IV;
|
||||
2. шифрует исходный файл локально;
|
||||
3. вычисляет `fileId = Base58(SHA-256(ciphertext))`;
|
||||
4. подписанным HTTP `PUT` загружает ciphertext на свой текущий access-сервер;
|
||||
5. отправляет обычный контентный DM `type=1/2`, plaintext которого начинается с `<S:file...>`.
|
||||
|
||||
Внутри `<S:file...>` находятся `fileId`, абсолютный URL сервера отправителя, AES-key/IV и исходная метаинформация файла. Так как весь plaintext контентного DM уже шифруется на ключ получателя/отправителя, сервер не получает ключ файла.
|
||||
|
||||
Получатель после E2EE-расшифровки DM скачивает ciphertext непосредственно с указанного access-сервера отправителя, сверяет `SHA-256`, расшифровывает файл в браузере и сохраняет исходный файл.
|
||||
|
||||
Отключение функции «Передача файлов» в локальных дополнительных настройках запрещает только отправку новых файлов; ранее полученные `<S:file...>` остаются скачиваемыми.
|
||||
|
||||
Хранение ciphertext и HTTP-контракт описаны в `docs/API/18_DM_File_Storage_API.md`.
|
||||
|
||||
@@ -68,7 +68,7 @@
|
||||
- `kind` — ASCII-идентификатор типа вставки;
|
||||
- параметры отделяются `;`;
|
||||
- ключ и значение отделяются `=`;
|
||||
- значения не экранируются в v1;
|
||||
- значения обычных v1-вставок не экранируются; для `file` поля `url`, `name`, `mime` кодируются через percent-encoding (`encodeURIComponent`), чтобы `;`, `=` и `>` внутри метаданных не ломали блок;
|
||||
- канонический новый префикс: `<S:`;
|
||||
- legacy-префикс `<SHiNE:` продолжает поддерживаться при чтении.
|
||||
|
||||
@@ -127,7 +127,32 @@ fromLogin|toLogin|timeMs|nonce
|
||||
- UI может рисовать такие сообщения отдельным специальным стилем.
|
||||
- официальный UI не отправляет call-summary, если от старта исходящего звонка до его завершения прошло меньше `5` секунд.
|
||||
|
||||
## 7. Поведение официального UI
|
||||
## 7. Тип `file`
|
||||
|
||||
Формат v1:
|
||||
|
||||
```text
|
||||
<S:file;v=1;id=BASE58_SHA256;url=ENCODED_URL;key=BASE64URL_AES_KEY;iv=BASE64URL_IV;name=ENCODED_NAME;mime=ENCODED_MIME;size=123;encsize=139>📎 example.pdf
|
||||
```
|
||||
|
||||
Поля:
|
||||
|
||||
- `id` — `Base58(SHA-256(ciphertext))`;
|
||||
- `url` — абсолютный URL ciphertext на access-сервере отправителя, percent-encoded;
|
||||
- `key` — случайный 32-byte AES-256 key в Base64URL;
|
||||
- `iv` — случайный 12-byte AES-GCM IV в Base64URL;
|
||||
- `name` — исходное безопасно нормализованное имя файла, percent-encoded;
|
||||
- `mime` — исходный MIME, percent-encoded;
|
||||
- `size` — размер plaintext в байтах;
|
||||
- `encsize` — размер ciphertext в байтах.
|
||||
|
||||
`key`, `iv` и метаданные безопасно находятся здесь только потому, что весь plaintext DM затем шифруется существующим E2EE-механизмом. Они не передаются файловому HTTP endpoint отдельно.
|
||||
|
||||
Текст `📎 example.pdf` после блока служит fallback для старого клиента. Новый официальный UI вместо него рисует карточку файла и кнопку «Скачать».
|
||||
|
||||
Перед локальной AES-GCM-расшифровкой клиент обязан повторно вычислить SHA-256 скачанного ciphertext и сравнить Base58 с `id`.
|
||||
|
||||
## 8. Поведение официального UI
|
||||
|
||||
Официальный UI SHiNE в v1:
|
||||
|
||||
@@ -137,9 +162,10 @@ fromLogin|toLogin|timeMs|nonce
|
||||
- `Звонок: H:MM:SS`
|
||||
- `Звонил, но недозвонился: ...`
|
||||
- для `reply` скрывает сам блок и показывает только текст ответа;
|
||||
- для `file` скрывает fallback-текст и показывает карточку вложения с локальным download/decrypt;
|
||||
- если исходное reply-сообщение не найдено, reply-preview не показывается.
|
||||
|
||||
## 8. Совместимость
|
||||
## 9. Совместимость
|
||||
|
||||
Так как это часть plaintext, а не часть серверного envelope:
|
||||
|
||||
|
||||
@@ -371,3 +371,12 @@ UI-примечание (байтовый формат не меняет): ра
|
||||
Контейнер `type=7/8` является служебным tombstone очистки истории. Его наличие без обычных сообщений `type=1/2` не должно само по себе означать, что у пары есть видимый пользовательский диалог.
|
||||
|
||||
Следствие для UI/агрегата диалогов: `hasDialog` определяется наличием пользовательского содержимого (или непрочитанных пользовательских сообщений), а не наличием служебной записи состояния/tombstone. Формат контейнера при этом не изменяется.
|
||||
|
||||
|
||||
## 15. Вложения `<S:file>` и бинарный формат
|
||||
|
||||
Поддержка файлов не добавляет полей в `SHiNE_DM` и не меняет порядок существующих полей.
|
||||
|
||||
Для контентных `type=1/2` технический блок `<S:file...>` является частью обычного plaintext, который затем попадает в уже существующий зашифрованный `body`. Сам ciphertext внешнего файла в `SHiNE_DM` не включается.
|
||||
|
||||
Поэтому подписи контейнера, `baseKey`, `revisionTimeMs`, `reencryptedAtMs`, алгоритм E2EE DM и правила парности входящей/исходящей копий остаются прежними.
|
||||
|
||||
Reference in New Issue
Block a user