docs/Personal_Messages/Протокол_DM_v1.md — логика протокола, роли API, серверное поведение, routing по access_servers
docs/Personal_Messages/Формат_DM_v1.md — точный бинарный формат контейнера SHiNE_DM
docs/Personal_Messages/Доставка_и_синхронизация_DM.md — доставка на единственный access-сервер, retry-воркер и UI-статусы
docs/Personal_Messages/Технические_вставки_DM_v1.md — формат специальных <S:...> вставок внутри plaintext DM после расшифровки
docs/Personal_Messages/Файлы_DM_v2.md — большие chunked-вложения, голосовые и BitTorrent v2 SHA-256/Merkle metadata
docs/API/18_DM_File_Storage_API.md — HTTP-хранилище зашифрованных файлов DM на access-сервере отправителя

Исторический устаревший документ сохранён отдельно:

Правило сопровождения:

код 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 при этом не меняется.