Архитектура · Спецификация протокола

Qlavis Citadel — опубликованная спецификация криптографии Qlavis · Messenger.

Каждый примитив с его стандартом и параметрами — и протокольные композиции, построенные на них. Все примитивы стандартизованы NIST или IETF; композиции — собственные разработки Qlavis, и они специфицированы на этой странице. Факты об алгоритмах и параметрах сверены с production-кодом.

01 Стек

Стандартные примитивы.
Своя композиция.

«Пост-квантовость» — это спектр: полное отсутствие сквозного шифрования → классическое E2EE → пост-квант только при установлении сессии → пост-квант при установлении и при непрерывной ротации ключей. Qlavis стоит на этом верхнем уровне, на максимальном параметре NIST — и распространяет пост-квантовую защиту на две поверхности, которые этот спектр не измеряет: аутентификацию (корень доверия идентичности и каждая подпись протокола) и плоскость звонков в реальном времени. Результат — полный набор NSA CNSA 2.0 — ML-KEM-1024, AES-256-GCM, ML-DSA-87, SHA-2 — на каждой поверхности, касающейся пользовательского контента, за годы до федерального мандата США (Executive Order 14412: пост-квантовое установление ключей к 2030 году, подписи — к 2031-му). Каждый алгоритм — опубликованный стандарт NIST или IETF — нигде ни одного проприетарного шифра, хеша или подписи — и каждый сессионный секрет гибриден по построению: чтобы его вскрыть, нужно сломать классический примитив и пост-квантовый.

Пост-квантовая инкапсуляция ключей ML-KEM-1024 FIPS 203 · категория 5 · каждый обмен ключами в продукте

Пост-квантовые подписи ML-DSA-87 FIPS 204 · категория 5 · корень доверия идентичности и все протокольные привязки

Аутентифицированное шифрование AES-256-GCM FIPS 197 + SP 800-38D · 96-битный nonce, 128-битный тег · каждая AEAD-поверхность

Классическое согласование ключей X25519 RFC 7748 · классическая половина гибрида

Классические подписи Ed25519 RFC 8032 · кросс-подписывает PQ-корень доверия · Stellar (требование сети)

Подписи XRP Ledger secp256k1 Детерминированная ECDSA по RFC 6979 · требование сети

Деривация ключей и хеширование HKDF · HMAC · SHA-2 RFC 5869 / RFC 2104 / FIPS 180-4 · запас HMAC-SHA512 в звонках и кошельке

Деривация восстановления BIP39 → SLIP-0010 12 слов, 128 бит энтропии · PBKDF2-HMAC-SHA512, 2048 раундов

Локальная база при хранении SQLCipher 4.14.0 Постраничный AES-256 · таблица рэтчета зашифрована дважды

Привязка к устройству Secure Enclave P-256 Приватный ключ никогда не покидает железо

Пост-квантовые примитивы работают на constant-time-реализациях Apple CryptoKit. Никаких самодельных криптографических примитивов — композиция наша; детали — нет.

Уровень пост-квантовых параметров NIST L5 ML-KEM-1024 и ML-DSA-87 — высшая стандартизованная категория

Ротация ключей звонка 5 мин Смена ключей посреди звонка — без пересогласования и без разрыва

Паддинг сообщений 256 Б Однородные блоки — короткие сообщения неразличимы по длине

Путей расшифровки на сервере 0 Для пользовательского контента — проверяемо по production-схеме под NDA

02 Идентичность

12 слов.
Пост-квантовый корень.

Ни номера телефона, ни email, ни сторонних аккаунтов. Вся идентичность детерминированно выводится из BIP39-фразы в 12 слов (128 бит энтропии), развёрнутой через PBKDF2-HMAC-SHA512 (2048 раундов) в 64-байтовый сид.

i

Две идентичности, одна фраза.

Классический якорь — Ed25519, выведенный по SLIP-0010 на hardened-пути m/44'/637'/0'/0'/0' (coin type здесь — чистый разделитель доменов, не пересекающийся с путями кошелька) — и пост-квантовый корень доверия — ML-DSA-87, порождённый из вторичного сида, полученного HKDF-SHA256 над тем же 64-байтовым сидом с версионированной строкой доменного разделения. Добавление пост-квантового корня не изменило ничего из того, что пользователь должен хранить в бэкапе.

ii

Миграция не стоила пользователям ничего.

Идентичность Ed25519 кросс-подписывает публичный ключ ML-DSA-87. Контакт с классическим пином проверяет эту аттестацию и переносит свой пин на пост-квантовый корень прямо внутри протокола — без церемонии перепроверки, без смены safety-номера и без доверия серверу, который держит только публичные ключи и подделать аттестацию не может.

iii

Пиннинг разделён по стабильности ключей.

Ключи X25519 и ML-KEM-1024 у каждой установки случайны и из фразы не выводятся — осознанное решение. Trust-on-first-use пинит только стабильную подписную идентичность, выведенную из фразы: переустановка не поднимает ложной тревоги, а другая фраза на том же handle блокирует переписку. Контакты дополнительно отслеживают монотонную эпоху опубликованного пакета ключей: эпоха, идущая назад — фирменный признак воспроизведённого или подменённого пакета — поднимает статус безопасности даже при совпадающей идентичности.

iv

Устройство привязано на уровне железа.

Пара ключей P-256, сгенерированная внутри Secure Enclave — её приватный ключ никогда не попадает в память софта — регистрируется как хеш-отпечаток. Восстановление на другом устройстве меняет отпечаток и вызывает видимое оповещение о перепривязке на остальных устройствах аккаунта.

v

Восстановление слепо к фразе.

Клиент заново выводит ключ Ed25519 из введённой фразы и подписывает выданный сервером challenge; сервер сверяет с публичным ключом в записи. Фраза никогда не покидает устройство, и сервер не хранит ничего выведенного из фразы. Резервный PIN хранится только как солёный PBKDF2-хеш; десять неудач подряд стирают весь локальный ключевой материал — фраза по-прежнему восстанавливает идентичность на любом устройстве.

03 Хендшейк

PQXDH на ML-KEM-1024 от начала до конца.

Сессии устанавливаются PQXDH — опубликованным хендшейком Signal — в гибридной инстанциации. Опубликованный пакет prekey несёт ключи идентичности контакта, подписанный prekey, чья подпись сделана ML-DSA-87 и проверяется под запиненной пост-квантовой идентичностью, одноразовые prekey и prekey ML-KEM-1024. Инициатор вычисляет:

SK = HKDF-SHA256( DH1 ‖ DH2 ‖ DH3 ‖ DH4 ‖ SS1 ‖ SS2 )

     4 × связки Диффи–Хеллмана X25519
   + 2 × инкапсуляции ML-KEM-1024
   → 32-байтовый гибридный корневой ключ

Компрометация сессионного ключа требует сломать одновременно X25519 и ML-KEM-1024. Подпись ML-DSA-87 на подписанном prekey заодно аутентифицирует согласованный пост-квантовый набор, так что релей не может незаметно понизить KEM.

Привязка входящей идентичности — fail-closed. Каждое сообщение инициации сессии несёт публичный ключ идентичности ML-DSA-87 инициатора, его кросс-аттестацию Ed25519 и подпись-привязку над X25519-ключом этой установки. Получатель проверяет привязку только под запиненной идентичностью — никогда под ключом, пришедшим по проводу. Провал привязки трактуется как атака: сессия не устанавливается, сообщение не атрибутируется контакту, поднимается предупреждение безопасности, исходящая отправка блокируется до перепроверки. Злонамеренный или принуждённый сервер не может вбросить поддельный хендшейк «от» запиненного контакта — ему нечем подписаться: эти ключи никогда не покидают устройство контакта.

04 Рэтчет

QTR-1024 — Qlavis Triskelion Ratchet.

Ключи текущей переписки даёт конструкция Double Ratchet, расширенная независимой пост-квантовой осью, на максимальном уровне параметров NIST.

04.1 · Три оси DH × цепочки × ML-KEM-1024

Смена ключей каждые 10 сообщений или 24 часа.

Рэтчет Диффи–Хеллмана на X25519, симметричные цепочечные рэтчеты (ключи цепочек продвигаются HMAC-SHA256 с константами доменного разделения) и независимый рэтчет ML-KEM-1024, обновляющий пост-квантовый корень каждые 10 сообщений или 24 часа — что наступит раньше.

04.2 · Гибридные ключи MK = KDF( DH_mk ‖ PQ_mk )

Каждый ключ сообщения требует слома обеих осей.

Каждый ключ сообщения выводится сразу из классической и пост-квантовой оси, поэтому forward secrecy и post-compromise security держатся против классического противника сегодня и квантового — завтра. Signal и Apple ради экономии трафика выбрали в своих рэтчетах KEM с параметром 768; QTR-1024 несёт ML-KEM-1024 (категория 5), меняя примерно 3 КБ на ротацию на высший стандартизованный уровень.

04.3 · Устойчивость к потерям повторное включение · дедуп · ограниченное подтверждение

Потерянные и переставленные сообщения не ломают сессию.

KEM-инкапсуляция, в отличие от DH-значения, не идемпотентна — в прежних пост-квантовых рэтчетах потеря единственного сообщения с материалом новой эпохи ломает сессию. QTR-1024 повторно включает тот же ожидающий KEM-ciphertext в каждый исходящий заголовок, пока пир не подтвердит; получатель держит ограниченную SHA-256-историю обработанных ciphertext’ов и декапсулирует каждый отличный ciphertext ровно один раз, пропуская дубликаты без продвижения состояния; подтверждение объявляется в ограниченном числе последующих сообщений.

04.4 · AEAD и паддинг AES-256-GCM · блоки по 256 байт

Запечатано, аутентифицировано, длина скрыта.

Тела сообщений запечатываются AES-256-GCM (свежий случайный 96-битный nonce, 128-битный тег) с заголовком, привязанным как associated data, и дополняются до однородных блоков в 256 байт — короткие сообщения неразличимы по длине на проводе. Перед любой мутацией при расшифровке состояние сессии снимается в снапшот; неудачная аутентификация откатывает к снапшоту, так что подпорченный ciphertext не может испортить сессию.

05 Звонки

Пост-квант на каждом кадре.
Принуждается самой инфраструктурой.

Штатное SRTP-ключевание WebRTC классическое, поэтому Qlavis намеренно его отключает и накладывает собственный слой шифрования кадров. Принуждение — не настройка клиента.

05.1 · Контроль допуска fail-closed на релее

Классический звонок отклоняется до того, как телефон зазвонит.

В принуждающем production-режиме сигнальный релей валидирует каждый offer звонка до оповещения вызываемого и отклоняет его, если тот не несёт пост-квантовую версию протокола, требуемую capability пост-квантового набора, корректный материал ciphertext ML-KEM-1024 и утвердительный флаг пост-квантовых медиа. Answer проходит симметричные проверки. Устройство вызываемого, как эшелон обороны, само отклоняет offer без KEM-материала ещё до звонка.

05.2 · Согласование ключей ML-KEM-1024 в два захода · в пределах звонка

Звонящий и вызываемый выводят одинаковые ключи из зеркальных инкапсуляций.

Звонящий инкапсулирует к публичному ключу ML-KEM-1024 вызываемого и шлёт ciphertext в offer; вызываемый декапсулирует, инкапсулирует к ключу звонящего и отвечает. Обе стороны выводят одно и то же — ключи привязаны солью к единственному звонку, ключи сигналинга и медиа разделены по домену; релей видит только непрозрачные ciphertext’ы:

master   = HKDF-SHA256( salt = callId, IKM = ss1 ‖ ss2 )
sigKey   = PRF( master, "call:sig" )     — метаданные сигналинга
mediaKey = PRF( master, "call:media" )   — шифрование кадров

05.3 · Шифрование кадров AES-256-GCM · атомарная смена ключа каждые 5 мин

Ключи ротируются посреди звонка — без щелчка и без пересогласования.

Каждый аудио- и видеокадр запечатывается AES-256-GCM под медиа-ключом. Таймер продвигает ограниченный индекс ключа каждые пять минут; ключ кадра для индекса i выводится детерминированно из медиа-ключа и i, а индекс едет в метаданных кадра — приёмники перекатываются вперёд, не прерывая поток.

05.4 · Привязка идентичности Sig( callId ‖ ct ) · fail-closed

Сервер, подменяющий ключи, убивает звонок.

Каждая сторона подписывает свой идентификатор звонка и KEM-ciphertext ключом идентичности ML-DSA-87; подпись едет вместе с пост-квантовым публичным ключом подписанта и его Ed25519-кросс-аттестацией внутри непрозрачного сигнального поля, которое релей пересылает как есть. Приёмник проверяет аттестацию под запиненным корнем доверия, привязку — под доказанным ключом, и пинит пост-квантовую идентичность с первого взгляда прямо из звонка. Подпорченный ciphertext, отсутствующая аттестация, понижение до классического набора от способного пира или несовпадение пина завершают звонок — сравнение safety-строк не требуется; звонок наследует уже запиненную идентичность переписки.

05.5 · Без деградированного режима плюс relay-маршрутизация Hidden IP

Если звонок нельзя запечатать пост-квантово — он не соединяется.

Нет ни состояния «небезопасный звонок», ни закрываемого предупреждения: любой пост-квантовый сбой на пути звонка означает, что звонок не устанавливается или рвётся. Опциональная политика Hidden IP для конкретного звонка ограничивает соединение relay-only-кандидатами (TURN), скрывая адрес устройства от собеседника, с логируемой best-effort-деградацией, если за ограниченное окно не собран ни один relay-кандидат.

06 Медиа и аватары

KEM-DEM на файл.
Аватары — грант на зрителя.

06.1 · Медиафайлы свежий ключ на файл · чистка по доставке

Сервер хранит непрозрачный blob, который не может прочитать — а затем удаляет его.

Каждый файл шифруется на устройстве под свежим случайным 32-байтовым ключом AES-256-GCM и загружается как непрозрачный blob; ключ файла — никогда не сам файл — заворачивается каждому получателю через ML-KEM-1024 внутри сквозно-зашифрованного сообщения, которое на него ссылается. Сервер удаляет blob, как только устройство получателя подтверждает надёжное получение (успешную расшифровку и запись в шифрованное хранилище устройства), с короткой льготной паузой и независимым потолком в 14 дней для так и не скачанных blob’ов; запись о доставке намеренно не несёт идентичности получателя. Пересылка перешифровывает под свежим ключом и загружает новый blob — на сервере форвард не связать с оригиналом.

06.2 · Аватары один blob · N обёрток по зрителям

Одно зашифрованное фото — независимый криптографический грант на каждого зрителя.

Фото профиля шифруется один раз под свежим симметричным ключом; для каждого допущенного зрителя устройство владельца инкапсулирует к его ключу ML-KEM-1024 и запечатывает ключ аватара под результатом с AES-256-GCM, помечая каждую обёртку её AEAD-набором — никакого единого общего ключа профиля. Ротация аватара удаляет вытесненный blob и все старые обёртки. Зрители без обёртки ставят запрос в очередь, которую устройство владельца отрабатывает при следующем выходе в сеть, и на каждом запуске сверяет покрытие по зрителям — никто не остаётся пропущенным навсегда. Сервер пересылает и индексирует обёртки, которые никогда не может открыть.

07 Конверт и устройство

Уведомления несут маршрут, не контент.
Устройство — прочный дом истории.

07.1 · Запечатанный отправитель эшелонированная защита

Идентичность отправителя едет внутри шифрованного тела.

Идентичность отправителя встроена внутрь зашифрованного тела сообщения — это укрепляет её против любого пути, срывающего или переписывающего транспортный конверт. Скажем честно: релей всё же видит маршрут отправитель-получатель, пока существует строка сообщения — но контент не обнажается ни на одном слое, никогда.

07.2 · Пуш-конвейер ноль контента · шифрованные токены

Полезная нагрузка пуша — только метаданные маршрутизации.

Нагрузка несёт идентификаторы разговора и сообщения и handle отправителя для отрисовки; зашифрованное тело скачивает и расшифровывает notification-расширение на устройстве. Локальная настройка устройства полностью скрывает отправителя на экране блокировки. Пуш-токены хранятся зашифрованными AES-256-GCM под внутренним ключом сервера и расшифровываются мимолётно, в памяти, только в момент отправки пуша.

07.3 · Локальное хранилище SQLCipher · Secure Enclave · вне iCloud

Всё, что лежит на устройстве, зашифровано.

Вся локальная база зашифрована постранично SQLCipher; таблица рэтчет-сессий несёт дополнительный AEAD-слой на строку. База кошелька отдельна и ключуется независимо. Медиа-история, переполнение тредов и кэши отрисовки шифруются AES-256-GCM под ключами из Keychain; все хранилища несут файловую защиту iOS и исключены из бэкапа iCloud. Вход в приложение закрыт Face ID / Touch ID с резервным PIN; подпись кошелька переспрашивает аутентификацию на каждой транзакции.

08 Кошелёк

Self-custodial, из тех же двенадцати слов.

Тот же BIP39-сид выводит self-custodial-кошелёк: ключ Ed25519 для Stellar через SLIP-0010 на m/44'/148'/0' и ключ secp256k1 для XRP Ledger через BIP-44 на m/44'/144'/0'/0'/0' (детерминированная ECDSA по RFC 6979). Ключи живут только на устройстве; сервер не хранит ни балансов, ни ключей, ни адресов, ни истории транзакций кошелька. Платёж в чате едет внутри переписки, запечатанный тем же рэтчетом, что и текст — релей видит блок ciphertext, а не сумму.

Подписи транзакций в сети — те, которых требует каждая цепь (сегодня классические) — и мы говорим это прямо, а не приукрашиваем. У обоих леджеров опубликованы пост-квантовые дорожные карты — Stellar к 2027, XRP Ledger к 2028 — а слой идентичности над ними уже пост-квантовый.

09 Сервер

Слепой релей — проверяемо, не обещано.

Сервер — транспортный посредник, который не может расшифровать пользовательский контент и держит так мало, как позволяет протокол. Мы не называем его zero-knowledge — в криптографии этот термин значит другое. Мы называем его тем, что он есть, и письменно фиксируем, что он всё-таки видит.

09.1 · Хранение ключей только публичные ключи

На сервере не существует ключа, расшифровывающего пользовательский контент.

Приватные ключи пользователей существуют только на их устройствах, в Keychain и Secure Enclave. Сервер держит публичные ключи — Ed25519, ML-DSA-87, X25519, ML-KEM-1024, prekey — материал, который нужен любому пиру для старта сессии. Его единственный внутренний симметричный ключ шифрует пуш-токены. Транспорт клиент-сервер идёт по TLS с пиннингом сертификатов — второй конверт вокруг контента, который уже зашифрован сквозно.

09.2 · Минимизация данных чистка по доставке · потолок 14 дней

Контент вычищается по подтверждённой доставке — на всех планах.

Контент доставленного сообщения стирается в момент доставки (для статуса доставки остаётся бесконтентная заглушка); доставленные медиа-blob’ы удаляются по надёжному получению; сигнальная строка звонка удаляется в момент его окончания — долгая история звонков существует только на устройстве пользователя. Потолок в 14 дней страхует всё недоставленное. Списки контактов никогда не попадают на сервер. Удаление аккаунта уведомляет каждого бывшего собеседника по отдельности и не оставляет глобального реестра удалённых аккаунтов.

09.3 · Честный остаток метаданные, которые мы всё же видим

Мы публикуем остаточную поверхность, а не отрицаем её.

Как транспортный посредник, релей видит маршрутизацию, пока существует строка сообщения, временные метки событий, размеры ciphertext’ов (тела дополнены до блоков в 256 байт), огрублённое присутствие (размытый флаг «в сети»; last-seen, округлённый до пяти минут) и состав чатов. Поза нулевого plaintext структурна и непрерывно проверяема — квалифицированным ревьюерам доступен read-only-доступ к production-базе под NDA.

10 Верификация

Проверено машиной.
Дальше — аудит.

Дизайн протокола формально верифицирован машинно-проверенными моделями в пяти независимых движках — Verifpal, ProVerif, CryptoVerif, Tamarin и F*/DY* — тот же класс инструментов и та же модель противника, что в опубликованных анализах PQXDH и SPQR Signal. Верифицированы одиннадцать свойств, каждое дополнительно прогнано со снятой защитой как негативный контроль, обязанный провалиться — чтобы доказательство что-то значило. Среди них:

Злонамеренный или принуждённый сервер не может выдать себя за запиненный контакт — модель до исправления заново находит эту атаку.
Harvest-now-decrypt-later закрыт: запиши трафик сегодня, сломай весь X25519 потом — всё равно нечитаемо.
Даже со сломанным ключом Ed25519 на руках сервер не может подделать идентичность: корень доверия — ML-DSA-87.
Каждый ключ сообщения остаётся секретным, пока не падут и X25519, и ML-KEM-1024 — доказано без ограничений, на каждом сообщении, в F*/DY*.
Сервер не может незаметно понизить KEM-набор — его аутентифицирует prekey, подписанный ML-DSA-87.

Скажем прямо: эти инструменты верифицируют дизайнпротокола, а не код реализации. Независимый внешний аудит реализации — стандартный следующий шаг — тот же, что прошли Signal и Apple — и он ещё не проведён. Полный вайтпейпер, отчёт о формальной верификации с моделями и логами прогонов и read-only-доступ к production-базе доступны под NDA.

11 Сравнение

С опубликованным state of the art.

Публичный статус на июль 2026; первоисточники под таблицей.

Мессенджер	PQ-хендшейк	PQ-рэтчет	PQ-подписи	PQ-звонки	Идентичность	Платежи в чате
Qlavis · Messenger	✔ ML-KEM-1024 (FIPS 203)	✔ ML-KEM-1024 (NIST L5)	✔ ML-DSA-87 (FIPS 204)	✔ принуждается на сервере	✔ 12 слов — без телефона и email	✔ Stellar + XRP Ledger
Корпоративные платформы
NetSfere	◐ гибрид ML-KEM-1024 (ECC сохранена)	✗ не опубликован	✗ не опубликованы	✗ не заявлены	✗ корпоративный аккаунт	✗
AWS Wickr	✗ не опубликован	✗ не опубликован	✗ классические	✗	✗ корпоративный аккаунт	✗
Wire	✗ классический MLS (PQ в планах)	✗	✗ классические (Ed25519)	✗	✗ email	✗
Element / Matrix	✗ классический (Curve25519)	✗ классический (Megolm)	✗ классические (Ed25519)	✗	◐ аккаунт на homeserver	✗
SecuSUITE (BlackBerry)	✗ классический (PQ анонсирован)	✗	✗ классические	✗	✗ корпоративная выдача	✗
Потребительские ориентиры
iMessage PQ3	✔ Kyber-1024	◐ Kyber-768 (ротация)	✗ классические (ECDSA)	✗	✗ Apple ID + телефон	✗
Signal + SPQR	✔ Kyber-1024	✔ ML-KEM-768	✗ классические (Ed25519)	✗	✗ номер телефона	✗
SimpleX	✔ sntrup761	✔ двойной KEM	✗ классические (Ed25519)	✗	✔ случайный ID	✗
WhatsApp	✗	✗	✗ классические	✗	✗ телефон	✗

Три обязательства, которые, насколько нам известно, не повторяет ни один работающий конкурент в 2026 году: ML-KEM-1024 в рэтчете, где Signal и Apple сознательно выбрали 768 ради трафика; пост-квантовый корень доверия идентичности, где каждый конкурент спаривает пост-квантовый KEM с классической подписью; и пост-квантовое принуждение звонков на сигнальном сервере, где каждый конкурент оставляет аудио и видео на классическом SRTP.

Источники: security.apple.com/blog/imessage-pq3 (фев 2024) · signal.org/blog/spqr (окт 2025) · signal.org/docs/specifications/pqxdh · simplex.chat/blog (мар 2024) · netsfere.com/Resources/pqc (июл 2026) · wire.com/en/messaging-layer-security (июл 2026) · github.com/matrix-org/vodozemac · blackberry.com/secure-communications (2026)

12 Стандарты

Стандарты, из которых собрана спецификация.

NIST FIPS 203 — ML-KEM (авг 2024) · NIST FIPS 204 — ML-DSA (авг 2024) · FIPS 197 + SP 800-38D — AES-GCM
IETF RFC 7748 (X25519) · RFC 8032 (Ed25519) · RFC 5869 (HKDF) · RFC 2104 (HMAC) · RFC 8018 (PBKDF2) · RFC 6979 (детерминированная ECDSA)
BIP39 · BIP32 · SLIP-0010 — детерминированная деривация ключей
Спецификации Signal — PQXDH, Double Ratchet, SPQR (signal.org/docs)
NSA CNSA 2.0 (сен 2022) · Executive Order 14412 (июн 2026): пост-квантовое установление ключей к 2030, подписи к 2031

Полный вайтпейпер, отчёт о формальной верификации и read-only-доступ к production-базе — доступны квалифицированным инвесторам, аудиторским фирмам и командам закупок под NDA: hello@qlavis.app