SimpleX мессенджер: приватный чат без идентификаторов и свой сервер

SimpleX мессенджер — это первая платформа обмена сообщениями, которая не присваивает пользователям никаких идентификаторов: ни номеров телефонов, ни логинов. Разработчики называют такую архитектуру приватной по умолчанию: серверы не знают, кто с кем общается, а сквозное шифрование Double Ratchet защищает содержимое переписки.

SimpleX — один из восьми вариантов нашего обзора децентрализованных мессенджеров; эта страница целиком о нём. Для российских компаний в 2026 году ключевой вызов — не сама технология, а доступность: дефолтные SMP-ретрансляторы недоступны из российских сетей, а средств маскировки трафика у мессенджера нет, поэтому и собственный сервер восстановление доступа не гарантирует. Отсутствие централизованного аккаунта усложняет корпоративное администрирование и аудит, делая выбор между SimpleX и Matrix вопросом приоритетов: абсолютная анонимность против управляемости бизнес-процессов.

SimpleX мессенджер — это сеть обмена сообщениями, которая не присваивает пользователю ни номера телефона, ни username, ни случайного ID: адресация идёт через одноразовые очереди на SMP-ретрансляторах, а сквозное шифрование строится по протоколу Double Ratchet с дополнительным слоем шифрования. Проще говоря, сервер не знает, кто вы — он видит только пары анонимных очередей, через которые идут зашифрованные пакеты.

Такая архитектура рушит привычную модель мессенджера. В Telegram или WhatsApp сервер обязан хранить связь «номер → аккаунт → список контактов», иначе доставка не работает. В SimpleX связь клиент-клиент задаётся ссылкой-приглашением, из которой каждая сторона получает пару входящих и исходящих очередей. Разные собеседники общаются с вами через разные очереди на разных ретрансляторах, поэтому даже полная компрометация одного релея не показывает список ваших контактов — она показывает трафик безымянных очередей.

Отсутствие ID даёт три следствия, важных для инженера. Первое: нельзя «найти пользователя по нику» — контакт добавляется только через явно переданную ссылку или QR. Второе: нет глобального каталога, а значит, нет и точки, которую можно принудительно раскрыть по запросу. Третье: восстановление аккаунта на новом устройстве — это не «войти по номеру и получить историю с сервера», а восстановление из локальной резервной копии базы. Потерял бэкап — потерял историю; сервер её не хранит.

Клиенты доступны как мобильные приложения для Android и iOS и как терминальное CLI-приложение для Linux, MacOS и Windows. Мобильный клиент — основной; CLI мы используем для тестовых сценариев и как «второй экран» на сервере администратора. Для iOS есть предварительная сборка в TestFlight — она удобна, когда нужно опробовать свежую функцию раньше публичного релиза, но полагаться на неё в проде мы не рекомендуем: попадание в бету лимитировано и не гарантировано.

Понимание этой модели — обязательный шаг перед корпоративным пилотом. SimpleX не «безопаснее Telegram на пару процентов», это принципиально другая система адресации, у которой другой набор удобств и другой набор ограничений. Всё, что мы обсуждаем дальше — блокировки, свой релей, сравнение с Matrix — вытекает из этого факта.

Из коробки — нет. И рассчитывать, что доступ удастся вернуть своими силами, тоже не стоит.

Что зафиксировано документально. В трекере проекта с 24 сентября 2024 года открыт и до сих пор не закрыт баг-репорт issue 4933 с заголовком «ALL default server banned in Russia». Речь о том, что недоступны все ретрансляторы, которые проект раздаёт по умолчанию: свежеустановленное приложение из российской сети не находит собеседника, а сообщения остаются неотправленными без внятной ошибки.

Насколько глубоко идёт ограничение. Тут важно различать два уровня. Если недоступны конкретные адреса серверов — вопрос решается сменой сервера. Если опознаётся сам протокол — смена сервера не даёт ничего. В обсуждении того же баг-репорта участник сообщества сообщал в октябре 2024 года, что не смог достучаться до собственного SMP-ретранслятора, размещённого на российском VPS, и сделал вывод о блокировке протокола целиком. Это наблюдение пользователя, а не заявление разработчиков, и мы приводим его именно как сигнал, а не как установленный факт. Но направление обсуждения его поддерживает: в ноябре 2025 года в том же треде просят добавить обфусцированный транспорт, чтобы личный сервер в другой стране заработал из коробки, — такая просьба имеет смысл только если сегодня он не работает.

Чего в продукте нет. Защиты от анализа трафика в SimpleX не реализовано: запрос issue 4300 «Protection from Deep Packet Inspection» открыт с июня 2024 года. Основатель проекта ответил в нём прямо: защита от инспекции протокола в принципе достигается маскировкой под другой, незаблокированный протокол, и это гонка вооружений. То есть трафик SimpleX на сегодня опознаваем, и средств это изменить продукт не предлагает.

Что это значит для компании. Более широкий контекст того, что происходит с мессенджерами в стране, мы собрали отдельно — запрет мессенджеров в 2026 году и что делать бизнесу. Строить корпоративную переписку в России на SimpleX нельзя: доступность не гарантирована ни на дефолтных серверах, ни на собственном, а инструментов маскировки трафика у мессенджера нет. Мы не даём инструкций по обходу ограничений и не советуем на них полагаться — мы предупреждаем, что ограничения существуют и что надёжного технического ответа у самого мессенджера сегодня нет. Если нужна приватная внутренняя переписка с предсказуемой доступностью, разворачивают корпоративный мессенджер на своём сервере на базе Matrix: он в этот сюжет не входит и управляется вами целиком.

Из четырёх сравниваемых мессенджеров SimpleX — единственный без постоянного идентификатора пользователя вообще; у остальных идентификатор есть, отличается только его форма и место хранения. Это одна ось выбора, вокруг которой и раскладываются остальные различия.

Matrix работает через homeserver и аккаунт вида @user:server.tld. Идентификатор постоянный, история хранится на сервере, есть федерация, есть SSO, есть админка, есть аудит. Это самая «корпоративная» из четырёх систем и разумный выбор там, где нужны роли, аудит переписки и интеграция с каталогом сотрудников — как это устроено, мы разбирали в гайде по Matrix и Element. За удобства платите тем, что homeserver знает, кто с кем и когда переписывался — метаданные видны администратору.

Session использует случайный Session ID (65-символьная строка) как постоянный идентификатор и маршрутизирует сообщения через свою onion-сеть на базе Lokinet. ID случайный, но постоянный — потерял, потерял контакты. Метаданные защищены лучше, чем в Matrix, но хуже, чем в SimpleX, потому что сам ID — уже долгоживущий признак пользователя.

Briar принципиально P2P и синхронизируется напрямую между устройствами через Tor, Bluetooth или Wi-Fi. Работает офлайн, что делает его инструментом для протестных и полевых сценариев, но для повседневного корпоративного общения неудобен: сообщения приходят, только когда собеседник онлайн одновременно с вами, а десктоп-клиент долгое время оставался ограниченным.

Delta Chat использует существующий email-ящик как транспорт и адресацию: идентификатор — это ваш email, шифрование — Autocrypt/OpenPGP поверх SMTP/IMAP. Плюс — не нужен отдельный сервер, работает поверх корпоративной почты. Минус — идентификатор публичен по определению, а метаданные (кто кому пишет) видны почтовому провайдеру.

Наш критерий выбора для клиентов выглядит так. Нужен максимум приватности метаданных и вы готовы к «нет истории на сервере» — SimpleX мессенджер. Нужен корпоративный контроль, SSO и аудит — Matrix (об этом ниже отдельно). Нужен постоянный псевдоним и onion-транспорт «из коробки» — Session. Нужен офлайн и P2P без инфраструктуры — Briar. Уже есть корпоративная почта и хочется просто зашифровать переписку без нового сервера — Delta Chat. Не пытайтесь выбрать «лучший» в отрыве от задачи: у этих четырёх систем разные модели угроз.

Всё, что описано ниже, опирается на официальную инструкцию по развёртыванию SMP-сервера — там же лежат команды установки, параметры systemd и Docker, настройка Tor и сертификатов.

Сразу оговорка, чтобы не тратить ваше время: свой ретранслятор решает вопрос контроля и аптайма, но не вопрос доступности в России — если ограничение работает на уровне протокола, собственный сервер тоже окажется недостижим (см. раздел выше). Поэтому свой SMP-ретранслятор имеет смысл в двух случаях: вы не готовы полагаться на чужую инфраструктуру для рабочей переписки или вам нужен ретранслятор с гарантированным аптаймом под конкретную команду. Во всех остальных случаях дефолтных релеев проекта хватает, и городить свой сервер только «чтобы был» — это лишняя точка отказа.

Что стоит знать до начала, по официальной инструкции. Поддерживаются два способа установки: systemd-сервис (скрипт установки, который ставит бинарь, юниты и вспомогательные скрипты бэкапа и обновления) и контейнер из DockerHub; сами разработчики рекомендуют первый и отдельно предупреждают, что из дистрибутивов официально поддерживается только Ubuntu. В межсетевом экране открываются TCP-порты 5223 и 443, а при использовании веб-страницы сервера — ещё и 80. Для скрытого сервиса в Tor документация описывает проброс тех же 5223 и 443 на localhost. Официальный репозиторий проекта содержит Dockerfile и инструкции по сборке образа smp-server; актуальные команды запуска, переменные окружения и версии мы всегда берём из README ветки stable — они меняются от релиза к релизу, и переписывать их здесь бессмысленно. Единственная деталь, которую полезно знать заранее: сервер хранит только очереди и зашифрованные сообщения до их доставки, персональных данных на нём нет — резервировать нужно ключи сервера и конфиг, а не «историю переписки».

По нашему опыту, минимальная рабочая конфигурация для команды до нескольких десятков человек — небольшой VPS у надёжного провайдера, отдельный поддомен с валидным TLS-сертификатом (Let’s Encrypt через reverse-proxy или встроенный механизм — зависит от версии сервера) и открытые входящие порты, которые указаны в актуальной документации проекта. Ставить SMP на тот же хост, где живёт корпоративный веб-сайт, мы не советуем: любой всплеск нагрузки от одного положит второе.

Отдельный вопрос — как заставить клиентов пользоваться именно вашим релеем. В приложении есть раздел настроек с предпочитаемыми SMP-серверами: туда вписывается адрес вашего сервера с его публичным ключом (выводится при первом запуске). После этого новые контакты добавляются через очереди на вашем релее; старые контакты продолжают ходить через прежние ретрансляторы, пока вы явно не пересоздадите ссылку — это часто забывают и потом удивляются, почему «половина чатов через свой сервер, половина — нет».

Не делайте так: не запускайте свой SMP без мониторинга дискового места и без бэкапа ключей сервера. Мы сталкивались с ситуацией, когда клиент поднял релей, забыл про него на полгода, диск заполнился, сервер перестал принимать новые сообщения, а восстановить ключи оказалось неоткуда — пришлось поднимать заново и переподключать все контакты вручную. Простой мониторинг свободного места и еженедельная копия каталога с ключами и конфигом снимают 90% таких инцидентов.

Из сетевых настроек в клиенте отметим одну, о которой спрашивают чаще всего: приложение умеет работать через внешний SOCKS-прокси, и только при включённом прокси становится доступна опция «Use .onion hosts». В документации по настройкам приложения она описана для Android и предполагает отдельное приложение-прокси. Это штатная возможность продукта, а не рецепт обхода ограничений: на опознаваемость самого трафика она не влияет.

Главное ограничение SimpleX в корпоративной среде — прямое следствие его сильной стороны: раз нет идентификаторов пользователей, нет и централизованного администрирования, аудита переписки и восстановления «через админа». Всё, что в Matrix или корпоративном Slack делается кнопкой в консоли, в SimpleX либо невозможно, либо ложится на пользователя.

Администрирование в привычном смысле отсутствует. Нет каталога сотрудников — контакты добавляются ссылками, которые пользователи передают друг другу. Нет ролей и групп доступа на уровне сервера — свой SMP-ретранслятор не «управляет» чатами, он маршрутизирует зашифрованные очереди и не знает, кто с кем говорит. Нельзя отозвать доступ уволенного сотрудника централизованно: пока у него на устройстве установлен клиент и есть ссылки на контакты, он остаётся собеседником для каждого, кто явно не удалит его из своих чатов. Единственный рабочий процесс — при увольнении рассылать команде уведомление «удалите контакт X» и заодно ротировать групповые чаты, где он состоял.

Бэкапы — только на устройстве. Приложение экспортирует локальную базу в зашифрованный архив, который пользователь должен сохранить сам. Если он этого не сделал и потерял телефон — история переписки утеряна безвозвратно, восстановить её с сервера нельзя, потому что сервера её никогда не видели. Для корпоративного пилота мы прописываем в инструкцию обязательный экспорт базы раз в неделю и хранение архива в защищённом месте — иначе первое же сломанное устройство превращается в потерю данных.

Аудит переписки в юридическом смысле — «показать все сообщения сотрудника за квартал» — не реализуем в принципе. Это ломает часть корпоративных сценариев: соответствие финансовым регуляторам, разбор инцидентов с клиентами, судебные разбирательства. Если у вашей организации есть требование архивировать деловую переписку, SimpleX как единственный мессенджер не подходит — либо используйте его только для оперативной связи и разделяйте с системой, где аудит есть, либо выбирайте Matrix.

Отдельно про поддержку: у проекта нет коммерческой поддержки с SLA — вопросы решаются через трекер на GitHub и встроенный канал связи с командой, без гарантированного срока ответа. Для бизнеса, где сломанный мессенджер означает остановку работы, это означает: либо у вас на стороне есть инженер, который разбирается с проблемами SMP-ретранслятора сам, либо вы покупаете внедрение и сопровождение у подрядчика.

Matrix нужен бизнесу тогда, когда SimpleX упирается в отсутствие тех самых корпоративных функций, которые в нём отсутствуют осознанно: централизованные учётные записи, роли, аудит переписки, SSO с корпоративным каталогом и предсказуемый процесс отзыва доступа при увольнении. Если хотя бы одно из этого — жёсткое требование от службы безопасности или регулятора, SimpleX не подойдёт, и никакой обход через инструкции для пользователей эту проблему не закроет.

Практический водораздел выглядит так. Отдел из десяти человек, который обсуждает чувствительные вопросы и готов принять «нет истории на сервере» — это SimpleX мессенджер: минимум инфраструктуры, максимум приватности метаданных. Компания на несколько сотен сотрудников с политикой хранения переписки, интеграцией с Active Directory, инцидент-менеджментом и внутренними каналами по проектам — это Matrix (Synapse или Dendrite) на собственном сервере, с элементами вроде SSO через SAML/OIDC, ботов для интеграции с задачами и модерацией комнат.

Есть и третий сценарий — гибридный, и мы его чаще всего разворачиваем. Matrix берёт на себя рабочую переписку, каналы по проектам, интеграции с CRM и хранение истории. SimpleX остаётся у службы безопасности и топ-менеджмента для обсуждений, которые не должны быть в аудируемом логе даже своего сервера. Такое разделение честнее, чем попытка «сделать всё в одном»: у каждого инструмента своя модель угроз, и смешивать их в одном канале — значит получать худшее от обеих.

Что выбрать конкретно вам, зависит от простого чек-листа. Обязателен ли аудит переписки по регуляторному требованию? Есть ли корпоративный каталог, с которым мессенджер должен интегрироваться? Что важнее — приватность метаданных от собственного администратора или контроль администратора над каналами? Первые два «да» — Matrix. Первое «нет» и приоритет приватности — SimpleX. «Не знаю» — начните с пилота на одном отделе, а не с закупки лицензий на всю компанию.

Мы в IT For Prof разворачиваем и то, и другое: подбираем стек под задачу, ставим сервер на вашей инфраструктуре, настраиваем бэкапы, мониторинг и обучение пользователей, а не оставляем клиента с «вот вам ссылка на GitHub, дальше сами». Если у вас есть требование по защищённой корпоративной переписке и нет ясности, что именно поднимать — напишите нам, разберёмся вместе на пилоте, а не в переписке про абстрактный «мессенджер для бизнеса».

Ответы на часто задаваемые вопросы по теме статьи.

Константин Тютюнник — ведущий инженер IT For Prof. Специализируется на развёртывании защищённых коммуникационных платформ и импортозамещении корпоративного ПО. Имеет опыт настройки собственных SMP-ретрансляторов и интеграции Matrix с Active Directory.