SHA256
Доработать вложенные файлы и архив проекта
This commit is contained in:
@@ -247,3 +247,19 @@ DeleteMessage принимает type=5/6. DeleteConversation принимает
|
||||
Отключение функции «Передача файлов» в локальных дополнительных настройках запрещает только отправку новых файлов; ранее полученные `<S:file...>` остаются скачиваемыми.
|
||||
|
||||
Хранение ciphertext и HTTP-контракт описаны в `docs/API/18_DM_File_Storage_API.md`.
|
||||
|
||||
## 16. Дедупликация файлов и пересылка сообщений (2026-09-11)
|
||||
|
||||
Для HTTP-хранилища DM-файлов действует усиленное правило content-addressed хранения:
|
||||
|
||||
- перед загрузкой каждого ciphertext-объекта официальный UI делает `HEAD /dm-files/{fileId}`;
|
||||
- если сервер подтверждает объект с тем же `fileId` и размером, `PUT` с байтами повторно не выполняется;
|
||||
- сервер перед ответом на `HEAD`, `GET` и перед `alreadyExists=true` сам пересчитывает `SHA-256` сохранённого объекта и сверяет его с `fileId`;
|
||||
- повреждённый или подменённый объект не считается существующим и не выдаётся клиенту; при следующем корректном `PUT` он может быть записан заново.
|
||||
|
||||
Пересылка личного сообщения не вводит новый тип DM и не добавляет признак «переслано». UI создаёт обычное новое контентное сообщение `type=1/2` выбранному собеседнику:
|
||||
|
||||
- для обычного текста переносится отображаемый текст сообщения;
|
||||
- исходный `<S:reply...>` не переносится, поэтому новое сообщение не остаётся ответом на сообщение из старого чата;
|
||||
- для сообщения с файлами повторно используются существующие `<S:file...>`-описатели, поэтому ciphertext не шифруется и не загружается повторно;
|
||||
- сервер и получатель видят пересланное сообщение как обычное новое сообщение без служебной пометки об источнике.
|
||||
|
||||
Reference in New Issue
Block a user