Сотрудник пишет коллеге из другой компании по адресу вида имя@домен — из своего приложения, без гостевой учётной записи и без общего облака посередине. Обе установки остаются на своих серверах и обмениваются только тем, что предназначено друг другу.
Две организации в одном разговоре
Как это устроено
Адрес вместо приглашения
Разговор начинается с ввода адреса имя@домен в контактах. Заводить внешнему человеку учётную запись у себя не нужно — а значит, не нужно её потом отзывать.
Доверие на ключах, без общих секретов
У каждой установки своя пара ключей. Исходящее сообщение подписано, принимающая сторона забирает публичный ключ домена отправителя по стандартному адресу .well-known и проверяет подпись. Паролей и общих секретов между организациями нет.
Что федерируется, а что нет
Федерируется: доставка сообщений между установками, зеркальный разговор и состав участников на принимающей стороне, защита от повторной доставки по глобальному идентификатору сообщения.
Не федерируется каталог. «Дайте другой организации читать список наших сотрудников» — не та просьба, которую стоит выполнять по умолчанию. Адрес коллеги вы узнаёте так же, как узнаёте его адрес электронной почты: от него.
В плане: присутствие между установками, синхронизация состава групп и вынос внешней стороны обмена в отдельную роль — сейчас доставка живёт внутри сервера переписки, что удобно для отладки и неудобно для изоляции.
Статус. Механизм реализован и по умолчанию выключен: пока не заданы домен и список разрешённых доменов, федеративных адресов у установки нет. Включаем в пилоте, по обоюдному согласию двух сторон — и это правильный порядок: федерация всегда договор двух администраторов, а не настройка одного.
А если у человека нет никакой установки
Тогда единственный идентификатор, который умеет маршрутизировать весь мир, — это почтовый адрес. Поэтому следующий шаг после федерации — почтовая плоскость: она закрывает всех, кто не внутри вашей организации и не в федеративной.
