MotoSpot

API не позволяет показать отправителю, прочитали ли его сообщение. Поле MessageDTO.read становится true в течение секунд после отправки, когда получатель просто онлайн и чат не открывал — замер от 1 октября 2026 ниже. То есть это признак доставки, а не прочтения, и другого поля в контракте нет.
Единственный достоверный сигнал сегодня — сокет-событие read. Но это событие: оно происходит один раз, и если клиент в этот момент не слушал, переспросить нечем.
Просим хранить прочтение по паре (пользователь, сообщение) и отдавать автору в истории отдельное поле «прочитано получателем». Пока этого нет, клиент держит состояние прочтения локально, и на новом устройстве или после переустановки галочки будут неверными.

Основа — хранить прочтение по паре (пользователь, сообщение), а не одним флагом на сообщении. Всё остальное из этого следует.

1. Новое поле в истории сообщений. В MessageDTO и MessageWithMediaDTO добавить признак «прочитано получателем» — например readByRecipient: boolean или, что лучше, readAt: string | null (время первого прочтения кем-то кроме автора). Это то самое поле, по которому рисуется вторая галочка.
2. Старое поле не трогать. read пусть остаётся как есть — легаси-клиент живёт на нём. Новый клиент перейдёт на новое поле, когда оно появится.
3. userId в событии read. Сейчас не приходит ни в одной из двух доставок, хотя в схеме объявлен. С ним клиент отличает стороны надёжно и без локальных догадок.
4. messageIds — только те, что реально сменили состояние. Сейчас в событии вся ветка на каждое открытие чата — в длинной переписке это сотни id в каждом пакете без пользы.
5. Групповые чаты — по желанию. Для parity с легаси достаточно «прочитал хотя бы один». Счётчик или список прочитавших нужен только если захотим экран «кто прочитал».
   Стоит также проверить, почему read поднимается без чтения. Если это осознанный признак доставки — отлично, тогда его стоит так и назвать в схеме (delivered), и мы сможем рисовать по нему первую галочку — сейчас у нас нет и этого признака.