Мессенджер Ласточка. Мы в Rustore. Cобственный DSL и федеративная архитектура

Путь от идеи до работающего мессенджера с открытым кодом — в последнем отчёте.

Я начал рассказывать о проекте «Ласточка» на Хабре чуть больше двух месяцев назад. Тогда это были вопросы нужен ли еще один мессенджер, которые переросли в твёрдое намерение построить честный российский мессенджер для обычной жизни — семьи, друзей, работы.

Регистрация в Rustore

Через некоторое время после публикации предпоследней статьи я получил вот такое письмо

И после нескольких модераций приложение одобрили и разместили в Rustore. Поэтому выражаю Хабру и всем коллегам по Хабру огромную признательность.

Текущий статус: 300 пользователей в списке ожидания

На момент написания статьи в списке ожидания (waitlist) зарегистрировано около 300 человек. Доступ даем ограниченному числу, чтобы не разочаровать в продукте и закрыть все нелепые баги до открытия проекта. Темп роста — органический, без рекламы: люди приходят с Хабра, из TG-канала, по рекомендациям. Мы сознательно не форсируем аудиторию.

Что работает сейчас:

• Регистрация по номеру телефона через wait call (обратный звонок) и SMS (запасной).

• Веб-клиент на React: личные чаты, групповые чаты. Поиск по пользователям, отправка файлов, базовые уведомления.

• Android-приложение Уже можно переписываться, создавать группы, редактировать сообщения.

• Desktop-клиент (Electron) собирается, но пока не выложен — ждём окончания тестов на Windows.

DSL «Ласточка Rules»: скрипты для чатов без программирования

Мы долго думали, как дать обычным пользователям возможность создавать простые автоматизации, не заставляя их писать код на Python. Модель «каждый бот — отдельный пользователь» с Bot API и SDK — это для разработчиков. А базовая потребность выглядит иначе: администратор группы хочет, чтобы бот отвечал на часто задаваемые вопросы, приветствовал новичков или пересылал сообщения по ключевым словам. Без серверов, деплоя и Docker.

Так родилась концепция «Ласточка Rules» — минималистичного DSL (Domain-Specific Language), который пишется прямо в интерфейсе управления группой. Это не язык общего назначения, а набор правил вида «если условие — то действие».

Примеры правил

Приветствие нового участника:

when user joined  send "Привет, {{user.name}}! Правила чата: https://..."

Ответ на частый вопрос:

when message contains "прайс"  send file "price_2026.pdf"

Защита от спама (дополнение к автоматической модерации):

when message matches "купить.*дешево|заработок.*день"  delete message  notify admin "Подозрение на спам от {{user.name}}"

Как это работает под капотом

Синтаксис парсится в абстрактное дерево (AST) прямо на сервере, никакого доступа к глобальным функциям нет: DSL может только читать содержимое входящего сообщения, проверять простые регулярки и вызывать ограниченный набор действий (отправить текст, отправить файл, удалить сообщение, уведомить администратора). Безопасность гарантируется тем, что правила исполняются на стороне сервера и не имеют доступа к внутренним API.

Храниться правила будут в PostgreSQL рядом с метаданными группы. Редактировать их сможет владелец группы через стандартный UI — без кода, просто заполняя поля «Если» и «То». Для продвинутых пользователей оставим raw-режим с подсветкой синтаксиса.

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

Федеративная архитектура: свой сервер без потери связи с миром

Вторая крупная тема, которую мы прорабатываем — как дать любым организациям возможность устанавливать собственную ноду мессенджера, но при этом не терять связь с внешними контактами. Федерация в Tinode устроена не так, как в Matrix или XMPP. Здесь нет репликации данных и общей шины. Вместо этого используется механика прокси-пользователей.

Когда компания «Ромашка» запускает свою ноду, её сотрудники создаются и хранятся локально. Центральная нода «Ласточки» узнаёт о них через защищённый федеративный обмен и создаёт у себя временные прокси-записи. Сообщения между нодами передаются по стандартному WebSocket-протоколу Tinode с обязательным TLS, но не сохраняются на центральной стороне — только транзитом. Постоянные данные остаются на той ноде, к которой относится пользователь.

Это даёт важное юридическое следствие: персональные данные сотрудников не покидают контур компании. Федеративная нода сама выступает оператором ПДн, а центральная обрабатывает лишь обезличенный прокси-идентификатор.

Юридическая сторона по федеративной архитектуре пока в проработке с юристами и соответствующими ведомствами.

Пока получается три сценария

Мы выделили три сегмента, и под каждый — свой продукт:

1. «Ласточка» (B2C) — бесплатно, центральная нода. Для обычных пользователей и малого бизнеса/ИП, которым не нужен контроль над инфраструктурой.

2. «Ласточка Сервер Лайт» — для средних организаций (100–1000 сотрудников). Своя нода в облаке (VDS от Selectel или VK Cloud), установка через один Docker Compose, федерация с центральной нодой.

3. «Ласточка Сервер Про» — для крупных организаций (1000+). Своё железо или частное облако, полный набор интеграций (LDAP, SSO, SIEM, DLP), контракт с SLA 24/7.

Что дальше

Стратегия сформулирована, идеология не меняется. Дальше — рутина:

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

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

P.S. Мы открыты для идей, конструктивной критики, любой помощи и участия в проекте.