🧩 Задача: Синхронизация истории вызовов между устройствами
1. Цель
Обеспечить автоматическую синхронизацию истории аудио- и видеозвонков (включая статус: входящий/исходящий, длительность, пропущенный, отклонённый и т.д.) между всеми устройствами пользователя, авторизованными под одним JID.
2. Текущее состояние
Звонки реализованы по протоколу Jingle (XEP-0166/XEP-0167) с WebRTC.
Карточка звонка создаётся локально на устройстве, участвовавшем в вызове, и сохраняется в локальной истории.
Синхронизация отсутствует: при звонке на телефоне история не появляется на планшете или компьютере.
3. Требования к реализации
3.1. Способ синхронизации
Использовать существующие в Luma протоколы Message Carbons (XEP-0280) и MAM (XEP-0313) для синхронизации истории вызовов. Это единый подход, уже применяемый для текстовых сообщений.
3.2. Формат данных
Для синхронизации истории вызовов через MAM/Carbons необходимо отправлять специальные служебные сообщения, которые:
Не отображаются у собеседника как обычные текстовые сообщения.
Содержат всю информацию о звонке: тип (аудио/видео), направление (входящий/исходящий), статус (завершён, пропущен, отклонён, без ответа, неудачный), длительность, временная метка, и, возможно, JID участников.
Имеют собственный XML-элемент в пространстве имён, например:
Это сообщение не должно быть отправлено собеседнику (т.е. не должно быть частью обычного Jingle-диалога). Оно отправляется только собственному серверу для архивации и ретрансляции на другие устройства пользователя через Carbons.
3.3. Механизм отправки
После завершения или пропуска звонка локальное устройство формирует такое служебное сообщение.
Сообщение отправляется в собственный JID пользователя (например, user@example.com/Luma) или, возможно, на специальный ресурс. Это гарантирует, что Carbons доставят его на все устройства, а MAM сохранит в архиве.
При получении такого сообщения на других устройствах оно не показывается как обычное сообщение, а парсится и преобразуется в карточку звонка в локальной истории.
3.4. Обработка на других устройствах
При получении служебного сообщения через Carbons или при загрузке истории через MAM, клиент должен:
Распарсить XML.
Создать или обновить запись о звонке в локальной базе данных (Core Data/Realm/и т.п.).
Отобразить карточку звонка в соответствующем чате.
Если звонок был пропущен, корректно обновить счётчик непрочитанных сообщений.
3.5. Обработка конфликтов
Возможна ситуация, когда одно и то же устройство получит дублирующую информацию (например, через Carbons и MAM одновременно). Необходимо предусмотреть дедупликацию на основе уникального ID звонка (можно использовать stanza-id или генерировать UUID).
4. Технические рекомендации
Компонент
Рекомендации
XMPP-стек
Использовать уже существующий слой отправки сообщений (вероятно, XMPPManager или аналогичный).
Модель данных
Расширить локальную модель хранения истории, чтобы она могла принимать записи из удалённого источника.
UI
Карточки звонков уже реализованы. Нужно лишь вызывать их отображение из обработчика входящих служебных сообщений.
Логирование
Добавить логи для отслеживания отправки/получения служебных сообщений для упрощения отладки.
5. Критерии приемки
После завершения звонка на устройстве А, на устройстве Б (под тем же JID) в истории чата появляется карточка этого звонка.
Карточка содержит корректную информацию: статус, длительность, направление.
Пропущенный входящий звонок корректно помечает чат как непрочитанный на всех устройствах.
Синхронизация работает как для онлайн-устройств (через Carbons), так и для офлайн-устройств (при подключении подтягивается через MAM).
Собеседник не видит никаких служебных сообщений от вашего клиента.
6. Дополнительные соображения
Учитывайте, что текущая реализация звонков уже использует Jingle Message Initiation (JMI, XEP-0353). Возможно, имеет смысл интегрироваться с этим механизмом, но описанный выше подход с отдельными служебными сообщениями проще и надёжнее.
В будущем можно рассмотреть возможность синхронизации истории звонков через XEP-0353 или XEP-0354 (Jingle Message Initiation with MAM), но для текущей задачи предложенный подход является оптимальным.
Обязательно протестируйте сценарии с несколькими устройствами и различными статусами звонков.
## 🧩 Задача: Синхронизация истории вызовов между устройствами
### 1. Цель
Обеспечить автоматическую синхронизацию истории аудио- и видеозвонков (включая статус: входящий/исходящий, длительность, пропущенный, отклонённый и т.д.) между всеми устройствами пользователя, авторизованными под одним JID.
### 2. Текущее состояние
- Звонки реализованы по протоколу **Jingle (XEP-0166/XEP-0167)** с WebRTC.
- Карточка звонка создаётся **локально** на устройстве, участвовавшем в вызове, и сохраняется в локальной истории.
- Синхронизация **отсутствует**: при звонке на телефоне история не появляется на планшете или компьютере.
### 3. Требования к реализации
#### 3.1. Способ синхронизации
Использовать существующие в Luma протоколы **Message Carbons (XEP-0280)** и **MAM (XEP-0313)** для синхронизации истории вызовов. Это единый подход, уже применяемый для текстовых сообщений.
#### 3.2. Формат данных
Для синхронизации истории вызовов через MAM/Carbons необходимо отправлять **специальные служебные сообщения**, которые:
- Не отображаются у собеседника как обычные текстовые сообщения.
- Содержат всю информацию о звонке: тип (аудио/видео), направление (входящий/исходящий), статус (завершён, пропущен, отклонён, без ответа, неудачный), длительность, временная метка, и, возможно, JID участников.
- Имеют собственный XML-элемент в пространстве имён, например:
```xml
<call-history xmlns='https://luma.chat/call-history'>
<direction>incoming</direction>
<status>missed</status>
<duration>0</duration>
<start>2026-08-27T10:00:00Z</start>
<with>user@example.com</with>
</call-history>
```
- Это сообщение **не должно** быть отправлено собеседнику (т.е. не должно быть частью обычного Jingle-диалога). Оно отправляется **только собственному серверу** для архивации и ретрансляции на другие устройства пользователя через Carbons.
#### 3.3. Механизм отправки
- После завершения или пропуска звонка локальное устройство формирует такое служебное сообщение.
- Сообщение отправляется **в собственный JID пользователя** (например, `user@example.com/Luma`) или, возможно, на специальный ресурс. Это гарантирует, что Carbons доставят его на все устройства, а MAM сохранит в архиве.
- При получении такого сообщения на других устройствах оно **не показывается** как обычное сообщение, а парсится и преобразуется в карточку звонка в локальной истории.
#### 3.4. Обработка на других устройствах
- При получении служебного сообщения через Carbons или при загрузке истории через MAM, клиент должен:
1. Распарсить XML.
2. Создать или обновить запись о звонке в локальной базе данных (Core Data/Realm/и т.п.).
3. Отобразить карточку звонка в соответствующем чате.
4. Если звонок был пропущен, корректно обновить счётчик непрочитанных сообщений.
#### 3.5. Обработка конфликтов
- Возможна ситуация, когда одно и то же устройство получит дублирующую информацию (например, через Carbons и MAM одновременно). Необходимо предусмотреть дедупликацию на основе уникального ID звонка (можно использовать `stanza-id` или генерировать UUID).
### 4. Технические рекомендации
| Компонент | Рекомендации |
|-----------|--------------|
| **XMPP-стек** | Использовать уже существующий слой отправки сообщений (вероятно, `XMPPManager` или аналогичный). |
| **Модель данных** | Расширить локальную модель хранения истории, чтобы она могла принимать записи из удалённого источника. |
| **UI** | Карточки звонков уже реализованы. Нужно лишь вызывать их отображение из обработчика входящих служебных сообщений. |
| **Логирование** | Добавить логи для отслеживания отправки/получения служебных сообщений для упрощения отладки. |
### 5. Критерии приемки
- [ ] После завершения звонка на устройстве А, на устройстве Б (под тем же JID) в истории чата появляется карточка этого звонка.
- [ ] Карточка содержит корректную информацию: статус, длительность, направление.
- [ ] Пропущенный входящий звонок корректно помечает чат как непрочитанный на всех устройствах.
- [ ] Синхронизация работает как для онлайн-устройств (через Carbons), так и для офлайн-устройств (при подключении подтягивается через MAM).
- [ ] Собеседник не видит никаких служебных сообщений от вашего клиента.
### 6. Дополнительные соображения
- Учитывайте, что текущая реализация звонков уже использует **Jingle Message Initiation (JMI, XEP-0353)**. Возможно, имеет смысл интегрироваться с этим механизмом, но описанный выше подход с отдельными служебными сообщениями проще и надёжнее.
- В будущем можно рассмотреть возможность синхронизации истории звонков через **XEP-0353** или **XEP-0354 (Jingle Message Initiation with MAM)**, но для текущей задачи предложенный подход является оптимальным.
- Обязательно протестируйте сценарии с несколькими устройствами и различными статусами звонков.
---
## 🔗 Полезные ссылки
- [XEP-0280: Message Carbons](https://xmpp.org/extensions/xep-0280.html)
- [XEP-0313: Message Archive Management](https://xmpp.org/extensions/xep-0313.html)
- [XEP-0353: Jingle Message Initiation](https://xmpp.org/extensions/xep-0353.html)
- [Архитектура Luma](https://github.com/TolaMironcenko/Luma/blob/main/Docs/ARCHITECTURE.md)
- [Модель угроз Luma](https://github.com/TolaMironcenko/Luma/blob/main/Docs/SECURITY.md)
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
🧩 Задача: Синхронизация истории вызовов между устройствами
1. Цель
Обеспечить автоматическую синхронизацию истории аудио- и видеозвонков (включая статус: входящий/исходящий, длительность, пропущенный, отклонённый и т.д.) между всеми устройствами пользователя, авторизованными под одним JID.
2. Текущее состояние
3. Требования к реализации
3.1. Способ синхронизации
Использовать существующие в Luma протоколы Message Carbons (XEP-0280) и MAM (XEP-0313) для синхронизации истории вызовов. Это единый подход, уже применяемый для текстовых сообщений.
3.2. Формат данных
Для синхронизации истории вызовов через MAM/Carbons необходимо отправлять специальные служебные сообщения, которые:
3.3. Механизм отправки
user@example.com/Luma) или, возможно, на специальный ресурс. Это гарантирует, что Carbons доставят его на все устройства, а MAM сохранит в архиве.3.4. Обработка на других устройствах
3.5. Обработка конфликтов
stanza-idили генерировать UUID).4. Технические рекомендации
XMPPManagerили аналогичный).5. Критерии приемки
6. Дополнительные соображения
🔗 Полезные ссылки