Корпоративный мессенджер обычно работает внутри управляемого контура: ИТ управляет доступом, информационная безопасность — политиками и потоками данных. Но проектные команды редко совпадают с юридическими границами компании. Сотрудникам нужно постоянно общаться с подрядчиками, партнерами и коллегами из дочерних обществ — и желательно не переносить рабочий контекст в публичные сервисы.

В ноябре 2025 года мы выпустили федерацию VK WorkSpace для двух On-Premise-инсталляций. В релизе 26.2, вышедшем в июле 2026 года, сняли ограничение на парное взаимодействие: теперь в одном чате могут работать участники из нескольких независимых контуров. В статье разберем, как устроена модель доверия, почему мы выбрали репликацию данных на стороне каждой организации, что пришлось изменить в клиентских приложениях и какие ограничения у решения остаются.

Меня зовут Андрей Ковайкин, я старший менеджер продукта направления Мессенджер в команде VK WorkSpace. Мы развиваем единый контур корпоративных коммуникаций, а федерация решает его внешний сценарий: позволяет организациям общаться между собой, не объединяя инфраструктуру, администрирование и политики безопасности.

Что такое федерация и как устроен доступ

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

Доступ строится на двух уровнях:

1. Траст между инсталляциями. Одна сторона отправляет приглашение, вторая подтверждает связь.

2. Допуск пользователей. Администратор каждой стороны определяет сотрудников, которым разрешена внешняя коммуникация в рамках конкретного траста.

Одна инсталляция может установить отдельные трасты с несколькими дочерними обществами, подрядчиками и партнерами. Права выдаются для каждого такого отношения отдельно.

Только допущенные пользователи видят разрешенных сотрудников другой организации, могут начинать с ними диалоги и участвовать в групповых чатах. Полный корпоративный справочник между инсталляциями не реплицируется: в текущей реализации передается минимально необходимая карточка внешнего пользователя — ФИО, рабочий email и признак другой организации.

Такая модель дает каждой компании два независимых рычага контроля: с какими организациями устанавливать доверие и каким сотрудникам разрешать внешнюю коммуникацию. Траст или персональный допуск можно отозвать; уже полученная история при этом остается в локальном контуре.

Федерация, мультидоменность и гостевой доступ решают разные задачи:

Какую архитектуру выбрать

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

Первый — хранить сообщения и файлы только в одной, «хостовой» инсталляции, а пользователям остальных контуров давать к ним доступ через прокси. Схема экономит место, но создает зависимость от владельца данных: при разрыве траста или недоступности хостовой стороны остальные участники теряют доступ к истории. Для архитектуры Мессенджера VK WorkSpace такой вариант также потребовал бы сложной модели удаленного доступа.

Второй — внедрить открытый федеративный протокол, например Matrix. В Matrix события комнаты реплицируются между homeserver-ами, пользователи которых участвуют в этой комнате, через Server-Server API; единого сервера-владельца у комнаты нет. Открытая спецификация упрощает межвендорную совместимость, но для зрелой платформы означает необходимость сопоставить существующие сущности, права, политики и API с другой моделью данных. Для VK WorkSpace это потребовало бы глубокой переработки мессенджера и миграции уже работающих сценариев.

Справочно: официальная спецификация Matrix

Третий — реплицировать федеративные сущности на прикладном уровне. В каждом контуре внешний пользователь и общий чат получают локальное представление. Когда пользователь создает чат, добавляет участника или отправляет сообщение, федеративный слой перехватывает операцию и воспроизводит ее в других доверенных инсталляциях. В результате сообщения, файлы и настройки конкретного федеративного чата существуют в каждом участвующем контуре.

Речь не о копировании всей базы данных или корпоративного справочника, а только о репликации объектов и событий, относящихся к разрешенным федеративным чатам.

Почему мы выбрали локальную репликацию

• Данные остаются у обеих организаций. Каждая сторона хранит локальную копию доступной ей истории переписки и файлов; разрыв траста не удаляет уже полученные данные.

• Свой контур — свои политики. Каждая компания применяет к локальной копии собственные правила DLP, аудита, хранения и резервного копирования; контроль не делегируется партнеру.

• Нет пользовательской сессии в чужом контуре. Клиент внешнего сотрудника работает со своей инсталляцией, а между доверенными федеративными сервисами передаются разрешенные сообщения, файлы и события.

• Справочник не реплицируется целиком. Разрешенным сотрудникам доступна только карточка внешнего пользователя, необходимая для коммуникации.

• Управляемый доступ. Администратор выдает и отзывает права на внешнюю коммуникацию отдельно для каждого траста и пользователя.

• Локальная доступность истории. При временной недоступности партнерской инсталляции уже синхронизированная переписка остается доступной; обмен новыми событиями зависит от доступности федеративного канала.

Для разработки важным преимуществом стала изоляция федеративного слоя от ядра мессенджера. Основная бизнес-логика продолжает выполняться внутри Мессенджера VK WorkSpace, а отдельный модуль отвечает за обнаружение федеративных операций, их передачу и обогащение ответов. Это уменьшает объем изменений в ядре, хотя каждый новый пользовательский сценарий все равно требует проверки совместимости с федерацией.

Протокол федеративного взаимодействия мы реализовали самостоятельно и адаптировали к модели данных и релизному циклу VK WorkSpace. Собственный протокол не является преимуществом сам по себе: вместе с контролем над развитием мы берем на себя поддержку совместимости версий и не получаем автоматической совместимости с другими мессенджерами. Для нашей существующей архитектуры такой компромисс оказался приемлемым.

От первого релиза к нескольким контурам

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

После установления связи допущенные сотрудники видят внешних пользователей в интерфейсе Супераппа VK WorkSpace. Возможности федеративного режима расширялись поэтапно.

В пилотной версии, выпущенной в ноябре 2025 года, можно было:

• искать разрешенных внешних пользователей;

• создавать с ними диалоги, групповые чаты и каналы;

• отправлять, удалять, редактировать и пересылать сообщения.

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

Что добавили после пилота

После пилота мы последовательно сокращали разницу между обычными и федеративными чатами.

В следующих релизах мы:

• синхронизировали аватары групповых чатов и каналов;

• поддержали доступные федеративные публичные чаты и поиск по ним;

• синхронизировали настройки чатов;

• добавили передачу прав администратора;

• синхронизировали треды, закрепленные сообщения, реакции, стикеры и файлы.

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

Главным архитектурным ограничением первой версии оставалась связь только двух инсталляций. Для пары компаний-партнеров этого достаточно, но, например, холдингам с отдельными контурами разных юридических лиц или геораспределенной организации нужны многоконтурные чаты.

В июле 2026 года, в релизе 26.2, мы сняли ограничение на парное взаимодействие. Теперь один групповой чат может объединять пользователей из нескольких независимых On-Premise-контуров. Логика доступа не изменилась: каждая инсталляция самостоятельно определяет свои трасты и список сотрудников с правом внешней коммуникации.

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

Как обмен работает «под капотом»

Клиентские приложения не подключаются напрямую к чужой инсталляции. Весь обмен проходит через собственный мессенджер и федеративный слой.

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

1. Клиент отправляет запрос в свою инсталляцию обычным способом; ядро мессенджера выполняет локальную операцию.

2. Промежуточный сервис определяет, что пользователь или чат относится к федерации, подготавливает операцию и через федеративный шлюз передает ее во все задействованные доверенные инсталляции.

3. На принимающей стороне федеративный слой проверяет связь с трастом и выполняет операцию через локальный API мессенджера от имени локального представления внешнего пользователя.

4. В каждой инсталляции сохраняется собственная копия сообщения, файла или события чата.

Упрощенная схема обмена:

Поскольку основная бизнес-логика выполняется внутри мессенджера, федеративный слой не дублирует ее полностью. Но формулировка «любая новая функция заработает из коробки» была бы слишком сильной: каждую новую операцию и изменение API необходимо отдельно проверять в многоконтурном сценарии.

На раннем этапе мы подняли два независимых стенда, разделили между ними часть команды и несколько месяцев работали через федерацию. Такой dogfooding помог обнаружить неочевидные технические сценарии и доработать UX/UI на основе реального использования, а не только тест-кейсов.

Сейчас федерация работает не только на внутренних стендах: ряд заказчиков использует ее в продуктивных On-Premise-инсталляциях.

Узнайте больше о возможностях Мессенджера VK WorkSpace

Объединяйте сотрудников из разных подразделений и организаций в одном пространстве, сохраняя защищенность и автономность инфраструктуры

Узнать

Что оказалось сложнее всего

Основные сложности возникли не только в транспортном протоколе, но и в модели возможностей и пользовательском интерфейсе зрелого многоплатформенного продукта.

1. Не показывать действие, которое все равно не сработает

Изначально мы планировали сообщать о недоступности функции уже после действия пользователя — например, при попытке позвонить внешнему сотруднику. Dogfooding показал, что такой интерфейс создает лишние ошибки. Поэтому перешли к модели возможностей: клиент заранее определяет тип пользователя или чата и скрывает неподдерживаемые действия.

Для этого потребовалось добавить признак федеративности в ответы нескольких API-методов и найти все места, где клиенты и сервисы получают сведения о пользователях и чатах.

2. Показывать внешний контекст во всех точках интерфейса

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

3. Обогатить ответы, не переписывая ядро

Мы использовали отдельный сервис-посредник по паттерну sidecar: он перехватывает запрос, передает его основному сервису, получает ответ, добавляет федеративные атрибуты и возвращает результат клиенту. Так пользователи и чаты получают единый признак внешнего контекста без переноса этой логики во все сервисы ядра.

Каждое изменение затем проходит кросс-платформенную проверку: одинаковая логика должна корректно работать на web, desktop и mobile и не ломать обычные, не федеративные сценарии.

Ограничения текущей версии

Федеративные аудио- и видеозвонки пока не поддерживаются. Для встречи с внешней организацией используется гостевая ссылка — это отдельный сценарий, а не часть постоянного федеративного траста.

• Функциональность федеративных чатов близка к обычным, но не полностью совпадает; новые возможности могут появиться в федеративном режиме позже.

• Текущая реализация связывает независимые On-Premise-инсталляции. Облачные тенанты и сценарий SaaS ↔ On-Premise в нее пока не входят.

• Федерация не отменяет локальные политики безопасности: DLP, SIEM, аудит, хранение и права доступа каждая сторона продолжает настраивать в своем контуре.

Что дальше

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

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

Направления, которые мы прорабатываем:

• федерация между независимыми тенантами внутри одной On-Premise-инсталляции;

• федерация между независимыми SaaS-тенантами с настройкой прав на внешнюю коммуникацию;

• федерация SaaS-тенантов с On-Premise-инсталляциями;

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

О составе и сроках конкретных релизов будем рассказывать после завершения проектирования и пилотирования соответствующих сценариев.