В ZionVox я начинаю архитектуру доставки не с выбора WebSocket, а с вопроса: что произойдёт, если Core жив, но маршрут клиента до него заблокирован?

Добавить retry недостаточно: повторный запрос не создаёт новый путь. Сделать всё P2P — тоже не готовый ответ: остаются членство в чатах, офлайн-доставка и согласование истории нескольких устройств.

Поэтому базовая схема server-first, а устойчивость транспорта и устойчивость данных разделены.

До отправки у логического сообщения есть clientMessageId. Серверный id появится позже. Локальный tempId относится к записи исходящей очереди. При смене транспорта логическая идентичность не должна меняться: иначе потерянный ACK превращается во второе сообщение.

Локальное хранение — тоже не один кэш. В IndexedDB отдельно живут outbox, relay_queue, ratchet_states, история и discovery-подсказки. Очередь отвечает за отправку, криптографическое состояние — за сессию, кэш истории — за локальный рабочий набор. Полную серверную базу на устройство я не переношу.

Разбор outbox идёт последовательно под блокировкой между вкладками. Это ограничивает параллелизм, зато не позволяет двум вкладкам независимо разбирать один список. Подтверждение серверной записи, доставка адресату и прочтение — отдельные события, не один статус.

Сеть описывается машиной состояний NORMAL, DEGRADED и BYPASS. Она учитывает окна проб и задержку переключения. 403/451, критичные 5xx и 404 необязательного endpoint имеют разный смысл. Один случайный ответ не должен бесконечно переключать маршруты туда и обратно.

Резервный узел не получает доверие только потому, что доступен. Подписанные подсказки проверяются отдельно; у кэша ограничен срок жизни. Мост ведёт к живому Core, а не становится новым владельцем аккаунтов.

Что взять себе: сначала определить идентичность операции, границы локального хранения и merge после восстановления связи. Только потом добавлять следующий транспорт. Без этих правил резервирование увеличивает число состояний, но не обязательно надёжность.

В полной статье — последовательность доставки, конверт сообщения и разбор отказов. Я проектирую такие системы и для клиентских продуктов.

https://arhellist.ru/blog/zionvox-messendzher-dlya-nestabilnoy-seti/