mayatnikovandClaude Opus 5
63a7a1ef52
Сервер: регистрация устройств и X-Device, hub с одним потоком на устройство, очередь per-device с фан-аутом без эха отправителю, POST /api/messages с проверками в порядке protocol.md, ACK, SSE с воспроизведением очереди, ready и пингом раз в 20 секунд, контакты в обе стороны при первом сообщении, лимит 30 сообщений в минуту. Клиент: ULID, ключ 1:1 из ECDH через HKDF, шифрование конверта с AAD, sync.js как единственный писатель в IndexedDB, ACK строго после записи, список чатов, экран чата по эталону, разделители дат и «новые», pending и failed с повтором, полоса «нет соединения». ADR-033: у неотправленного есть текст отказа — clock_skew стало видно. ADR-034: входящее с известным id не перезаписывает запись. Собеседник знает открытый id конверта и подменял им чужое сообщение в чужой истории — вплоть до стирания своего присланного, чего «удалить у всех не существует» не допускает. ADR-035: один поток событий на браузерный профиль (locks + BroadcastChannel): две вкладки отбирали поток друг у друга и оставались без живой доставки. ADR-036: повтор отправки сохраняет ULID, пока он в пределах окна часов, — иначе потерянный ответ давал у собеседника два сообщения вместо одного. Приёмка на боевом сервере: два аккаунта, пять устройств, живая доставка, копия на второе устройство, очередь офлайн-устройству, ACK, подмена from игнорируется, чужой deviceId и запрос без Origin отбиваются, плейнтекста в базе и WAL ноль вхождений. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015DbCjVfTFq4ZFG8juD45YJ
3.6 KiB
ADR-035: Один поток событий на браузерный профиль
Контекст
Устройство определяется браузерным профилем (ADR-017), а docs/protocol.md держит одно соединение на устройство: новое закрывает предыдущее. Про несколько вкладок одного профиля не сказано нигде, и клиент открывал EventSource в каждой.
Две вкладки одного аккаунта отбирали поток друг у друга бесконечно: сервер закрывал предыдущее соединение, браузер переподключался через три секунды и закрывал соседнее. Замер — семь соединений за двадцать секунд, каждое ровно по три секунды, и после каждого ready ещё GET /api/contacts и повтор pending. Живой доставки при этом нет ни у одной вкладки: сообщения приходят только выдачей очереди, полоса состояния мигает, сервер получает два десятка запросов в минуту на пользователя — и так, пока открыты обе вкладки.
Решение
- Поток открывает одна вкладка профиля — та, что держит замок
navigator.locksс именемbare-stream. Замок берётся на всё время работы синхронизации и отпускается при выходе и при закрытии вкладки; следующая вкладка получает его сразу и открывает поток. - Остальные вкладки потока не открывают. Экраны, чтение базы и отправка у них работают как прежде:
POSTпотока не требует. - Вкладки рассказывают друг другу об изменениях через
BroadcastChannel: то же, что вкладка раздаёт своим экранам, — изменения лент, список чатов, состояние сети. Пишет в базу каждая сама, поэтому рассылают все, а не только владелец. - Неотправленное повторяет только владелец потока: иначе одно сообщение ушло бы дважды, с разными ULID.
- Оба API нужны вместе: замок выбирает владельца, канал раздаёт его находки. Нет хотя бы одного — вкладка работает как единственная, то есть как до этого решения.
Следствия
- Соединений к серверу столько, сколько браузерных профилей, а не открытых вкладок.
- Вкладка-наблюдатель показывает то же, что владелец, с задержкой в один
postMessage. - Новых текстов интерфейса решение не заводит: наблюдатель видит те же полосы, что владелец.
- Зависимостей не прибавляется:
navigator.locksиBroadcastChannel— нативные браузерные API (ADR-001).