SHiNE-server/Логика_доставки_почты.md

# Логика доставки почты (Signed Messages v2)

## Что отправляет клиент
- Клиент формирует **пару подписанных блоков** с одинаковой базой (`baseKey`):
- `incoming` — сообщение для получателя (`targetLogin = toLogin`).
- `outgoing` — копия для отправителя (`targetLogin = fromLogin`).
- Пара отправляется методом `ReceiveOutcomingMessage` (старое имя `SendMessagePair` оставлено для совместимости).

## Что делает сервер при `ReceiveOutcomingMessage`
1. Валидирует поля запроса (`incomingBlobB64`, `outgoingBlobB64`).
2. Разбирает оба блока и проверяет, что это корректная пара.
3. Проверяет пользователей и криптоподписи по каждому блоку.
4. Пытается сохранить обе записи **одной транзакцией**:
- либо добавляются **обе** записи,
- либо при дубле/конфликте не добавляется **ни одна**.
5. Если пара реально добавилась в БД, сервер запускает realtime-доставку в активные сессии целевых пользователей.
6. Если это дубль, дальнейшая доставка не выполняется (повтор не разгоняется).

## Почему допускаются дубли сети
- В модели с несколькими серверами возможны повторные пересылки одного и того же сообщения.
- Дедупликация делается на уровне БД по ключам записи.
- За счёт этого «шторм» затухает: сервер, который уже видел сообщение, больше его не разгоняет.

## Будущая мультисерверная схема (цель)
- Клиент может отправить `ReceiveOutcomingMessage` на любой из своих серверов.
- Сервер-источник:
- сохраняет пару,
- рассылает исходящее по серверам пользователя A,
- рассылает входящее по серверам пользователя B.
- Остальные серверы повторяют тот же принцип, но благодаря дедупликации повторная пересылка быстро прекращается.

## Важные текущие ограничения
- **A) Реальной мультисерверности пока нет.** Сейчас фактически предполагается один сервер на пользователя.
- **B) Нет полноценного graceful shutdown для очереди пересылки.** Возможен сценарий: запись уже сохранена в БД, но сервер перезагрузился до пересылки дальше. Это нужно доработать отдельно.