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
23 lines
3.6 KiB
Markdown
23 lines
3.6 KiB
Markdown
# 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).
|