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

Архитектурные требования к локализации данных

Фундаментальным требованием Федерального закона № 152-ФЗ является локализация баз данных. С 1 сентября 2025 года согласно нормам 233-ФЗ данные российских пользователей должны физически располагаться на серверах, находящихся на территории Российской Федерации. Любая выгрузка обезличенных данных по запросу регуляторов должна осуществляться по строго определенным протоколам. Нарушение требований к локализации влечет за собой риск наложения штрафов в размере до 6 млн рублей для юридических лиц.

Трансформация интерфейса согласий

С 1 сентября 2025 года требования к получению согласия пользователя на обработку данных становятся более детализированными. Теперь согласие не может быть «спрятано» внутри общего пользовательского соглашения; оно должно быть явным и отдельным. Владельцу мессенджера необходимо предусмотреть в интерфейсе приложения и сайта отдельные чекбоксы для:

1. Обработки основных персональных данных.

2. Передачи данных третьим лицам (если это предусмотрено функционалом).

3. Использования данных в маркетинговых целях.

Процедура уведомления Роскомнадзора

До начала фактической деятельности по обработке данных компания обязана направить уведомление в Роскомнадзор по форме, утвержденной Приказом № 180 от 28.10.2022. В уведомлении необходимо максимально конкретно указать цели обработки (например, «обеспечение функционирования сервиса мгновенного обмена сообщениями»), категории данных и субъектов, а также правовые основания для каждого действия.

Важно помнить, что датой начала обработки в уведомлении следует указывать день фактического начала работы с данными (например, день приема первого сотрудника или регистрации первого пользователя), а не день подачи самого документа.

Статус организатора распространения информации (ОРИ) и «Закон Яровой»

Мессенджеры в российской юрисдикции классифицируются как Организаторы распространения информации (ОРИ). Этот статус накладывает на владельца сервиса ряд специфических обязанностей, направленных на обеспечение национальной безопасности и возможности проведения оперативно-розыскных мероприятий.

Регистрация в реестре ОРИ и хранение метаданных

После запуска мессенджера Роскомнадзор может направить требование о включении в реестр ОРИ, либо владелец может сделать это инициативно. Согласно нормам Федерального закона № 374-ФЗ (известного как «Закон Яровой»), ОРИ обязан хранить на территории РФ:

1. Сведения о фактах приема, передачи, доставки и обработки сообщений, аудио- и видеозвонков (метаданные) — в течение 3 лет.

2. Содержание самих сообщений, включая текст, голос, изображения и видеофайлы — в течение 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-ФЗ вводятся новые требования к разработчикам ПО. Чтобы продукт был признан российским, необходимо соблюдение следующих условий:

1. Исключительные права на мессенджер должны принадлежать российскому лицу (гражданину РФ или ООО, контролируемому российскими лицами).

2. Выплаты в пользу иностранных правообладателей (за лицензии, компоненты и т.д.) не должны превышать 30% от выручки проекта.

3. На сайте продукта должны быть размещены инструкции по установке и эксплуатации, а также описание функциональных характеристик.

Процесс регистрации состоит из 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 это только малая часть того с чем придётся столкнуться и скорее всего самая простая.

Сразу скажу, сервис транскрипции отключен не потому что не работает, а потому что в простое потребляет 200мб выделенных ресурсов. Если судить по описанию либы которую использую и модель - это нормально.

Принцип разработки был построен на максимальной изоляции сервисов друг от друга. Т.е. единственный сервис который имеет между собой какое-либо взаимодействие с другими это сообщения. Сообщения ходят в треды или топики что бы обновить числовые значения или отправить push о том что есть новое сообщение. Если будет интересно разобрать какой то сервис отдельно - напиши в коммент я опишу.

Выделили мы фронт в отдельную монорепу. Раньше весь проект был в одной общей репе.

1. Auth - сервис отвечающий за авторизацию, выдачу токенов, рефреш токена, создания пары новый / старый токен.

2. Chat - Отвечает за сами чаты, личные, канбан, серверы.

3. Cleanup - отдельный воркер который очищает старые данные, проверяет на актуальность

4. File - отвечает за хранение файлов, создание метаданных, проверка вложенности, проверка что pdf это именно pdf и ничего более, что бы не закинуть вирус. так же занимается шифрацией файлов.

5. Gateway - сервис шлюз, он отвечает за выдачу пропуска на каждый запрос. Проверяет роли через permission, проверяет что вложено, активный ли токен, кол-во запросов и тп.

6. Link - сервис гиперссылок. Вынес его отдельно, так как он подгружает информацию на фронт из ссылки и проверяет что внутри ссылки лежит.

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

8. И куча других сервисов. Остановлюсь только на транскрипции. Это не прям сервис, это бот. Бот секретарь в голосовых встречах. При его включении он начинает слушать комнату, производит транскрипцию, собирает всю транскрипцию встречи в т.ч. с информацией какой участник говорил, собирает промт и отправляет в ЛС инициатору, инициатор выбирает что и где подправить, согласует и бот уходит в 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 и яндекс телемост. Причиной стало наличие своего сервиса для конференций.

Написал много, очень размазано. Что писать - честно говоря не знаю, проще отвечать на вопросы. Так же зреет адаптация под мобилки.

Над чем сейчас ведется работа:

1. Улучшение шумодава и передачи звука, вынос настроек со звуком в отдельное меню

2. Паки эмодзи, они есть везде и не надо отставать, но не в приоритете

3. Адаптация под мобильное устройство

4. Вынос в отдельные app для личного и для компании.

5. Оптимизация при работе со сжатыми файлами без потери качества и сжатие добиваться больше чем через обычный архив

6. Добавление видео передачи с камеры при общих созвонах

7. SSO авторизация

8. Unit тесты. Делать будут онли через ИИ, ему проще скормить сервис и что бы он написал тест.
   

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

Пытался я вынести проект на тестирование, и один знакомый выделил мне сервер на 2U. Однако я столкнулся с проблемой: настраивать сеть я не умею. Запустить проект на Ubuntu удалось, но я не понял, как сделать его доступным для других. Нагружать знакомого уже не мог — он и так бесплатно дал мне сервер. Поэтому пока отложил тестирование и рассматриваю аренду виртуальной машины.