Продолжаем пет проект корп мессенджера1
Показываю итоги разработки. Сейчас к процессу присоединился знакомый Front-end разработчик. Устранили очень большое кол-во проблем в том числе с WS, кешем и прочим, так же убрали эмодзи и переложили их в рендер на JS. Можно было брать готовые референсы из интернета, но везде надо указывать авторов.
Теперь про дизайн / стиль и прочее.
Начнем с прочего и это будет бэк.
Сейчас проект насчитывает 15 основных сервисов и 4 сервиса инфраструктурных, плюс 3 сервиса мониторинга.
Сразу скажу, сервис транскрипции отключен не потому что не работает, а потому что в простое потребляет 200мб выделенных ресурсов. Если судить по описанию либы которую использую и модель - это нормально.
Принцип разработки был построен на максимальной изоляции сервисов друг от друга. Т.е. единственный сервис который имеет между собой какое-либо взаимодействие с другими это сообщения. Сообщения ходят в треды или топики что бы обновить числовые значения или отправить push о том что есть новое сообщение. Если будет интересно разобрать какой то сервис отдельно - напиши в коммент я опишу.
Выделили мы фронт в отдельную монорепу. Раньше весь проект был в одной общей репе.
Auth - сервис отвечающий за авторизацию, выдачу токенов, рефреш токена, создания пары новый / старый токен.
Chat - Отвечает за сами чаты, личные, канбан, серверы.
Cleanup - отдельный воркер который очищает старые данные, проверяет на актуальность
File - отвечает за хранение файлов, создание метаданных, проверка вложенности, проверка что pdf это именно pdf и ничего более, что бы не закинуть вирус. так же занимается шифрацией файлов.
Gateway - сервис шлюз, он отвечает за выдачу пропуска на каждый запрос. Проверяет роли через permission, проверяет что вложено, активный ли токен, кол-во запросов и тп.
Link - сервис гиперссылок. Вынес его отдельно, так как он подгружает информацию на фронт из ссылки и проверяет что внутри ссылки лежит.
Messages - сервис отвечающий за сообщения. Самый нагруженный сервис из всех. Его задача не только получить данные текста, сохранить и отдать. Но так же отвечает за пересылку сообщений между чатами, закрепления, уведомления, реакции на сообщения и тп. В идеальном формате перевести все уведомления в будущем на отдельный сервис. Но пока так
И куча других сервисов. Остановлюсь только на транскрипции. Это не прям сервис, это бот. Бот секретарь в голосовых встречах. При его включении он начинает слушать комнату, производит транскрипцию, собирает всю транскрипцию встречи в т.ч. с информацией какой участник говорил, собирает промт и отправляет в ЛС инициатору, инициатор выбирает что и где подправить, согласует и бот уходит в GigaChat с просьбой произвести перевод из каши на протокол встречи. Бот сейчас больше экспериментальный, на CPU работает тяжеловато, есть артефакты, на GPU работает супер. Понимает контекст голоса на 90% и транскрипт выводит +- хороший.
Отдельно про безопасность. Все данные которые отправляются на сервер имеют валидацию по различным форматам, синтаксис, sql инъекции, html тегирование и прочее. Под это дело зашит отдельный сервис в gateway + часть этого же зашита во все другие сервисы как доп проверка с более обширным функционалом. Средняя латентность ответа на докер десктоп в районе 40-70мс.
Теперь про дизайн и интерфейс.
Как зарождался вообще дизайн? (Мало кому интересно, но все же). Писал его опираясь на discord и mattermost формат. В начале делал отрисовку в Figma частично с набросками основных элементов, потом писал бэк, оборачивал все с один промт на AI, смотрел как получилось и если норм - оставлял, потом переделаю, если нет - переделывал сразу.
В целом, AI создал хорошую базу, но иногда встречаются недочеты в виде спагетти и ошибки в рамках что где-то что-то не учел. Сейчас мы перестаем им пользоваться в рамках разработки, но используем в рамках объяснения кода и связанности слоев.
Первоначально сообщения были в стилистике телеграмм, но я заметил что очень много пространства остается пустым и если я отправлю PlantUML диаграмму то она уходит в лево и отображается как будто визуально под другим пользователем.
На фотографии мы видим:
Название программы Mountain
Левая панель с выбором чатов, личные, канбан, сервера
Верхняя панель
Правая панель с ToDo и активными участниками чата
Если вы начали диалог в голосовой комнате, но решили перейти в другой чат ответить на сообщение, звонок не сброситься, перейдет в верхний трей и будет показано что сидите в эфире.
Поиск по сообщениям, ищет по буквам и ключевому слову. При клике перенаправит на сообщение и выделит его
Серверы, а не чаты названы потому что часть сервисов автоматически масштабируется для распределения нагрузки. Вообще идет 2 слоя от которых происходит масштабирования от кол-ва активных чатов и от потребления ОЗУ и ЦПУ. Уровни настроек чатов такой же как в ДС.
Вот треды это отдельная тема. Т.е. есть топики (темы) и внутри них как отдельный сервис есть треды. Треды не живут долго, 1 месяц, потом переходят в архив как и сообщения, достаются списки уже через пагинацию.
Значит что мы видим выше - это основные окна с которыми часто придется взаимодействовать пользователям. Стиль - можно менять, у меня выбран тот стиль который мне приятен глазу, да бордовый и ничего страшного. Все цвета сообщений, имена пользователей - подстраиваются под цвет бэкграунда.
Для личного не будет "ToDo, Kanban доски чатов, бот секретарь", но будет раздел "Друзья".
Да, стиль очень схож с дискорд. Считаю не страшно, в этом и была задумка, но это удобнее чем другие корпоративные мессенджеры (slack, mattermost) с пол сотней различных чатов и еще тысячей тредов которые вообще не понять как работают. Для меня смесь стиля discord и функционала mattermost с telegram - получаем что-то между и это более приятное решение. Да и зачем придумывать что-то новое, когда уже есть все, бери и адаптируй.
ToDo делал лично для себя. Но прижился в проекте. Мне удобно прям в момент встречи сделать сразу задачи себе и проставить даты. Это удобнее чем иметь множество различных приложений.
В процессе разработки выпилил интеграцию с такими сервисами как: Google meet, Jitsi и яндекс телемост. Причиной стало наличие своего сервиса для конференций.
Написал много, очень размазано. Что писать - честно говоря не знаю, проще отвечать на вопросы. Так же зреет адаптация под мобилки.
Над чем сейчас ведется работа:
Улучшение шумодава и передачи звука, вынос настроек со звуком в отдельное меню
Паки эмодзи, они есть везде и не надо отставать, но не в приоритете
Адаптация под мобильное устройство
Вынос в отдельные app для личного и для компании.
Оптимизация при работе со сжатыми файлами без потери качества и сжатие добиваться больше чем через обычный архив
Добавление видео передачи с камеры при общих созвонах
SSO авторизация
Unit тесты. Делать будут онли через ИИ, ему проще скормить сервис и что бы он написал тест.
Про будущее говорить очень рано, продукт сырой, признаю это как есть. Нам бы доделать то что имеем, написать тех доку и попробовать зайти в компанию к знакомым для запуска первого релиза внутри их штата.
Пытался я вынести проект на тестирование, и один знакомый выделил мне сервер на 2U. Однако я столкнулся с проблемой: настраивать сеть я не умею. Запустить проект на Ubuntu удалось, но я не понял, как сделать его доступным для других. Нагружать знакомого уже не мог — он и так бесплатно дал мне сервер. Поэтому пока отложил тестирование и рассматриваю аренду виртуальной машины.
















Правовые и технические аспекты запуска мессенджера в Российской Федерации: комплексное руководство по обеспечению комплаенса в условиях регуляторных изменений
В условиях стремительной трансформации цифрового ландшафта Российской Федерации запуск собственного мессенджера представляет собой сложную многоуровневую задачу, выходящую далеко за рамки написания качественного программного кода и разработки интуитивно понятного интерфейса. Для предпринимателя, находящегося на стадии перехода от готового прототипа к коммерческой эксплуатации сервиса, ключевым вызовом становится соблюдение жестких требований национального законодательства в области связи, информационной безопасности и защиты персональных данных. Регуляторная среда 2024–2025 годов характеризуется переходом к модели «цифрового суверенитета», что накладывает на владельца мессенджера обязательства по локализации данных, идентификации пользователей и глубокой интеграции с государственными системами мониторинга.
Управление персональными данными: локализация и новые требования 152-ФЗ
С момента регистрации ООО и запуска сервиса владелец мессенджера становится оператором персональных данных (ПДн). В 2025 году законодательство в этой сфере существенно ужесточилось, вводя новые механизмы контроля за тем, как данные российских граждан собираются и хранятся.
Архитектурные требования к локализации данных
Фундаментальным требованием Федерального закона № 152-ФЗ является локализация баз данных. С 1 сентября 2025 года согласно нормам 233-ФЗ данные российских пользователей должны физически располагаться на серверах, находящихся на территории Российской Федерации. Любая выгрузка обезличенных данных по запросу регуляторов должна осуществляться по строго определенным протоколам. Нарушение требований к локализации влечет за собой риск наложения штрафов в размере до 6 млн рублей для юридических лиц.
Трансформация интерфейса согласий
С 1 сентября 2025 года требования к получению согласия пользователя на обработку данных становятся более детализированными. Теперь согласие не может быть «спрятано» внутри общего пользовательского соглашения; оно должно быть явным и отдельным. Владельцу мессенджера необходимо предусмотреть в интерфейсе приложения и сайта отдельные чекбоксы для:
Обработки основных персональных данных.
Передачи данных третьим лицам (если это предусмотрено функционалом).
Использования данных в маркетинговых целях.
Процедура уведомления Роскомнадзора
До начала фактической деятельности по обработке данных компания обязана направить уведомление в Роскомнадзор по форме, утвержденной Приказом № 180 от 28.10.2022. В уведомлении необходимо максимально конкретно указать цели обработки (например, «обеспечение функционирования сервиса мгновенного обмена сообщениями»), категории данных и субъектов, а также правовые основания для каждого действия.
Важно помнить, что датой начала обработки в уведомлении следует указывать день фактического начала работы с данными (например, день приема первого сотрудника или регистрации первого пользователя), а не день подачи самого документа.
Статус организатора распространения информации (ОРИ) и «Закон Яровой»
Мессенджеры в российской юрисдикции классифицируются как Организаторы распространения информации (ОРИ). Этот статус накладывает на владельца сервиса ряд специфических обязанностей, направленных на обеспечение национальной безопасности и возможности проведения оперативно-розыскных мероприятий.
Регистрация в реестре ОРИ и хранение метаданных
После запуска мессенджера Роскомнадзор может направить требование о включении в реестр ОРИ, либо владелец может сделать это инициативно. Согласно нормам Федерального закона № 374-ФЗ (известного как «Закон Яровой»), ОРИ обязан хранить на территории РФ:
Сведения о фактах приема, передачи, доставки и обработки сообщений, аудио- и видеозвонков (метаданные) — в течение 3 лет.
Содержание самих сообщений, включая текст, голос, изображения и видеофайлы — в течение 6 месяцев.
Организатор также обязан предоставлять ключи для декодирования сообщений по запросу уполномоченных органов (ФСБ), если в мессенджере используется дополнительное шифрование (например, сквозное шифрование E2EE).
Система оперативно-розыскных мероприятий (СОРМ-3)
Техническое исполнение обязанностей ОРИ осуществляется через внедрение СОРМ. Для мессенджера актуальным является стандарт СОРМ-3, который обеспечивает комплексный контроль за интернет-коммуникациями. Процесс внедрения СОРМ является одним из самых сложных и дорогостоящих этапов запуска проекта.
Для небольших проектов существуют решения по аренде мощностей СОРМ у специализированных провайдеров, что позволяет избежать огромных разовых затрат на покупку собственного оборудования. Стоимость аренды санкционированного канала может составлять около 305 000 рублей в месяц при стоимости инсталляционных работ порядка 250 000 рублей.
Новая парадигма идентификации пользователей: 303-ФЗ и 41-ФЗ
2025 год становится переломным в вопросе анонимности цифровых коммуникаций. Владелец мессенджера больше не может позволить пользователям регистрироваться без подтверждения личности через верифицированные каналы связи.
Верификация по номеру телефона и лимиты на SIM-карты
С 1 апреля 2025 года согласно 303-ФЗ вводится обязательная идентификация всех абонентов. Для мессенджера это означает необходимость интеграции с базами данных операторов связи для проверки принадлежности номера конкретному лицу. Важным ограничением является установленный лимит: на одного гражданина РФ может быть зарегистрировано не более 20 мобильных номеров (включая виртуальные и корпоративные). Оператор мессенджера обязан прекратить оказание услуг пользователю, если данные о его номере не прошли проверку на достоверность.
Запрет на использование иностранных мессенджеров (41-ФЗ)
С 1 июня 2025 года вступает в силу запрет на передачу конфиденциальной информации через иностранные сервисы (такие как WhatsApp или Telegram) для широкого круга организаций. Под запрет попадает передача:
Персональных данных граждан.
Платежных документов и чеков.
Договоров и финансовой отчетности.
Этот запрет распространяется на госкомпании, банки, участников национальной платежной системы, а также на популярные сайты и агрегаторы с суточной аудиторией более 100 тыс. человек. Для разработчика нового российского мессенджера это открывает уникальную рыночную нишу: корпоративный сектор будет остро нуждаться в отечественных альтернативах, включенных в реестр российского ПО, для обеспечения легальной коммуникации с клиентами и сотрудниками.
Лицензирование криптографии и нотификация ФСБ
Вопрос использования шифрования в мессенджере является критическим с точки зрения лицензионного контроля. В Российской Федерации деятельность по разработке и распространению криптографических (шифровальных) средств регулируется Постановлением Правительства № 313.
Разграничение лицензии и нотификации
Для владельца стартапа важно понимать разницу между лицензией на деятельность и нотификацией на продукт. Если шифрование используется исключительно для защиты собственных каналов связи мессенджера с использованием стандартных библиотек (например, OpenSSL) и не передается третьим лицам как отдельный функционал, лицензия ФСБ на разработку может не потребоваться.
Однако для легального оборота и ввоза/вывоза ПО, содержащего криптографические алгоритмы, необходима нотификация ФСБ. Этот документ подтверждает характеристики шифрования и регистрируется в реестре Евразийской экономической комиссии (ЕЭК). Срок оформления нотификации составляет от 7 до 30 рабочих дней, госпошлина за процедуру не взимается.
Требования к получению лицензии на криптографию
Если же компания планирует разрабатывать собственные криптографические модули или оказывать услуги по шифрованию для других организаций, ей необходимо получить лицензию ФСБ. Это требует:
Наличия в штате минимум двух специалистов (руководителя и инженера) с профильным образованием в сфере ИБ и стажем работы в лицензированных компаниях от 3 лет.
Организации аттестованного рабочего места с установленными СЗИ и антивирусами.
Прохождения проверки на соответствие требованиям информационной безопасности, что занимает от 3 месяцев.
Реестр отечественного ПО: путь к масштабированию
Включение мессенджера в Реестр российского программного обеспечения является необходимым шагом для участия в госзакупках и получения налоговых льгот.
Условия включения в 2025 году
С 31 июля 2025 года согласно закону 325-ФЗ вводятся новые требования к разработчикам ПО. Чтобы продукт был признан российским, необходимо соблюдение следующих условий:
Исключительные права на мессенджер должны принадлежать российскому лицу (гражданину РФ или ООО, контролируемому российскими лицами).
Выплаты в пользу иностранных правообладателей (за лицензии, компоненты и т.д.) не должны превышать 30% от выручки проекта.
На сайте продукта должны быть размещены инструкции по установке и эксплуатации, а также описание функциональных характеристик.
Процесс регистрации состоит из 12 шагов через портал ГИС «Реестр российского ПО». Предварительная проверка занимает до 5 рабочих дней, экспертная оценка — до 30 рабочих дней, после чего Минцифры принимает финальное решение.
Операционная деятельность и маркировка коммуникаций
С сентября 2025 года вводится требование по обязательной маркировке звонков и сообщений для бизнеса. Это означает, что при получении сообщения от компании через мессенджер пользователь должен видеть верифицированное наименование отправителя. Владелец мессенджера должен предусмотреть техническую возможность передачи метаданных о категории вызова и идентификаторе юридического лица оператору связи.
Заключение и стратегический прогноз
Запуск мессенджера в России сегодня — это не только технологическое предпринимательство, но и глубокая работа в области юридического комплаенса. Основные сложности связаны с необходимостью значительных инвестиций в системы хранения данных и обеспечения безопасности (СОРМ), что может стать барьером для мелких игроков. Однако введение запрета на использование иностранных мессенджеров для бизнеса и государственных структур создает колоссальный спрос на защищенные, юридически «чистые» отечественные платформы.
Ключевым фактором долгосрочного успеха станет скорость адаптации к новым требованиям 2025 года, особенно в части идентификации по 303-ФЗ и маркировки сообщений. Владельцу мессенджера необходимо выстраивать прозрачные отношения с регуляторами (Роскомнадзор, ФСБ, Минцифры) и постоянно отслеживать изменения в реестрах, чтобы сохранять статус льготной ИТ-компании и доверие корпоративных пользователей. Процесс запуска, начатый с правильной юридической структуры и соблюдения норм локализации, обеспечит проекту устойчивость к проверкам и создаст фундамент для масштабирования на национальном уровне.
Источники:
https://kontur.ru/elba/spravka/79556-nalogooblozhenie_it_kom...
https://dv-consulting.ru/registratsiya-it-kompanii/
https://dsgners.ru/vagabond-agency/11788-polnyiy-gayd-po-per...
https://www.buhgalteria.ru/article/kak-sostavit-i-napravit-v...
https://www.1cbit.kz/blog/novaya-forma-uvedomleniya-ob-obrab...
https://www.klerk.ru/blogs/fedresurs/673677/
https://www.lanbilling.ru/blog/sorm/podgotovka-k-sdache-sorm...
... и множество других
Для чего я это выложил: показать что написать собственный мессенджер в 2026 это только малая часть того с чем придётся столкнуться и скорее всего самая простая.