Путь от идеи до работающего мессенджера с открытым кодом — в последнем отчёте. Дальше — рутина, развитие и поддержка.
Я начал рассказывать о проекте «Ласточка» на Хабре чуть больше двух месяцев назад. Тогда это были вопросы нужен ли еще один мессенджер, которые переросли в твёрдое намерение построить честный российский мессенджер для обычной жизни — семьи, друзей, работы.
Короткий пост про текущий статус по развитию мессенджера.
Последние два месяца мы занимались бумажной работой. Той самой, которую стартапы обычно откладывают до последнего, а потом делают в пожарном режиме. Мы решили пойти иначе: сначала закрыть все юридические вопросы, потом запускать пользователей. В итоге получили официальный ответ Роскомнадзора, подали уведомление об обработке персональных данных, открыли whitelist-доступ для первых тестеров. Обо всём по порядку.
Каждый, кто хоть раз искал работу в IT за последние пару лет, знает это чувство. Ты рассылаешь резюме, проходишь пять этапов собеседований, решаешь алгоритмические задачи, пишешь тестовые — и в конце получаешь шаблонное «мы остановились на другом кандидате». Без объяснений. Без обратной связи. Без малейшего намёка на то, что именно пошло не так.
Я работаю в IT больше десяти лет. Проходил собеседования с обеих сторон стола — и как кандидат, и как нанимающий. И чем дольше я в профессии, тем очевиднее становится мысль: найм сломан. Не «работает не идеально» — а именно сломан. Системно, фундаментально, на уровне базовых механизмов.
Календарь, задачи, заметки, почта. Мы используем десятки инструментов, но они не умеют жить вместе. Данные размазаны по сервисам. Команда в Битрикс24, семья в WhatsApp, клуб в Google Calendar. Везде свой интерфейс, свои правила, своя изоляция.
"Я выложил библиотеку на GitHub в четверг. В пятницу её клонировал AI-агент, а в субботу конкурент запустил идентичный SaaS." Такое будущее если еще и не наступило, но уже возможно очень скоро. Мы вошли в эру «вайб-кодинга», где софт пишется по наитию промптами, а скорость копирования превысила скорость осмысления. Встаёт неудобный вопрос: если вас могут повторить за сутки, стоит ли вообще публиковать код и пытаться строить продукт?
Центральная идея: одно ядро, runtime-профили
Проблема, которую решает OptimaOS — фрагментация через форкинг. Android — форк Linux. Embedded-дистрибутивы — форки с кастомными патчами под каждый SoC. AI-стеки — отдельные кодовые базы. Каждый форк — это отдельный security-аудит, отдельная команда и свой накапливающийся регресс.
AI-агенты в 2025 году умеют почти всё. Одного хорошо не умеют — помнить. Я взял две чужие идеи и склеил их.
Представьте, что ваш мессенджер — это не одно приложение, привязанное к серверу в чужой стране, а персональный «цифровой контейнер», который вы можете парковать у любого провайдера или на своей машине. При смене «парковки» ваши контакты, история и подписки переезжают вместе с вами без потери связи, а каждое публичное сообщение получает математическое доказательство авторства, которое не под силу оспорить даже суду. В этой статье разберем идеологию, сетевой протокол и контуры применения архитектуры, которая может стать фундаментом для следующего поколения устойчивых к цензуре и фейкам коммуникаций.
Несколько недель назад я описал на Хабре идею «честного российского мессенджера» с открытым кодом и прозрачным compliance. Та статья была про «зачем». Эта — про «как получилось». Web-клиент и Android-приложение полностью переписаны и работают в production, серверная часть развёрнута и обслуживает реальные подключения. iOS пока не трогали. Ниже — разбор архитектуры, решения, которые мы приняли, грабли, на которые наступили, и открытый набор людей в проект.
Telegram практически заблокирован. Max — официальный, удобный, но его не хотят ставить даже те, кто в курсе, что именно VK-экосистема уже хранит половину их цифровой жизни. В этом зазоре появляется вопрос: а нужен ли вообще «свой» мессенджер, и если да — каким он должен быть? Я попробовал ответить не словами, а кодом.
В 2026 году написать операционную систему с нуля — это либо академическое упражнение, либо попытка решить реальную проблему. OptimaOS — второе: проект исследует, можно ли построить одно ядро, которое без форкинга и переписывания обслуживало бы десктоп, сервер, Edge и AI-устройство одновременно. В этой статье — мотивация, архитектурные решения и статус проекта.
Когда очередной лендинг требует «просто принимать заявки и показывать новости», разработчик оказывается перед выбором: поднять Laravel/Django с кучей зависимостей, купить SaaS-подписку, или написать что-то своё. Я выбрал третий путь — и это оказалось интереснее, чем я ожидал.
В этой статье разбираю архитектурные решения, которые принял при написании LightHeadless — минималистичного headless CMS на Go.
Весь современный веб спроектирован для одного типа клиента — человека с браузером. Но когда клиентом становится AI-агент, оказывается, что большинство привычных решений работают неправильно или не работают вообще. В этой статье — разбор архитектурных проблем, которые возникают при проектировании инфраструктуры для Agent-to-Agent (A2A) взаимодействия: адресация, маршрутизация, доверие и поиск.