Путь от идеи до работающего мессенджера с открытым кодом — в последнем отчёте.
Я начал рассказывать о проекте «Ласточка» на Хабре чуть больше двух месяцев назад. Тогда это были вопросы нужен ли еще один мессенджер, которые переросли в твёрдое намерение построить честный российский мессенджер для обычной жизни — семьи, друзей, работы.
Регистрация в 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. Мы открыты для идей, конструктивной критики, любой помощи и участия в проекте.
