Мессенджер, который не знает, кто вы

Практически все мессенджеры знают, кто вы. Они запрашивают данные при регистрации, и без этих данных просто не работают. WhatsApp знает ваш номер телефона. Telegram знает аккаунт, привязанный к номеру телефона. Signal, при всей своей репутации образцового privacy-инструмента, тоже знает как вам позвонить. Max… ну там номер телефона и есть ваш идентификатор. Сервисы электронной почты типа yandex, mail.ru или gmail также требуют при регистрации указать номер телефона, заявляя, что это для защиты аккаунта.

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

Шифрование в этой картине решает только одну задачу: оно прячет содержимое переписки. Но не сам факт переписки, не её участников, не время, не частоту, не социальный граф. Всё это сервер видит, потому что иначе он не сможет работать.

SimpleX устроен принципиально иначе. У него нет идентификатора пользователя. Совсем. Нет ни номера, ни логина, ни адреса электронной почты, ни постоянного публичного ключа, ни даже случайного числового идентификатора, который сервер мог бы связать с конкретным человеком. И это не маркетинговая формулировка, а архитектурное свойство протокола.

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

Что прячет шифрование, а что нет

Прежде чем переходить к архитектуре, давайте договоримся о понятиях. Когда говорят, что мессенджер «безопасен», обычно имеют в виду сквозное шифрование: содержимое сообщения не может прочитать никто кроме отправителя и получателя.

Это важное свойство, но оно решает только половину задачи, поскольку у любого разговора есть два компонента.

Содержание. То, что написано в сообщении. Текст, картинка, файл.
Метаданные. Кто кому пишет, когда, как часто, с каких устройств, в каких группах состоит, кто отвечает первым.

Удобная аналогия — обычное бумажное письмо. Содержание — то, что лежит внутри конверта. Метаданные — то, что написано на конверте: адреса, дата отправки, штемпели. Шифрование надёжно закрывает письмо, но конверт остаётся открытым.

Беда в том, что метаданные часто ценнее содержимого. По одному только графу связей и расписанию переписки можно вычислить близкие отношения, рабочие команды, источники журналиста, участников акции, врача, психотерапевта, любовника. Бывший директор АНБ Майкл Хейден когда-то сказал прямо: «We kill people based on metadata». Содержание сообщений для этого не понадобилось.

Signal делает много для защиты метаданных. Есть «запечатанный отправитель» (sealed sender): информация о том, кто прислал сообщение, шифруется так, что сам сервер её не видит, а сравнивает только криптографически. Есть «приватное обнаружение контактов» (private contact discovery): когда вы загружаете записную книжку, чтобы найти знакомых в Signal, сервер не получает её в открытом виде, а сверяет хеши внутри защищённого анклава процессора. На сервере не хранится история переписки и журналы доставки. И это хорошо, но всё-таки сервер знает, что у телефона X есть аккаунт, что он зарегистрирован, что он сейчас онлайн. Этого достаточно, чтобы построить значительную часть социального графа на стороне сервера или того, кто получит к нему доступ.

SimpleX пытается решить более сильную задачу: спрятать не содержимое переписки, а сам факт существования социальной связи. Сервер не должен иметь возможности сказать, что «пользователь А и пользователь Б знакомы». Не потому, что эта связь зашифрована, а потому, что в системе нет понятия «пользователь А».

Однонаправленные очереди вместо аккаунтов

Главная инженерная идея SimpleX лежит в названии. Simplex в теории связи — это однонаправленный канал. В отличие от duplex, по нему данные идут только в одну сторону.

Вместо аккаунтов в SimpleX используются однонаправленные очереди сообщений (simplex queues). Очередь живёт на конкретном сервере-ретрансляторе (relay-сервере) и работает так:

кто-то один пишет в неё сообщения;
кто-то один их забирает;
сервер только временно хранит то, что ещё не было получено.

Сервер-ретранслятор — это просто промежуточный узел, который принимает сообщения и держит их у себя ровно до тех пор, пока за ними не придут. Он не «принадлежит» никому из участников и сам по себе не знает, чьи сообщения через него идут. Дальше я буду называть такие узлы просто ретрансляторами.

Очередь не привязана к личности. Это просто адрес на сервере, у которого две разные «ручки»: одна для отправителя, другая для получателя.

Когда Алиса хочет общаться с Бобом, Алиса создаёт у себя на телефоне новую очередь на каком-нибудь ретрансляторе. Получает от сервера два идентификатора: один для приёма (RcvId, recipient ID — идентификатор получателя) и один для отправки (SndId, sender ID — идентификатор отправителя). Идентификатор приёма Алиса оставляет себе. Идентификатор отправки она каким-то внешним способом передаёт Бобу — через QR-код, ссылку, бумажку, заранее согласованный канал.

С этого момента Боб может писать в эту очередь, используя SndId. Алиса — забирать из неё сообщения, используя RcvId. Сервер видит две независимые операции: «кто-то пишет по адресу X» и «кто-то забирает по адресу Y». Без знания того, что X и Y относятся к одной и той же очереди (а это знание есть только у клиентов), он не может связать их в осмысленную картину.

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

Эта конструкция называется попарным соединением (pairwise connection). Для каждого нового контакта Алиса создаёт свою отдельную пару очередей. У неё нет «учётной записи», которую можно было бы переиспользовать. Она для каждого собеседника предъявляет, по сути, новый одноразовый «почтовый ящик». Получается то, что в криптографических протоколах называют попарными псевдонимами (pairwise pseudonymous identifiers): уникальная «личность» для каждой пары собеседников. Никто из посторонних, включая сервер, не может по этим псевдонимам понять, что за ними стоит один и тот же человек.

Если у Алисы 50 контактов, у неё на серверах живёт около 100 очередей, и ни один из серверов не может сделать вывод, что за ними стоит один человек.

Криптография нижнего уровня: как защищена сама очередь

Очередь — это не просто адрес. Она защищена несколькими криптографическими механизмами, и это первый слой, на котором стоит остановиться.

Когда Алиса создаёт очередь, она генерирует у себя три пары ключей:

ключ авторизации получателя — чтобы сервер пускал к очереди только её;
ключ согласования с сервером (X25519) — чтобы получать сообщения по защищённому каналу;
ключ шифрования сообщений в этой очереди (тоже X25519).

Сервер в ответ возвращает идентификаторы RcvId, SndId и свой публичный ключ для DH-согласования. Алиса передаёт Бобу SndId плюс свой публичный ключ шифрования. Боб, прежде чем начать писать, генерирует свою пару ключей для авторизации отправителя и через специальное подтверждающее сообщение регистрирует её у сервера. С этого момента очередь «закрывается»: сервер принимает в неё только команды, подписанные Бобом, и только команды чтения, подписанные Алисой.

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

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

И всё это ещё обёрнуто в TLS 1.3 для транспорта. Сертификат сервера привязан к адресу: в самом адресе ретранслятора зашит отпечаток (fingerprint) его оффлайнового сертификата — это короткая криптографическая «фотография» сертификата, по которой можно проверить, что вы используете нужный сервер, а не тот что вам подсунули. Клиент при подключении проверяет, что предъявленный сертификат подписан именно тем, чей отпечаток зашит в адресе. Этот приём позаимствован у Tor.

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

Двойной храповик и его постквантовая версия

Поверх всех этих транспортных слоёв работает то, ради чего обычно и приходят в современный приватный мессенджер: сквозное шифрование с прямой секретностью (forward secrecy) и восстановлением после взлома (break-in recovery). Эти два свойства принято объяснять отдельно, потому что они защищают от разных бед.

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

Восстановление после взлома — свойство более сильное и редкое. Оно означает, что даже если злоумышленник украл текущее состояние ключей с устройства, после нескольких следующих сообщений он его «потеряет». Это происходит за счёт того, что при каждом ответе участники генерируют новые случайные ключи и подмешивают их в общее состояние. То есть тот же злоумышленник, который сегодня видит вашу переписку «вживую», через несколько обменов снова окажется заперт снаружи.

Сегодня эталоном такой конструкции считается алгоритм двойного храповика (Double Ratchet), придуманный командой Signal. Слово «храповик» здесь означает механизм, который крутится только в одну сторону: ключи постоянно обновляются, и старые состояния математически невозможно «отмотать назад». Двойной он потому, что обновление идёт по двум независимым линиям. Одна линия срабатывает на каждом отправленном сообщении и обеспечивает прямую секретность. Вторая срабатывает каждый раз, когда направление переписки меняется (то есть когда тот, кто отвечал, начинает писать сам), и обеспечивает восстановление после взлома. SimpleX тоже использует двойной храповик, но с двумя важными дополнениями.

Во-первых, у SimpleX шифруются ещё и заголовки сообщений (header encryption — шифрование заголовков). В классическом двойном храповике заголовок с номером сообщения и счётчиком шага храповика виден в открытом виде. SimpleX дополнительно зашифровывает его отдельным симметричным ключом, который выводится из общего состояния. Это делает шифротексты с одного и того же шага храповика структурно неотличимыми: снаружи нельзя понять, в каком месте «цепочки» находится конкретное сообщение.

Во-вторых, и это куда интереснее, в SimpleX добавлена постквантовая защита всего механизма храповика, а не только начального обмена ключами.

Здесь нужно небольшое отступление. Современная криптография на эллиптических кривых (X25519, Ed25519) надёжна против классических компьютеров, но уязвима против достаточно мощных квантовых. В реальной доступности таких компьютеров пока нет, но злоумышленник может уже сегодня записывать чужой трафик и хранить его в архиве в расчёте на «когда-нибудь потом». Эта стратегия так и называется: «собирай сейчас, расшифруешь потом» (harvest now, decrypt later).

Чтобы защититься от неё, придумали постквантовые криптосистемы. В двойном храповике обычно применяют не «полное» постквантовое шифрование, а особую конструкцию — механизм инкапсуляции ключа (key encapsulation mechanism, сокращённо KEM). Идея KEM проста. Одна сторона публикует свой постквантовый публичный ключ. Вторая сторона придумывает случайный секрет, «упаковывает» (инкапсулирует) его этим ключом и присылает обратно зашифрованным. Теперь у обеих сторон есть общий секрет, и злоумышленник, даже располагая квантовым компьютером, не сможет его восстановить.

Signal решает задачу постквантовой защиты через протокол PQXDH (Post-Quantum Extended Diffie-Hellman — постквантовый расширенный обмен Диффи — Хеллмана): на этапе начального обмена ключами поверх обычного X25519 подмешивается постквантовый KEM, конкретно — CRYSTALS-Kyber. Это защищает первую сессию, но не защищает последующие шаги храповика. Если злоумышленник дождётся появления квантового компьютера и взломает один из обновляемых эллиптических ключей в середине разговора, у него снова появится точка входа, и восстановление после взлома в постквантовом смысле не сработает.

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

Это потребовало нетривиального инженерного хода. KEM по своей природе асимметричен: одна сторона публикует публичный ключ, другая упаковывает под ним случайный секрет и отправляет обратно. Алгоритм Диффи — Хеллмана, на котором работает обычный храповик, наоборот симметричен: обе стороны публикуют свои половинки и независимо вычисляют общий секрет, и неважно, кто сделал это первым. Чтобы вписать асимметричный KEM в симметричный ритм двойного храповика, в SimpleX крутят сразу два KEM-обмена параллельно, в режиме «шаг в шаг» (lock-step): роли «того, кто публикует ключ», и «того, кто упаковывает секрет», по очереди меняются местами от шага к шагу.

В качестве самого KEM авторы намеренно выбрали не Kyber, а Streamlined NTRU Prime — его вариант sntrup761. Это альтернативный постквантовый алгоритм из того же семейства задач на решётках. Аргументы в пользу этого выбора следующие: .

Sntrup761 уже много лет используется в OpenSSH, у него длинная история практической эксплуатации.
Процесс стандартизации Kyber (стандарт получил название ML-KEM) вызывал у независимых криптографов вопросы. В частности, Дэниел Бернстайн, один из авторов NTRU Prime, подробно разбирал, как NIST из стандарта убрал важный шаг хеширования, который защищал от атак на скомпрометированный генератор случайных чисел.
Sntrup761 свободен от подозрений в патентных конфликтах, в отличие от ML-KEM.

С точки зрения собственно протокола это означает, что в SimpleX уже несколько лет работает один из самых сильных постквантовых режимов среди мессенджеров общего пользования.

Невидимый адрес: как сообщение находит получателя без идентификатора

Дальше начинается сетевая часть, которая, на мой взгляд, и есть самая красивая.

Допустим, у Алисы и Боба уже есть пара очередей. Алиса хочет отправить сообщение. Что физически происходит?

Её клиент подключается к ретранслятору, на котором живёт нужная очередь, и кладёт туда зашифрованный байтовый блок. Сервер записывает его во внутренний буфер очереди и ждёт, пока кто-то с правильным RcvId придёт за ним. Когда Боб подключается, сервер отдаёт ему накопленные сообщения и удаляет их у себя.

Никакого «получателя» в этой картине нет. Сервер не знает, что сообщение предназначено «Бобу». Он знает, что есть очередь с такими-то идентификаторами, и в неё кто-то имеет право писать, а кто-то — читать. Эти «кто-то» вообще не имеют профилей внутри его базы данных.

Алиса для разных контактов использует разные очереди на разных серверах. Если она пишет Бобу, Карлу и Диане, её клиент может стучаться к трём совершенно несвязанным операторам ретрансляторов, не позволяя ни одному из них собрать полную картину. Это похоже на принцип разделения по отсекам (compartmentalization) в оперативной безопасности: каждый узел знает только свою часть мозаики, и потеря одного узла не раскрывает всей картины.

Размеры сообщений тоже нормализуются. SimpleX применяет дополнительное заполнение (padding) на нескольких уровнях: каждое сообщение дополняется случайными байтами до фиксированной длины. Это нужно, чтобы внешний наблюдатель не мог по длине шифротекста догадаться, переслан ли там стикер, длинное письмо или короткая служебная команда. А сами серверы работают как «быстрые смешивающие узлы» (low-latency mix nodes): порядок входящих и исходящих сообщений у них перетасован, и поэтому трудно соотнести «вошло вот это» с «вышло вот то» только по времени.

Двухзвенная маршрутизация: спрятать IP даже от собственного ретранслятора

До определённого момента у этой схемы оставалась одна неприятная дыра. Когда Алиса пишет в очередь Боба, она подключается напрямую к серверу, который выбрал Боб. И этот сервер видит её IP-адрес, если она не пользуется Tor. Если Боб сам владеет этим сервером (или дружит с его владельцем), он потенциально может сопоставить IP-адреса входящих с тем, что в этот момент в его очередь поступило новое сообщение.

Это противоречит самой идее «сервер не должен знать, кто пишет». В версии 5.8 (лето 2024-го) в SimpleX появилось решение — приватная маршрутизация сообщений (private message routing), она же двухзвенная луковичная маршрутизация. «Луковичная» (onion) означает, что сообщение упаковано в несколько слоёв шифрования, как луковица в шелуху: каждый промежуточный узел снимает свой слой и видит ровно ту информацию, которая нужна ему, и не больше.

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

В итоге ни один из серверов не имеет полной картины:

первый ретранслятор знает IP отправителя, но не знает получателя;
второй ретранслятор знает, в какую очередь идёт сообщение, но не знает, чей это IP.

По форме это очень похоже на двухзвенный onion из Tor. Но есть тонкая разница в зернистости анонимности. В Tor вы один раз строите цепочку из трёх узлов и какое-то время гоните через неё весь свой трафик: это анонимность на уровне цепочки (per-circuit anonymity). В SimpleX каждое отдельное сообщение использует свежие одноразовые ключи и потенциально другую пару ретрансляторов: это анонимность на уровне сообщения (per-message anonymity). Даже два сообщения, идущие в одну и ту же очередь подряд, склеить друг с другом по виду шифротекста или сетевым следам невозможно.

Автор прямо пишет, что многое в этой схеме навеяно микснетами (mix networks — смешивающими сетями, в которых трафик от разных пользователей перемешивается, чтобы скрыть, кто кому пишет; одно из известных воплощений — сеть Nym). В каком-то смысле SimpleX можно рассматривать как специализированный микснет, заточенный именно под асинхронные сообщения, а не под общий веб-трафик.

При этом Tor никуда не делся: SimpleX по-прежнему отлично работает поверх Tor, и большинство преднастроенных серверов имеют .onion-адреса. Для параноидальных сценариев можно использовать оба механизма одновременно: трафик идёт через Tor, а уже внутри Tor — через двухзвенную маршрутизацию SimpleX. Это даёт защиту по принципу «один слой вышел из строя, второй ещё держится»: если кто-то скомпрометирует Tor, остаётся внутренний onion; если кто-то скомпрометирует один из ретрансляторов, остаётся Tor.

Почему это не P2P и почему это правильно

В разговорах о приватности часто звучит мысль, что настоящее решение — это одноранговая сеть без серверов вообще (peer-to-peer, или сокращённо P2P): в ней каждый участник одновременно и клиент, и сервер, и сообщения ходят напрямую от устройства к устройству. SimpleX сознательно не идёт по этому пути, и причины тому довольно веские.

Чисто одноранговый мессенджер хорош тем, что в нём нет посредника, но плох тем, что собеседники видят IP-адреса друг друга и должны быть онлайн одновременно. Это убивает асинхронность (одно из главных свойств мессенджера: написать тому, кто сейчас спит) и создаёт прямой канал утечки сетевой информации.

Ретрансляторы решают обе проблемы. Они принимают сообщения в любое время, хранят их короткий срок и отдают, когда получатель появится онлайн. А ещё они служат буфером, который скрывает прямую сетевую связь между отправителем и получателем.

Парадокс в том, что в защите метаданных промежуточный сервер часто оказывается полезнее, чем его отсутствие. Главное, чтобы он знал как можно меньше. SimpleX устроен так, что отдельный сервер действительно знает мало, а доверие распределено между несколькими операторами, которых выбирают сами пользователи.

И ещё один важный момент: серверы SimpleX взаимозаменяемы. Их можно поднимать самому, можно использовать чужие, можно мигрировать с одного на другой. Протокол не привязан к серверам, которые держит компания-разработчик. В этом смысле SimpleX ближе к федеративным сетям (где разные серверы обмениваются между собой, как у электронной почты), чем к классическому централизованному мессенджеру, хотя в привычном смысле здесь даже федерации не нужно: серверы вообще не знают друг о друге и не общаются между собой.

Каналы: как сделать публичность в системе без идентификаторов

Самое свежее интересное добавление — каналы SimpleX (SimpleX Channels) в версии 6.5 (апрель 2026-го). Группы в SimpleX уже какое-то время существовали, но они устроены как «расширенная попарность»: участники по сути обмениваются сообщениями через попарные очереди друг с другом. Это отлично работает для приватных групп, но плохо масштабируется на тысячи подписчиков. Каналы — другой режим.

В канале содержимое сообщений видно операторам ретрансляторов. Это сознательный размен: ради того, чтобы канал мог быть публичным и доступным многим, его контент не шифруется сквозным шифрованием так, как в личной переписке. Зато сохраняется главное.

Реальная личность владельца канала не известна ни операторам, ни подписчикам, ни сети.
Реальная личность подписчика не известна никому, включая владельца канала.
Подписчики не видят друг друга.
Каждый канал использует несколько ретрансляторов, поэтому один оператор не может его заблокировать.

Получается то, что в манифесте проекта называют приватностью участия (privacy of participation): вы прячете не текст, а сам факт того, что вы здесь. По духу это близко к идее onion-сервисов и публичных площадок в Tor, но без необходимости подниматься на отдельную инфраструктуру.

Делается такой режим возможным именно потому, что в SimpleX в принципе нет идентификаторов пользователей. Автор сам формулирует это коротко: нельзя добавить приватность участия в сеть, которая идентифицирует своих пользователей, как нельзя добавить приватность в мессенджер с идентификаторами на номерах телефона.

Что SimpleX по-прежнему не делает

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

Пользоваться SimpleX заметно сложнее, чем привычным мессенджером. Здесь нет глобального поиска людей, поэтому нельзя «найти кого-то по нику», нельзя кликнуть на упоминание и попасть в профиль. Контакт появляется только тогда, когда кто-то одной из сторон передал другой одноразовую ссылку или QR-код. Это сильная защита от спама и от массового сбора аккаунтов, но это непривычный шаг для людей, привыкших к Telegram.

Аудитория маленькая. Сетевой эффект (мессенджер тем полезнее, чем больше в нём ваших знакомых) никто не отменял. Крутая технология не поможет, если ваши собеседники не готовы ставить себе ещё один мессенджер ради переписки с вами.

Серверы всё-таки существуют. Они знают намного меньше, чем сервер WhatsApp или Telegram, но они есть. У них есть владельцы. Они могут падать, могут блокировать, могут вести журналы (другое дело, что осмысленных журналов из их положения получить очень сложно). Полная независимость от инфраструктуры пока остаётся мечтой.

Протокол не отменяет операционной безопасности (OPSEC, operational security — гигиена обращения с собственными данными). Если вы используете один и тот же профиль везде, ходите в интернет с домашнего IP без Tor, рассказываете в чате своё настоящее имя, никакая криптография вас не спасёт. SimpleX даёт хорошие инструменты, но не делает за пользователя его работу по обеспечению цифровой гигиены.

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

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

Кто это всё придумал

Полезно сказать пару слов про автора, потому что SimpleX — это во многом результат работы одного программиста. Евгений Поберёзкин — программист с российскими корнями, давно живущий в Великобритании. До SimpleX он был известен прежде всего как автор Ajv — валидатора JSON Schema, который скачивают порядка шестисот миллионов раз в месяц и который встроен буквально во всё, что обрабатывает JSON в экосистеме Node.js. Иначе говоря, человек, давно умеющий писать прикладные инструменты, которыми пользуются миллионы. Криптографию он отдельно изучал в Стэнфорде, до этого получил магистратуру по финансам в Лондонской школе экономики.

С самим SimpleX вышла характерная история. В конце 2020-го Поберёзкин начал писать первый вариант сервера на Go, но язык категорически не зашёл (по его собственному рассказу, последней каплей стала неуклюжая работа со словарями в стандартной библиотеке). Тогда он сел изучать с нуля Haskell, несколько месяцев читал академические статьи и параллельно проектировал протокол, а затем за неделю собрал работающий сервер. Сегодня сервер и ядро всех клиентов — терминального, iOS, Android, десктопа — написаны именно на Haskell. Для прикладного мессенджера это очень редкий выбор. С компиляцией Haskell под мобильные платформы помог Мориц Ангерманн, один из ключевых разработчиков компилятора GHC. Позже к проекту подтянулись инвесторы (фонд Village Global и несколько ангелов) и небольшая команда контрибьюторов, но архитектурно SimpleX остаётся продуктом мысли одного человека.

У Поберёзкина есть личный блог, где он подробно пишет про Haskell, зависимые типы и архитектурные решения внутри SimpleX. Если хочется посмотреть, как рассуждает автор мессенджера без идентификаторов, лучше всего идти туда.

Что важнее самого приложения

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

Сначала прятали содержимое. Так появился PGP, потом сквозное шифрование в каждом приличном мессенджере. Потом начали думать про прямую секретность и восстановление после взлома, то есть про то, чтобы и в будущем нельзя было расшифровать прошлое и чтобы случайный взлом устройства не открывал двери в переписку навсегда. Потом про метаданные: что сервер вообще видит, кроме шифротекстов. Потом про сам факт регистрации в системе.

SimpleX доводит это движение до естественного предела. Он спрашивает: а что, если в системе вообще не будет понятия «пользователь»? Не будет никого, кого можно было бы отметить, заблокировать, выдать по запросу, продать рекламодателю или просто сосчитать. Будут только короткоживущие каналы доставки, попарные между конкретными устройствами.

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

И, пожалуй, лучшее в этой истории даже не то, что Поберёзкину удалось довести идею до работающего приложения с миллионами установок, а то, что он показал на практике: мессенджер без идентификаторов — это не маркетинговая фантазия, а вполне реализуемая инженерная конструкция. Эта идея уже не сможет «исчезнуть», даже если сам проект однажды закончится. Кто-нибудь её обязательно подхватит, и в следующий раз вопрос «а как ваш сервер узнаёт, что Алиса знакома с Бобом?» будет звучать странно.

Источники

Основные технические материалы:

Релизы и анонсы, использованные в тексте:

Про автора и историю разработки:

Сторонние материалы: